Reflections on 21 Years of Programming and Developing Software. Here are 21 Timeless Lessons I Have Learned

I first fell in love with programming in 1999 while in school, and have been developing software ever since. 21 years is a long time to see a field evolve, and I am amazed by how much programming has changed the world we live in in the last two decades. Programming, alongside tremendous growth in computing power backed by Moore’s law, has not just impacted but transformed every industry. The way we do business and pleasure is so different than what it was just two decades ago.

As I sit back to reflect over these last two decades of programming, below is what all I have learned :-

1. Writing code is not the objective. It never was. Code serves a purpose – solving problems for real people, and we must never forget that.
2. Keep it simple. Less is more when it comes to code. Deleting code is more valuable than adding code. Don’t write code you don’t need. Code needs maintenance, and every extra line of code will be a liability in the months, years and decades ahead.
3. Listen to others, but decide for yourself. Don’t let others decide for you. Develop your own voice. Learn to understand the industry you are in, and the problem your product is solving. Your code and what it does is your responsibility. Speak up if you have doubts over the impact of your code in the outside world. Your voice matters, but you will have to make it heard. There is nothing wrong in writing, for example, a software to capture people’s faces and detect their ethnicity, but you have to think about what that will be used for. You are responsible for the use of your code.
4. Change is the only constant. If the software era can teach us something, it is about change. From command line scripts to downloadable software to websites to mobile apps to internet of things, the definition of software and how software engineers work is constantly changing. The corollary to this is that unless we become comfortable with unlearning and learning new technologies as they evolve, we risk becoming obsolete.
5. You spend 99% of your time maintaining software, rather than writing or creating new software. Every new graduate programmer start their career with dreams of writing lots of code and creating new software. However, they soon realise as they enter the workforce that they spent 99% of their time maintaining software rather than writing code from scratch. Sometimes you get lucky, but over a career spanning in decades, it all evens out.
6. Learning to communicate is more important than learning to program. We are all social beings, and believe it or not, developing software is a very social act. It involves interaction between business leaders, product managers, designers, developers, testers, and sometimes with people from sales, marketing and other administrative tasks. To make it worse, we developers have a very bad reputation when it comes to effective communication. I have seen many a software projects fail because of missing communication rather than bad code itself. Learn how to communicate more effectively, and you will make a big improvement in your productive output.
7. The importance of documentation, code reviews and testing can’t be stressed enough. In the constant pressure of delivering software fast, it is often tempting to neglect or bypass them. However, practices like code reviews, testing (both unit and integration), and documentation are essential for the long term success of not just the software in question, but also the culture of the organisation. Think of the next developer who will work on your project, and do what you can to make their job easier. After all, you are in the same boat (company).
8. Do stuff other than programming. In the first 5 years of my career, I was coding more than 12 hours a day because I loved and enjoyed it a lot. Experience has shown me that that kind of pace is not sustainable. It is important to keep your mind and body in good shape. Otherwise sooner or later, cracks will start showing up. Do other things to engage your mind and body like practicing a hobby or a sport. In other words, get a life. Over the long term, the experience you gain out of such activities will also enhance your programming.
9. Look for evidence / data when presenting your arguments to business and product people. Sharing your opinions without backing them up with relevant data is a surefire way to disappointment. Do your homework and go well prepared. It will prevent unnecessary frustration and code rewrites later, and you will thank yourself for it. Evidence will make it easier for you to get done what you want done. Learn how to run small proof of concept experiments to gather data to support your argument. It will also help you grow faster in your career and earn you respect.
10. Be willing to throw your code away. Don’t get attached to your code or your software. If it makes business / product sense to throw it away and start from scratch, do it without worry or guilt. Remember point 1 above, that code itself is never the objective. Solving user problems is.
11. Strive to make your code readable and self-documenting through good naming practices rather than by adding comments. Code is not only for execution, it is also a way to communicate. Write readable code. Most of the time code is read by people who didn’t wrote it. Think about the next person who will read your code. Make their lives easier.
12. Solve the problem you have right now. Then solve the next one. And the next one. Don’t think too much in the future. Don’t try to solve problems that don’t exist yet. Don’t write code that you think you might need in the future, but don’t need yet. This is coding for imaginary future use cases, and inevitably the code will become dead code or need rewriting because the future use case always turns out to be slightly differently from how you imagined it.
13. Just like the best way to solve a problem is to avoid it, the best way to ‘securely’ deal with user data is by not capturing it. Or to store it only in an anonymised way. Once you capture user data, even if it is encrypted, there is always a risk of it falling into the wrong hands. So make sure to double check if you necessarily need to capture user data. You will thank yourself in hindsight.
14. Automate anything when you see yourself repeating a set of steps. It not only saves time but also prevents human error. The most important thing is to automate the build and deploy (CI/CD) process to prevent unnecessary production issues from cropping up due to preventable errors.
15. Refactor whenever you get a chance. Once you encounter a piece of code, leave it better than you found it. Programming is all about abstractions, and the closer your abstractions map to the problem domain, the easier your code is to understand and maintain. Refactoring is one of the best ways to make your abstractions resemble the real world problem.
16. Life is too short to work in a place you don’t enjoy working. Work in a company whose culture makes you thrive. When something goes wrong, do people point fingers and blame? Or do they take responsibility to make sure the same mistake doesn’t happen again? What kind of culture do you want to be a part of?
17. Always use Unicode and UTF-8 or UTF-16. If you are dealing with text in a computer, you need to know about encodings. I am surprised I am still talking about encodings in 2020.
18. Add monitoring early in your project. It will help you understand how your system behaves. It will give you necessary inputs to add automated mitigation and fail over practices in place. You should add proper alerting for everything else that can’t be automated.
19. Ask WHY more often. Understand why you are adding a feature. What business need does it serve? Ask if there is a better way to achieve the same objective. Give inputs to the product / business people around you if you have a strong opinion. They will respect you more for it, and the product will get better. Asking “why” can not only make you more productive in creating software but also make your team and company save iterative effort later on. Talk to your peers. You can’t (and don’t have to) do it all alone.
20. Say “NO” more often. Every feature has a cost that goes beyond the initial implementation – maintenance cost, documentation cost, and cognitive cost for your users. It is much more difficult to remove a feature and its code later than it is to say NO earlier and keep the product focused and simple.
21. Software development is a team sport. The young developer likens himself to a sole warrior. Time and experience teaches that software development is a team sport. So if you are very productive individually but destructive to your team’s productivity, sooner or later you will bear the consequences.