A tremendous amount of time, money, and effort goes towards training people how to get software jobs. Once someone has been hired, however, too often they are left on their own. Good workplaces pair new engineers with mentors (and if the new hire is fortunate enough to be paired with someone passionate about mentoring, the results can be good). For those who know where to look there are a number of good books which can help, but for the rest there are a number of lessons that are usually learned the hard way.
The most important lesson is one that takes many people a long time to realize - the importance of saying “no”. Whether a developer is new to the industry or merely new to a role, they often are inclined to say “yes” to any and all requests. This is natural - they want to show that they are a team player, that they are up to the task, and they want to make their coworkers happy and build good relationships. In excess, however, it will quickly lead to their downfall.
Saying No to Tasks
At the end of the day, there will always be more work. If you stay up past midnight finishing a new feature, crash on a couch, and go to a meeting the next morning, there will always be more features or more bugs to work on. Software is never perfect - you eventually just decide that its level of quality is acceptable to release. Trying to be a hero who does whatever it takes to get a feature in can have long-term effects on your health as well as on people’s assumption of the workload you can handle. As such, the first important place to learn to say “no” is when given a new task. If you have a full load of work and are being asked to take on more tasks, your have a number of good responses:
- “Which of these other tasks should I de-prioritize?”
- “I can look into that after <other task>, which wouldn’t be until at least <date in the future>”
- “I can’t work on that at the moment, but we should file a feature request for a future milestone”
The core thing to remember is that your health - physical and mental - should be your top priority. Study after study has show the negative physical effects of insufficient sleep. Insufficient downtime - not just sleep but free time - leads to burnout, which has catastrophic effects. On a previous team, I worked nights for several months, burnt out, and ultimately was in a slump for longer than I care to admit. As part of my recovery, I started strictly separating my work and personal time and refusing to work more than 40 hours in a week. My productivity in those 40 healthy hours was so much higher than in 60-80 hour burned out weeks prior that I was promoted that cycle. Burnout is particularly dangerous because when you’re burnt out, you’re likely not in the mood or condition to interview with other teams or companies - and in some cases a change of scenery is exactly what you need to get out of burnout. If you believe this is the case, do whatever you have to do to reduce your hours and get out of the burned out state - even if it means causing friction on your team in the short term.
Like any rule, this isn’t set in stone. There will be times in the release where time-sensitive deadlines come up, urgent issues arise, and you may need to work long hours for a week or two. On many teams, this is accepted as part of the process and can be healthy. If it becomes a constant trend, however, that’s when you know there’s a problem that needs to be addressed.
Saying No to Design Decisions
As a developer, you will get requests for all sorts of design changes and bug fixes from all sorts of people. Many of them will be people you respect, are friends with, or who have an impact on your career trajectory - bosses, product managers, more senior engineers. There is always an inclination to prioritize these requests or to implement them without question. Instead, you must remember that you have a number of obligations:
- You have an obligation to the customers of your product to deliver a great experience for them. Will this feature deliver what the user wants, or will it merely check off a box claiming a feature exists? If it doesn’t address the scenario in a productive way, push back.
- You have an obligation to the codebase and the future maintainers of the code (which could very well be you). Be sure that your estimates of how long a feature will take incorporate the time to do it properly - refactoring the code, adding tests, and all other essential steps. If you agree to features on short deadlines and leave tech debt, it will multiply over time.
- You have an obligation to keep in mind the overall experience. Even if implementing someone’s pet feature would only take a day, would that day be better spent on other work that would deliver more value to users?
It’s not always a literal ‘No’
Directly telling people “no” can seem confrontational at times. Sometimes this is unavoidable, sometimes this is not. Never be afraid to fall back on data - “we could do that, but it would take 4 months and delay the launch of feature foo”. At the end of the day, however, sometimes the right response is one word - and “No” is a perfectly valid answer.