Lessons I learned in the last 10 years

January 7, 2024

I've been a software developer for nearly 10 years. These are some of the lessons I have learned along the way.

1. Learning how to communicate.

You spend most of your work expressing ideas and opinions to others. Knowing how to highlight your accomplishments, soften your mistakes, and how to champion your solutions, will help you more than learning a new programming language or framework.

2. Never use the new shiny stuff on more than 30% of your project.

Shiny stuff is shiny and wonderful, but never do more than a third of your project with an unfamiliar technology. If it works out, congratulations, you still have something newer and better. If it doesn't, you can still yank it out and replace it with the tried and tested.

3. The vast majority of deadlines are made up.

It's a skill knowing which ones are not.

4. You are always under a time pressure.

Being late is the default state, because there's business value for shipping as early as possible. Over time, you'll learn to ignore that pressure, as it's always there.

5. The vast majority of product/business managers are not incompetent.

Most of them never had a reliable and trustworthy technical partner for them to work with (see #1). If you have their trust, they will change features, deadlines, commitments, and resources to help you and your team.

6. You need less technical skills and more people skills the higher you go on the corporate ladder.

The best tech leads I know, don't write a lot of code, but they do a lot of code reviews, coaching, talking, testing, changing processes, reverting changes, and just communicating.

7. Being a middle manager is the worst.

You're not high enough to be judged by only your people accomplishments, and you're not low enough to contribute yourself. You have to manage as well as lead.

8. Experience is more valuable than hard work, but hard work is needed to gain experience.

Having the wisdom that you don't need to work 10-hour shifts comes from working 10-hour shifts.

9. Toxic work environments are never worth it.

"Just for a little bit, to get my finances in order.". No. It's a downward spiral from day one, and every additional day lowers your energy level. Energy that you could spend on finding a healthier work environment. The money, status, prestige, experience is not worth it, if you can't actually enjoy them.

10. Your job satisfaction comes mainly from your team, not the company.

How happy you are at work mostly depends on your manager and the team they manage. A good company culture might increase the chance of having a good manager, and them sticking around. Don't believe me? Wait until you change managers and the team dynamics shifts overnight.

11. Great codebases never started out great, they became great over time.

All the best codebases I worked on were continuously improved upon. Effort was being put in to refactor, and small compounding clean-ups accumulate over time. I have witnessed too many projects start out clean and proper, and change to a hot mess as soon as they hit production, user feedback starts coming in, and the product team starts putting in more requests.

12. Most codebase complexity is due to engineers not understanding the problem space.

I'm not sure if engineers themselves are to blame, but I've seen so many unwise architectural decisions, that could be solved by a simple Google search. For example, tax rates change all the time and have an effective start and end date. Hardcoding them in just won't do!

13. Take care of your body.

Invest in ergonomics. Most of us over 30 have bad backs, neck pains, wrist pains, hip pains. That's why we're bitter. Don't be like us, invest in a good chair and desk. Don't forget about exercise. 30 minutes a day. At least.

14. Read the Mythical man Month

Read the Mythical man Month (1975) not because you will learn something new about technology, but read it to understand that all the advancement we made with AI, internet, pocket computers, space exploration, and general technology in the last 50 years, we're no closer to solving the real problem of software engineering. People.

15. Be a part of a community.

Ideas and opinions need peer-review. That's what communities are for.

16. Never work on an important part of the codebase after lunch.

If it's not the first thing in the morning, just don't do it. You wouldn't want a surgeon operate on your heart, if they are tired. Being fresh to tackle important development works wonders for quality.

17. Master a stack. Then branch out.

Mastering a stack will give you the foundation on which you build your engineering knowledge. But don't stop there, branch out to other stacks and paradigms, as you need exposure to different ideas and approaches to really build out your skill set.

18. The 10x developer exists.

To find them, don't look at individual contributions (how much code they shipped), but their involvement in things that had the biggest impact. Simply doing an analysis on your most successful initiatives will often bring up just a handful of names. The same can also be used to find the negative 10x developers.

19. There's a difference between a manager and a leader.

The manager's job is to manage work being done. It's an organizational position. A leader is somebody you follow, because you value them and their input.

20. Programming is a skill. You have to practice.

It's like riding a bike or playing an instrument. You won't be very good at it, if you only read books and follow courses. You have to actually do the thing to learn.

21. Never call it TDD. Call it old plain software development.

People have a strong reaction to testing, especially if they have never done it. Still do TDD, but don't say you're doing TDD. Say you're tired of manually testing the code, so you made the computer do it. Call it automation or something like that.

22. Refactoring is a part of feature development.

Always remember that refactor and maintenance is an integral part of feature development. Always include them when doing estimations.

23. Nobody actually knows what's the actual value of your work.

It's a debate. If the organization is making money, the debate continues and #1 will help you at that. If the organization is not making money, it's a moot point, as you'll be out of a job either way.

24. It's just a career.

Try to be a well-rounded individual. Having a career is important, but it shouldn't be the only thing important in your life.