I turn 30 today. I can’t say that I’m thrilled to be exiting my 20s, but I am looking forward to seeing what the next decade will bring. In celebration of this major milestone, I’d like to share the 30 most impactful things I’ve learned about software in my career.

1. Take Every Opportunity to Learn Something New

I’m not sure there’s an industry that moves faster than software. Things change, new methods and patterns are developed, and managed services improve literally every day. Seize every chance you have to grow your toolkit.

2. Differences in Opinion Lead to Innovation

Surround yourself with people who challenge your ideas. If your team agrees with you 100% of the time, you’ll end up with narrow ideas. Questioning your thought process will not only make you think about your solution more, but it also might spark a totally different idea.

3. Don’t Take It Personal

So what if your story failed QA five times or the stakeholders hated your demo in sprint review? It’s not because you wrote it. We’re all part of the same team with the same goal: making the best software we can.

4. Automate Everything

Every time you have a task performed by a person, you introduce an opportunity for failure. A machine won’t forget an item on a checklist. A machine will perform the same task the same way over and over and over. You can automate everything from authentication in your tests to your deployment strategy.

5. Embrace Failure

You will never know less than you do right now. If you try to build a new piece of software and it fails horribly, that’s OK! The next time you try, you will know exactly what not to do. Build on your experiences to hone your skills.

Photo by Michał Parzuchowski on Unsplash.

6. User Experience Is Everything

Your user experience is what sells your product. Customers aren’t going to buy your software because the back end is written well. They’re going to buy it because it’s delightful and solves their problem in an intuitive and efficient way.

7. Iterate, Iterate, Iterate

When building software, your goal should be to get something working and exposed to people as fast as possible. In general, people have a hard time coming up with ideas from scratch. But they can tell you how to take what you have and turn it into the solution they need.

8. No Sacred Cows

Don’t accept the “we do it like this because we’ve always done it this way” policy. Do something because it’s the right way to do it — not because it’s the familiar way. You can’t expect change if you never do anything differently.

9. Use the Single-Responsibility Principle

Cars drive really well. But if you also made a car fly, you’d sacrifice some of its driving ability. It might be able to do both, but it will never be great at either. Your code is the same way. Keep it focused. Make it great at one thing.

10. Line-by-Line Debugging Is Overrated

If you follow the single-responsibility principle, your code should have a narrow focus. If it has a narrow focus, you should be able to limit the things that go wrong. There’s nothing faster than a console log and some unit tests. Hey, I got 10 things in before I said something controversial.

Photo by Clint Patterson on Unsplash

11. The Programming Language You Use Is Actually a Big Deal

When starting a new project, think about the problem you’re trying to solve. Python is good for big data. JavaScript is good for general web development. There are so many languages out there for a reason. Choose the language that best solves your problem.

12. Side Projects Teach You More, Faster, Than Anything Else

If you want to learn something new, be it a programming language, new architectural pattern, or technology stack, getting your hands dirty will drastically improve your understanding. Theory is just theory until you practice. Plus, you get an opportunity to share what you’ve learned with others.

13. You Will Never Know Everything

Go into development with the knowledge that there is probably a better way to build what you are about to build. But you will iterate and you will learn. Technology changes so fast that the best way to solve a problem yesterday might not be the best way to solve it today.

14. Don’t Build What You Don’t Need

This might sound obvious, but it bites so many of us. Who asked you for that piece of configuration? Nobody? Hardcode it. If you don’t need to build it right now, then don’t. Build the minimum you need to solve the business problem, then iterate.

15. Retrospectives Are Game-Changers

In agile development, you do your sprint review and retrospective at the end of your sprint. If your retrospective is done right, you and your team will turn into highly functioning code machines. You’ll be aligned, be enabled to move quicker, and have an unrivaled team camaraderie.

Photo by Austin Distel on Unsplash.

16. 80/20

When you ship your final product, you might be disappointed to find out that your consumers don’t use every feature you built. In fact, they are going to find a small set of features (about 20%) and use the crap out of them (80% of the time). The other 80% of the features will get used, but only 20% of the time. So put your focus into optimizing the features that solve the business problem.

17. Good Architects Make Complex Solutions of Complex Problems

There are some problems out there that are harder to solve than others. If you have a good software architect, they will design a complicated solution to solve the complicated problem.

