G’day guys!
Today I wanted to talk a bit about software companies: the good, the bad and the ugly. The truth is that not all software companies are created equal, and if you’ve never been at a good software company, you may not be able to recognise when you’re at a bad one. I’ve worked at a few software companies throughout my career so far, and looking back, there are definitely a few that stick out like a StackOverflowException, I mean Sore Thumb. Likewise, there are a couple of places that I look back on with fond memories, like a Wayback Machine replaying the golden age of the internet in the 90s. So without further do, here’s a list of 10 simple factors that I think might indicate whether you’re at a good software company, or a bad one.
To make this list even better, I’ll provide a couple of examples of how my current company addresses each point. This isn’t meant to be a brag - I just want to provide concrete examples of what you might expect from a good software company in the real world. And if you’re a passionate developer who loves code and star wars, who knows, there may be a place for you here ;-)
1. The pay is good.
This will vary a bit depending on your level of experience and whereabouts you live, but I think a good rule of thumb is to always aspire to be at an above average rate. If you’re not sure what average looks like for your circumstances, you could try doing a lookup on GlassDoor, or reach out to a few recruiters on LinkedIn - most will be happy to guage what salary you could expect and potentially even help you find a company that’s hiring, since the commission that they receive is often in proportion to the salary of the candidate.
Before you all start firing bullets at me, I agree that money is not everything, and that a company that pays you well may still not be a good company - they may be overcompensating for what they lack in other areas. But you still don’t want to be earning less than what you could be, and a company that will knowingly and willingly pay you less than what you could be earning is in my books, a bad company.
What my company does: I won’t disclose my actual salary here, but needless to say, I’m compensated well. That’s not to say that I couldn’t potentially be earning more elsewhere, and I have seen opportunities with better remuneration. But the package that I receive at my current company, including the remuneration, is very difficult to beat.
2. They provide you with good tools.
You can’t give a builder a hammer and tell him to build you a house any more than you can give a programmer an archaic machine from the stone age and tell him to build you a program. If a company wants to get the most out of their developers (and save us a great deal of frustration), they need to provide them with adequate tooling. Understandably every team has a budget and they don’t need to overspend, but they do need to provide their devs with the tools needed to get the job done. At the very least, this is a modern desktop with enough computing power to meet the needs of the tasks at hand, as well as subscriptions to whatever services will make the developer more efficient in what they’re doing (eg: an issue tracker, IDE, cloud services, etc).
There’s nothing wrong with Open Source tools or free tools, but if you’re using sub-par solutions that are consuming time and effort simply because somebody doesn’t want to pay for the real stuff, you are - you guessed it - at a bad company.
What my company does: We have subscriptions to Jira, Confluence and Trello for collaboration. We host our services on AWS for reliability and scalability. We all have licences to Visual Studio Professional and Redis Desktop Manager, including the new guy. We have a SumoLogic subscription for logging. I’m probably unaware of over half of the tools that we actually have, and those used by other teams as well, but you get the gist. All of these tools cost money, but they all go towards making our lives easier and helping us deliver quality products.
3. They’re flexible.
Why do you need to wear a buttoned shirt and leather shoes, when the only people that will ever see you are fellow developers? Why do you need to come into the office, when you can remote in from home and be just as productive? Why do you need to be at your desk from 9am to 5pm, when you might prefer to work from 7am to 3pm and achieve the same results? If there isn’t a strong need for their employees to do something, I’m of the opinion that they shouldn’t be forced to do it. Having rules in place “just because” is in my view, a sign of a bad company.
What my company does: They supported WFH as needed (even just on rainy days) even before COVID made WFH the new normal. They allow for starting and finishing earlier or later, so long as you’re present in the morning huddle. And they allow for you to take time off during the day to go to the gym or to play sport, so long as you make the time up elsewhere. Oh, and they don’t mind what you wear.
4. They encourage self improvement.
This could be by allocating a certain amount of time for “hackathons” or “hack weeks”, or it could be by rewarding employees who acquire new certifications or new skills. But in the software industry, stagnant skills in technology rust like an old saw, while new technology keeps emerging at a pretty alarming rate. A company that doesn’t encourage their developers to keep their skills sharp and up-to-date is basically condoning the use of a rusty saw on the job. Bad company!
What my company does: They offer a Pluralsight subscription to help support our learning outside of work, and we have a “hack week” once a quarter, where every developer can spend the whole week working on a small project of their choice using any new tools that they’ve been wanted to tinker with. Or they can just use that time to learn something, on Pluralsight for example.
5. They should care about their developers’ well-being.
This means permitting and encouraging time off without an interrogation. It means offering healthy and fun activities from time to time, and it means providing healthy options in the lunch room. Death marches fueled by coffee and pizza are definitely not a good thing.
What my company does: We have standing desks for starters - and not just the cheap kind at office works, but high-tech desks that are button operated. Our chairs are all super ergonomic. Our lunch room is filled with healthy snacks; fruit, nuts and yogurt. We have paid gym memberships with Fitness First.
6. Outages and production issues are few.
I was once working with a recruiter who was trying to push me into a role that I was a bit suspicious of, since the interviewers seemed to imply that production issues were common, and that a good candidate for the role should be able to deal with the stresses of these. The recruiter replied with “I know a large number of A grade software companies that are having production issues on a weekly basis!” as if it were supposed to be normal. I’m of the opinion that it’s not, and if it is, your product and company has some serious issues.
Do you not allocate time and funds for QE? Is the development culture one that promotes hacky workarounds and band-aids instead of implementing proper solutions? Is there unhealthy pressure from management to deploy before things are ready? If any of the above is true, I think you’re at a bad company.
What my company does: I won’t say that we never have production issues, because life isn’t a fairytale. But any issues that we do have (at least from my team) tend to be every 6-12 months, not every week.
7. Everybody is competent.
Probably one of the worst scenarios (and worst red flags) is where your team leader, manager or boss is incompetent. They recommend poor solutions, and don’t listen to (or don’t fully understand) suggestions for improvement. This is incredibly frustrating, and it’s not an environment in which anything can thrive. Not you, your skills nor the product being developed.
It’s not just about those above you though. In a good software company, the hiring process is stringent enough that everybody that gets hired should be competent. I’m not saying that they all need to be rock stars, Harvard graduates or have just left a FAANG company, but everybody should at least be competent, and ideally excell in a specific area. You shouldn’t have to oversimplify for anyone, or exclude anyone from discussions because you feel that it’s not worhwhile for them to be involved. At a good company, everybody is competent.
What my company does: This is probably one of the biggest differences between my current company and my previous one. Everybody that I work with is genuinely passionate about software, and we’re all very good engineers. Some of us may have more experience on the front-end, some of us have more experience on the back-end, but all of us are at least competent across the whole stack and are bright in general.
8. Suggestions are taken seriously.
If everybody on the team is competent (see point 7), then everybody’s suggestions should have merit. It sucks being in a position where you present suggestions for improvement - perhaps even invest a great deal of time into putting together a demonstration and presentation - and everybody just walks away as if they just came out of a cinema and nothing gets changed. You should be able to document your suggestions in a public place, and they should be discussed with your competent manager and competent peers.
What my company does: This may vary somewhat from team to team, but we have a Trello board where anybody can post a suggestion, either about our development practices, our stack, our workflow or anything really. So long as we’re not behind the 8-ball trying to ship a feature, you could grab our team lead and the rest of the team and have a discussion around the issue. If it’s agreed that it should be addressed, we’ll create an improvement ticket in Jira and assign it to somebody for implementation.
Actually though, I think one area where maybe we could improve is by having regular, scheduled times for discussion and reflection instead of it being on an “as-needed” basis.
9. Innovation is encouraged.
If your creative ideas are always dismissed, soon you’ll stop being creative. The net effect of this is that the company produces a cookie-cutter product with nothing original and nothing novel.
What my company does: I already mentioned our hack weeks once a quarter, which are a fantastic way to curry innovation and creativity. Everbody gets a whole week to work on their wild “it’s just crazy enough to work!” ideas and demo them infront of the rest of the developers. We have even had a few products emerge from these hack weeks.
10. Decisions are debated.
I think it’s probably quite common for decisions to be implemented simply because they come from above. A manager or tech lead has made a decision and put it into a ticket or issue, so it gets developed and deployed that way. But I think that all decisions could and should be debated, especially if there’s an interesting alternative with merit. It’s through this fearless discussion and debate that your team comes to the right decision, which results in a better solution, a better product and hopefully everybody walks away having gained something as a result.
What my company does: This one isn’t a specific action per say. It’s just a culture of being able to contest any decision and voice your opinion without fear of ridicule or losing your job. I’ve personally contested the decisions and opinions of my team lead, and the manager above him, and I think that everybody benefited from the debate. And of course, my own decisions get debated just as often.
Whew! This article turned out to be a fair bit longer than I originally intended, but I think it was worth it. What do you think? Do you disagree with any of these points or do you have one that I missed? Let me know and we can debate it ;-)
That’s all from me for now! Catch ya!