25 Lessons I’ve Learned as a Developer

Being perpetually curious, coding to the conditions, bigheadedness, and more

Lessons I’ve Learned as a Developer

1. Everyone is essentially self-taught in the industry. Tech generally moves too fast for traditional educational institutions to catch up. If you want to boot up something quick, you’re better off doing micro and nano degrees and certifications rather than sitting through three years of exams.
2. Traditional education still has a place in foundation studies. A bachelor’s degree is one way to get your foot through the door but it isn’t the only way. If your brain is more practical than theoretical, and you can’t fund student loan repayments for the next 10 years, the Internet has a lot more guides and structures available now than it did 10 years ago.
3. To make it in the industry, you have to be perpetually curious. You’re constantly asking questions about how things work, why things work — especially in eureka moments when everything finally falls into place.
4. For a long time, you’ll feel like you’re not really improving — until you look back at your old code or have to explain something to someone.
5. The amount of code you create matters as a junior. Learning to code is like learning to write. The more you write, the more you’ll start to notice patterns, inefficiencies, and how to fix them.
6. As a junior, you’ll hit a stage of bigheadedness and think you know everything. As an intermediate, you’ll find yourself deflating egos that you once exhibited. As a senior, you’ll give just enough guidance to steer your less-experienced peers in the right direction, but you’ll also let them struggle just a little bit because it’s all part of the learning-to-create process.
7. Bugs occur because there is a gap in knowledge. Code is an act of translating requirements for the compiler to transform into ‘computer speak’. When things go wrong, it’s because there’s been a blip in the translation by the developer.
8. When people tell you that you’re doing agile but don’t let you in on the planning phase that directly impacts you, it’s not real agile.
9. As a developer, you’ll be in a constant state of knowing but not knowing at the same time.
10. Formatting is the deal-breaker when it comes to readability.
11. Code is a communication tool. Write it in a way that is human-readable and not littered with secret code names that only the initiated will understand. When that happens, the code is incapable of being self-documenting and concise.
12. Functional programming patterns have their place in making things less complicated. Object-oriented patterns also have their place as an organization and categorization tool. These two patterns are not mutually exclusive from one another and co-exist if necessary.
13. Code to the conditions. Over-abstraction for the purpose of ‘best practice’ can lead to more technical debt in the long run.
14. All software ages. ‘Perfect’ code five months ago has the potential to be inefficient code due to changes in requirements, dependency upgrades, and unaccounted-for bugs and blips in logic.
15. Your database is everything. If it’s over-engineered, chances are that your back end will also be convoluted as a side effect.
16. When working in teams, a flat and automated process will be the deal-breaker for your productivity. A flat structure means you can move code through the pipeline faster, and automated means less time clicking, typing, and waiting for things to get done.
17. Inheriting bad code is a rite of passage. Everyone goes through it at some point in their careers. It is also an opportunity to learn from the mistakes of others, and space to do good things for the future direction of the software.
18. You’ll constantly be cleaning after others and your past creations. This is because code is like food — if it’s not actively consumed, it becomes legacy and can turn bad with age.
19. Work-life balance is still relevant for developers because we’re all still humans. Don’t be the stereotype and neglect yourself, your friends, or your family. Take care of yourself and don’t let the code life take you over.
20. If you feel like you’re on the brink of a burnout — stop. Take a break and then come back — but to code that has a higher purpose or personal meaning to you. Software is the interface between the customer and the business. As developers, we act as the force that allows this to happen. It’s alright to jump ship if you feel like you’re not really contributing to this — or you simply don’t believe in it. You need to be proud of what you’re making. Regardless of where you end up, you’ll still make a decent income.
21. Don’t get too hung up on other people’s code. Work with what you’ve got. Focus on improving yourself to become the benchmark.
22. If no one is calling you in for an interview, get creating. If you’ve got no experience to put down for your resume, get creating. If you’ve got a spare weekend and have an idea, get creating. As developers, we are in the business of creating code. The moment we stop is the day we risk becoming part of the management team.
23. Don’t just learn to code. The bigger your domain of knowledge, the easier it will be to code your projects. This is because coding is transforming the world, its rules, and processes into a digital representation of reality. You can’t effectively create something you don’t understand.
24. You will never know everything there is to know about code — but ideas are finite. It’s better to have a large repertoire of ideas and use them as the guideline for your code creation process. You’ll end up with sturdier software.
25. Software books are still worth reading and investing in. That’s where a lot of the big ideas are explored in depth — especially those by Robert C. Martin and Martin Fowler. They are the industry gods among us mere mortals.

Conclusion