PRACTICAL SOFTWARE DEVELOPMENT ADVICE

32 Opinionated Advice and Lessons Learned in Software Development

Useful advice for any developer

For the past few years, I’ve been developing software professionally for both small and large clients. Some of the software has been used in very strict environments where safety and reliability were of highest concern.

I’ve compiled a list of useful advice based on my experience thru the years. Without further ado, here’s my opinionated list of advice, lessons learned, and best practices.

1. It’s okay to write trash code sometimes. Not all parts of your application are born equal.
2. You don’t need to learn a new language to learn new things. The same thing can most often be done in many languages. Prefer depth over breadth.
3. Write throw-away-code to test different approaches. Just don’t let the throw-away-code become production code.
4. Code defensively. Do you remember the method parameter that you thought would never be null? Yeah, it turned out to be null anyway and your application exploded. Just write those guard clauses and get it over with.
5. Never. Ever. Hardcode application settings. Write configurable components and pass environment variables to them. It’s easier to restart an application than to recompile and redeploy.
6. Write code that’s easy to test. That means stop “newing” up a database object inside your command handler, service class, etc. Instead, turn it into a dependency.
7. Only throw exceptions when exceptional things happen.
8. Learn suitable substitutions for If-Else. If-Else is often overused and an early sign of poor design. Lots of design patterns remove the need for If-Else statements.
9. Not every IF needs an ELSE IF or ELSE. IFs by themselves are fine and often encouraged.
10. Refactoring means refactoring. Do not try to add new functionality while you’re on a refactor crusade. It won’t end well.
11. When you identify trash code, take some time to clean it up and make it better — whatever “better” means in the specific context.
12. If you’re not learning design patterns, you’ll have a difficult time. They’re everywhere and recognizing them makes your life easier.
13. Applying design patterns will most likely improve your code.
14. Bashing other people’s code is not going to make you a better programmer and is not a display of seniority. Primarily beginners bash other developers' code because they have a difficult time understanding even simple concepts.
15. Don’t create an interface before you’re going to need one. It’s completely fine to just start with concrete classes.
16. Are you sure the field/property/method needs to be public? No, that’s what I thought. Make it private or internal.
17. Super simple classes — like one method simple — are the way to go.
18. Write simple code for simple problems.
19. Make sure to have tests in place for every part you’re refactoring. Otherwise, you’ll not know what you’ve broken.
20. No — the code you just jotted down is not better than the NPM/NuGet/pip package with 11 million downloads. Download the f*kn package and move on.
21. Don’t be afraid to come up with complex solutions for complex problems. Just don’t go the other way.
22. It’s fine to pick up a few languages. Try to go for one back-end, front-end, and database language. You’ll have a greater appreciation for what other members of your team are dealing with then.
23. Stop watching them d*mn tutorials. Do your own thinking. Sure, the occasional tutorial is fine when you’re stuck on some problem or need to learn something fast. Just exit the tutorial limbo.
24. Most other developers write trash code as well. Don’t lose your sh*t over it. They surely did it for a reason.
25. Watch developer conference talks and follow thought leaders. Lots of great experience to draw from and easy way to gain inspiration.
26. We all hit a plateau in our journey to become better developers. Seek advice from accomplished developers. Don’t be afraid to send a random developer a message.
27. Using GUIDs/UUIDs as entity IDs are often making things easier to work with. But be aware of the tradeoffs you’re making.
28. Adhere to SOLID principles. They’re easy to understand and improve your code quality. Statements like “Open/Closed principle is not important” will come back to bite you.
29. Use enums over strings as arguments if there’s a finite number of options.
30. Arrange your code in modules (projects in .NET terms). Don’t just place everything in one module. It quickly gets out of hand.
31. The business problem you’re solving or business application you’re developing is the most important thing to keep in mind. To a business, your code is just a means to an end.
32. View software development as a craft. Write purposeful and beautiful code. Actively seek to refine your skills.

I’m sure there’ll be developers disagreeing heavily with some of my advice. But that’s the nature of opinionated content. You’ll always find differing opinions, approaches, and mindsets.

It’s healthy to take in lots of perspectives. Stay critical and incorporate what you find makes sense to you.

Nicklas Millard is a software development engineer in one of the fastest-growing banks, building mission-critical financial services infrastructure.

Previously, he was a Big4 Senior Tech Consultant developing software for commercial clients and government institutions.

New YouTube Channel (@Nicklas Millard)

Connect on LinkedIn