TL;DR notes from articles I read today.

Code less, engineer more

“…But just as we wouldn’t insist that every bridge be built with bespoke girders and bolts, or that all electrical plugs and sockets have their own form factors, we shouldn’t insist on custom-building every part of the designs that we craft.”

• Build only for the pieces that you absolutely must. Identify vendors for pieces you can more efficiently buy off the shelf than to build in-house. Document the rationales of your decisions for future use.
• Encourage the mindset of focusing on the impact of code and not the volume of code written in your team.
• If and when you write a completely new component, share it with everyone in the team and the company. While sharing write about what you made, why you made it and how you did it. This helps in avoiding duplication of efforts but another teammate or another team in the company.
• In your team, encourage & reward reusing code.

Full post here, 6 mins read

Good code reviews, better code reviews

• You can make code reviews better by questioning the maintainability, necessity & impact of code changes in the context of your overall system. Look at abstractions introduced and aim for doing a contextual pass.
• Any good code review avoids opinionated comments/statements. You can make code reviews better by focusing on being empathetic and all-round positive, kind and unassuming.
• Good reviewers leave as many comments and questions as are needed, and prefer connecting with the author in-person, while better reviewers will proactively reach out to the person to avoid any misunderstandings in the first place.
• You can have better coder reviews by looking beyond the errors and trying to figure out the underlying issue.
• Companies with good code reviews ensure that everyone takes part in the code review process. Companies with better code reviews ensure that code just doesn’t make it to production without reviews.

Full post here, 8 mins read

Stop writing crap code

• Stop using else statements as your defaults. As code grows, logic gets complicated and these else statements come to bite you back while debugging code 6-12 months later.
• Take the time to find & use built-in functionality of the language you are using. It will save your code from bloating.
• Each function should have just one job to be done. Don’t hide your logic inside functions.
• Make your code more descriptive by naming things properly, by adding code comments, etc.

Full post here, 4 mins read

Get these notes directly in your inbox every weekday by signing up for my newsletter, in.snippets().