18. But Great Architects Make Simple Solutions of Complex Problems

It takes a talented individual to boil down the intricacies of a complex solution and turn it into something consumable for everybody. They put the brunt of the problem on themselves and expose a simple solution that hides the ugliness of a difficult task. For example, a great architect designed Amazon’s “One-Click Purchase” button. They completely abstracted away the entire purchasing process behind a single button click.

19. 1x, 10x, 100x

If you see an issue with the code you’re writing, fix it now. It takes minimal effort. But if you let it get to QA to find and report, it’s going to take 10 times the effort. You have the effort of the analyst, plus your effort to get familiar with it again and fix it. If it gets into the field, it’s going to take 100 times the effort to fix. You have the effort of the consumer to find and report, then support to triage, then whatever flow you have to get it down to you to fix, test, and deploy.

20. Stories and Metaphors Are Key

If you want to explain how your software works in the easiest way possible, tell a story. People relate to stories and metaphors by making connections to things they are already familiar with. They will understand what you are trying to convey and be able to relay that to others.

Photo by Road Trip with Raj on Unsplash.

21. A Robust, Well-Documented API Is Worth Its Weight in Gold

Today, software is about integration. How can I tie this service into that service? APIs are the answer. If you build an API that has a rich set of features and is well documented, you’re a modern-day hero. Open APIs are the standard today, and you should be building them.

22. Interviewers Care More About Your Problem-Solving Ability Than Your Knowledge Of Programming Theory

When I interview someone, I’ll go through a couple of theoretical questions, but I spend most of the time trying to see how your brain works. When programming is your day job, you spend all day coming up with solutions to problems — not writing about what polymorphism is.

23. 80/20 (Again)

It takes about 20% of the time to do 80% of the work and the remaining 80% of the time to do the last 20%. Think about a house being built. In the first month, you see a plot of land go from a grassy field to having the foundation, scaffolding, and rooms framed. From there, things seem to move at a snail’s pace. Software is the same way. Most of the time will be spent hardening and ironing out the plumbing and details.

24. It’s Been Done Before

Developers joke that they’ve never written an original line of code in their life. To be honest, that’s probably true. Patterns are a thing for a reason. What makes your software unique is the way you solve the business problem. Don’t try to come up with a new pattern just to be unique. Use what works and make your user experience your game-changer.

25. Mentors Are Essential

It doesn’t matter if you’re just starting your career or are 45 years in. Somebody has done what you want to do. Get their help. More often than not, they’d love to help. And when you feel ready, give back.

Photo by Nadir sYzYgY on Unsplash.

26. It’s All Just 1s and 0s

Computers are going to do exactly what you tell them to do. They don’t have minds of their own. Your code doesn’t work because you wrote it that way. There is always an answer in the code. You just have to find it.

27. Software Goes in Cycles

I wasn’t around at the time, but apparently cloud development is almost exactly like mainframe development. The tools are just better today. Methodologies cycle too. We used to be big into waterfall development, then got into agile, but waterfall seems to be sneaking back in again. Maybe the next 10 years will bring us an improved toolkit and process of what we did 20 years ago.

28. Storage Is Out, Compute Is In

Back in the day, all of the cost optimization strategies gravitated around saving disk space. Use all the compute you could to take up as little storage as possible. But today, that has flipped on its head. Storage costs almost nothing and compute prices are on the rise. Spend your time optimizing the processing of your code and store everything you can.

29. Data Is Beautiful

Big data is a huge deal. It powers machine learning, provides insights into our work processes, and illustrates trends. With the storage of data being so cheap nowadays, there’s no reason not to store everything we can. People love graphs, charts, and trends. Wow them with beautiful insights about how they do something.

30. The Best Tool Is Your Team

If you want truly innovative software, build up a strong team. A team that trusts each other to get the job done, challenges each other, and connects on a personal level. Building a culture that focuses on getting to know each other will be the ultimate decider of whether or not you’re successful. As a leader, put your efforts into your team.

Photo by Helena Lopes on Unsplash.

Conclusion

That’s it! I’ve had a whirlwind of a career in software so far, and I’ll be excited to see how my opinions change in the next 10 years.

Do you have any other lessons that you would like to share? I’d love to hear about them.