Over the 15+ years of my development career, I have learned several things that significantly increase my effectiveness. In this post, I share those learnings with you.<\/p>\n
Structure:<\/p>\n
This blog post mentions and links valuable concepts that you can explore further as you see fit.<\/p>\n
As developers, we like writing code. Most of us want to be given a nice unambiguous task. A fun technical puzzle to solve without paying attention to the rest of the world.<\/p>\n
Put reasonable effort into making sure that you are solving the right problem. To quote Peter Drucker: There is nothing so useless as doing efficiently that which should not be done at all<\/a>. Gather feedback early and often, typically by continuous delivery to real users. Be<\/a> Agile<\/a>.<\/p>\n Software development is expensive, with the vast majority of the effort of real-world projects typically going into maintenance. Combine this with the goal being user\/business outcomes, the best code is often no code<\/a>. To quote Bill Gates: “Measuring programming progress by lines of code is like measuring aircraft building progress by weight.”<\/p>\n See also: YAGNI<\/a>, KISS<\/a>, The Last Responsible Moment<\/a>.<\/p>\n During the first 5 years of my development career, I thought that software design is for software architects or other people with special roles. I was focused on “getting things done”, and saw software design and practices such as writing tests, as a distraction at best. My code worked, and I was getting a lot of things done. Or so I thought.<\/p>\n Then I read Clean Code<\/a>, by Robert C. Martin<\/a>. This book motivates caring about software design and contains examples and many technical heuristics. The central takeaway of the book is: “The only way to go fast is to go well<\/strong>“. In other words, if you make a mess, it will slow you down<\/a>. See also: TradableQualityHypothesis<\/a>, DesignStaminaHypothesis<\/a><\/p>\n Learning how to write well-designed clean code of course takes time and effort. And when you start, you will be slower and make mistakes. Simple is not Easy<\/a>.<\/p>\n Writing tests tends to be beneficial. There are exceptions, but most of the time, it makes a lot of sense to write automated tests. Writing tests is an example of a best practice.<\/p>\n If you are new to writing tests, just follow the best practice and write tests for everything. When starting, blindly following the best practice will be better than following your own underdeveloped judgment<\/strong>. Over time you will learn how to write tests effectively, and be able to tell the difference between you have messed up, and situations where writing a test is not worth it. You will also start to understand the value tests bring on a more visceral level, by having experienced the decrease in debugging sessions and the worry-free refactoring enabled by your tests. After developing your judgment, you will be able to transcend the best practice<\/strong>.<\/p>\n This advice applies to best practices in any area that you are a junior in. Automated tests are just an example.<\/p>\n One big gotcha is that it is not easy to tell the difference between a sensible best practice and something nonsensical or even counterproductive. This is made more complicated by most existing code being a mess, and by most developers, including “experienced” and “senior” ones, not knowing software design basics. This makes having a good mentor extremely valuable. Barring that, one piece of advice based on my own experiences is to be wary of best practices specific to the community of your language or framework. Look for evergreen advice that has been around for decades.<\/p>\n Our focus will be on technical topics. Many other areas are essential, such as health, happiness, career, and soft skills. Knowing how to avoid a technical pitfall won’t help you if you are sleep deprived and working on the wrong problem for a toxic boss that underpays you.<\/p>\n Write automated tests. Perhaps write tests before the code, such as via Test Driven Development<\/a> (TDD). This makes it easy to verify your code is correct in a repeatable manner, thus saving you from much manual retresting and from debugging sessions.<\/p>\n You think test-first is difficult? Try debug-after.<\/p><\/blockquote>\n Perhaps even more importantly, tests give you the safety net to refactor your code. And continuous refactoring is needed to keep your code clean. Without a reliable test suite, it is all the more likely that your code will rot.<\/p>\n Writing tests is difficult if the design of your code is poor, such as when using inheritance for code reuse, or when using static functions. If on the other hand, you have SOLID<\/a> classes, with no global dependencies, then writing nice tests is not so difficult.<\/p>\n Test design matters because poorly written tests will slow you down. Avoid binding your tests to implementation details of the code under test or to the structure of the system. Avoid overusing Mocks and write better Test Doubles<\/a>.<\/p>\n This is one of those best practices that bring to mind the “Use the Best Practices” section. My advice: do not use inheritance for code reuse at all when you are starting out. It is rarely the right call and can do a lot of harm. Favor composition over inheritance<\/a>.<\/p>\n Write SOLID<\/a> code that is not STUPID<\/a>. There is so much value in understanding these principles and anti-patterns.<\/p>\n Actually create objects. Classes with only static methods are not OO. Try to avoid using static code altogether.<\/p>\n See also: my defense of SOLID<\/a>.<\/p>\n (Functional programming<\/a> is not to be confused with imperative<\/a> structural programming<\/a>.)<\/p>\n This point is not about entriely switching to a functional language. You can benefit from using a functional style in your OO language. Minimize state<\/a>, especially mutable state, and do one thing in your functions<\/a>. See also: functional core, imperative shell<\/a>.<\/p>\n Copy-pasting big chunks of code to multiple places is almost always unwise. Any self-respecting developer soon learns this and starts to follow some form of Don’t Repeat Yourself<\/a> (DRY). Unfortunately, the well-intended pursuit of DRY often leads to overengineering and accidental complexity. This is where the counterpart of DRY comes in: Write Everything Twice (WET). The idea behind WET is to only deduplicate on the third occurrence of duplication.<\/p>\n For a more in-depth look at the costs and benefits of deduplication, see The Fallacy of DRY<\/a>.<\/p>\n Try to write self-documenting code and avoid comments.<\/p>\n Every time you write a comment, you should grimace and feel the failure of your ability of expression. — Robert C. Martin<\/p><\/blockquote>\n Comments are dangerous because they can lie. The code can change without the comment being updated. New code can be added right under the comment. The comment might have been wrong or inaccurate in the first place. When this happens, the comment not only becomes useless, it becomes misleading.<\/p>\n To write self-documenting code:<\/p>\n Clean Code<\/a> by Robert C. Martin has some good rules of thumb about naming and comments.<\/p>\n See also: Recommended Reading for Developers<\/a> by Jeff Atwood<\/p>\n2. Software Design Matters<\/h3>\n
3. Use the BEST Practices<\/h3>\n
Technical Advice for Juniors<\/h2>\n
4. Write Tests<\/h3>\n
5. Do Not Use Inheritance For Code Reuse<\/h3>\n
6. Write Object-Oriented code<\/h3>\n
7. Write Functional Code<\/h3>\n
8. Use Informed Duplication<\/h3>\n
9. Types, Names and Comments<\/h3>\n
\n
\n
Recommended Reading for Juniors<\/h2>\n
Books<\/h3>\n
\n
Blogs<\/h3>\n
\n
Bonus links<\/h2>\n
\n
\n<\/i> Comment and retweet on Twitter
\n<\/a><\/p><\/blockquote>\n