10 Lessons I’ve Learned in 10 Years of Software Development

In 2011, I started my first Software Engineering role at a small startup specializing in insurance software. I had a shiny new Computer Science degree, and while I had done some classwork for a non-profit, this was my first time writing code for a business.

In 2022, I left that same startup as one of the VPs of Engineering. Here are 10 lessons I learned along the way.

Project-Level Lessons

As an individual contributor, you might not always have control over how things are run on the project or product level, but there are some lessons to keep in mind no matter what project you’re working on.

1. You are Bad at Software Estimation

At some point, someone is going to ask you how long something is going to take. The problem is that humans are pretty terrible at estimating in general, and software estimation — especially of large projects — is really hard to get right.

There are a lot of software estimating techniques and ways you can combat your own (usually optimistic) bias, but I think the first step is just to acknowledge that you're bad at it. Projects will run behind schedule, and it will take you longer than the 5 minutes you asked for to do a thing. If you’re interested in learning more, my favorite book on the subject is Software Estimation: Demystifying the Black Art.

2. Beware Brook’s Law

The book The Mythical Man-Month was first published in 1975, and almost fifty years later the warning, which came to be known as Brook’s law, still holds true:

“Adding manpower to a late software project makes it later”

At some point (possibly due to bad software estimations), someone in management will want to speed up a project by throwing more people at it. Occasionally it will work out okay: if you have any expert in the product area or you need to assign someone to a specific task (testing, UX/UI, etc.) it may work in your favor. However, hiring an army of junior developers or contractors to finish a late project will almost certainly result in a bad time.

3. Tech Debt Will Come Back to Bite You

Especially in a startup environment, there is a time when it’s appropriate to work fast and accrue some tech debt. However, just like financial debt, tech debt can severely hurt your future prospects if you don’t come back to address it.

It can be hard to convince management that you need to go back and refactor something that is working well (more or less), but lingering tech debt can turn into a monster problem, affecting the scalability, maintainability, and performance of your product. Try to convince your team that it’s worth spending a few hours every iteration to make things more future-proof.

Code-Level Lessons

You may not always have control over the project, but you should have reasonable control over the way you write your code.

4. Leave the Code Better than You Found it

Since you don’t always get the time you need to address tech debt properly, try to leave the code you touch better than you found it. This is commonly referred to as “The Boy Scout Rule”, and it can go a long way towards keeping your code clean.

This does not usually mean that you need to go reformat every line in the file (and in fact that can make it difficult to review your actual changes), but if the function you’re editing has a variable named foo you might want to rename that. Or refactor it so that the code is easier to understand, or so it’s a little bit more performant. Leave a helpful comment. You don’t have to go overboard, and every little bit helps.

5. Don’t let Perfect be the Enemy of Good

You will probably not write very much perfect code. There’s almost always something you could have done better, something that you could have made easier to understand. Accept that.

You want to write good, clean, maintainable code — but there is often a point where time spent begins to offer a diminishing return. For the vast majority of software projects, know when to say that something is “good enough”, and don’t waste your time chasing perfection.

6. Know When to Take a Break

Sometimes writing code makes you feel amazing, powerful, and productive. Sometimes…it doesn’t. When you start feeling trapped in a cycle or like you’re beating your head up against the wall, it usually doesn’t do you any good to keep staring at the same code.

Personally, I find that going for a walk, taking a shower, or even sleeping on it are the best ways to get over being “stuck” with a coding problem. If you’re working in an office or under a serious time constraint, you might not have the luxury of taking a break to shower or coming back to your issue the next day, but getting away from your computer (and ideally your phone) and going for a walk around the block can do wonders for helping you reset.

You’re not chained to your desk, so don’t torture yourself by not taking a break when you need it.

Personal-Level Lessons

While not specific to the software development field, here are some personal lessons I’ve learned while working in it.

7. Know when to Say No and Stand Your Ground

Unless you’re extremely lucky, there will come a time when you need to say “no” to something happening in your workplace, whether it affects your product, your company’s culture, or you personally.

Many things can be resolved with the “Disagree and Commit” approach, where you may reach a compromise or may just go on the record that while you disagree with the approach, you will commit to it nonetheless. For many things, this is the right approach.

However, there are times you have to say no and stand your ground, even when it means you’re not popular with your team, your boss, or your client. It could mean losing sales. It could even mean losing your job, but it can still be the best call for you as a person. I can’t tell you when it’s time to stand your ground, as it is dependent on your background and values.

This all being said, even though it’s important to say no when you need to, it’s also important to learn when to fight your battles. Don’t be the person who has to argue about every little thing; save your fights for when it matters.

8. Writing is One of Your Most Valuable Skills

I recently wrote another story on “5 Reasons Developers Should Refine Their Written Communication Skills”, and I truly believe this to be the case. Especially in our remote, online, and largely text-based field, being able to communicate clearly through your writing is one of the most important skills you can have.

9. Remember Your Coworkers and Clients are People

Especially if you work remotely and you’ve never met your coworkers or clients in person, it’s easy to get into a perspective where they feel like NPCs in a video game — it’s hard to see them out of the confines of your virtual work environment. While spending time in person is the best way to combat this, it’s not always a possibility in our current environment, so try to remember to humanize the people you work with.

Similarly, if all you ever see from your clients are complaints and defects, it’s sometimes hard to remember that they may love your system the other 95% of the time. I once worked with a client who seemed extremely critical of our product — until I met him in person and he told us how it had changed his life and allowed him to spend more time with his family. Getting that perspective made his previous statements seem much less critical and more like he was trying to leave valid feedback on areas we could improve.

10. We’re all kind of Winging it

Do you feel like an imposter sometimes? Like everyone else knows what’s going on and is confident in their decisions except you? Imposter Syndrome is rife in the software development industry, which I personally find comforting: if everyone feels like an imposter then maybe we’re all just kind of winging it together.

Now, there are a few people out there who are experienced, knowledgeable, fully confident in their decisions — but I’ve found them to be rare (and maybe not as knowledgeable as they think they are). In general, I think people are trying to do their best, and there’s not always a clear way (or consensus) on how to do that.

I hope this has been helpful, and best of luck in your own software development journey!