Here are some notes from a book I am reading. It also has some of my own thoughts as well as some tidbits from various other sources. These points are sorted in no particular order.

On Problems

Always provide options and solutions, and not just problems and excuses. Developers can be very good at finding wrong things, be it in a codebase, an organization or a culture. This, no doubt, is a useful skill to possess. Identifying these problems and then providing options to systematically solve these problems is what is appreciated more. The next time you go to your manager with a problem, think about whether you are also being part of the solution.

On Bad Codebases

Don’t live with broken windows. Some day, your house will get ransacked because nobody cared to fix a broken window. There are times when you are working with a less than ideal codebase. Badly designed monoliths, improper dependency management, lack of good unit testing, etc come to mind when you think of horror codebases. When working with such codebases, try not to add to the mess. Try to fix the crack instead of introducing more cracks.

On Big Changes

When you encounter bad code or culture, the natural tendency is to think of wholesale changes. While you want to always keep the bigger picture in mind, start with smaller changes, and get buy-in before asking for more.

On Code Quality

Make code quality a requirements issue. Code to requirements, and test to requirements. When you only need a hut, you do not build a castle, nor do you need to test for a castle.

On Knowledge

Build your knowledge portfolio. Do this by reading often, building diverse skills(don’t put all your eggs in one basket), being on top of emerging trends, getting involved in technology discussions at work or otherwise, and most importantly, reviewing and rebalancing your portfolio. Review as often as feasible to see if you are improving your knowledge portfolio.

On Communication

Communication is extremely important even if your primary job is to code. Know your audience, produce first-class documents of your work and listen to your audience. It’s all about what you say, and how you say it.

On Duplication

Avoid duplication of work. Be it in code, knowledge or documentation. Make it easy to reuse your work. Always think like a platform developer.

On Orthogonal Systems

Build loosely coupled systems. They are usually better tested and less fragile. Changing one part of the system shouldn’t impact another. The degree to which that happens tests the modularity of your design. Create modules that do one thing, and do it well. Create shy code that only exposes what’s needed to be exposed.

On MVPs

Build the smallest thing that provides value and iterate. Building end to end early helps iron out issues. A big bang approach to development rarely works.

On Estimates

Understand and state requirements and assumptions thoroughly before estimating projects. Understand the possible risks, and factor in testing and bugs. Productionazing software takes time.

On Tools

Master the Linux shell. Master your editor. Master a scripting language. These investments will make you very productive over the long run.

On Design

Don’t start until you are ready. Design by contract. Write lazy code that doesn’t do too much, and doesn’t expose too much. Crash as early as possible in the stack. Use assertions liberally. Use a configuration and a metadata-driven approach to design. Always think about concurrency. Close what you open.

On Fixing Bugs

Don’t rely on coincidences or luck. Code should always be deliberate and explainable. Don’t let existing code dictate future work. Don’t rely on magic code. Test state coverage, and not code coverage, i.e make sure all the possible logical states of your code are tested.