Notes from 6 articles all young developers must read

I share short notes from articles I read on software engineering every day through my newsletter in.snippets. I started doing this towards the second half of last year and shared notes from over 200 articles spanned across 67 editions.

Here are the notes from 6 of those articles that I believe young developers will benefit from.

Before we begin - if growing quickly in your career is on your focus list for 2020, do check out this free ebook I wrote last year: An engineer’s guide to getting more recognition at work.

1. Systems thinking as important as ever for new coders

“Drive a Honda or a Jeep, you'll still need to replace your tires and think about the road you're driving on, on the way to the grocery store.”
Understand how a system works, what are its constituents, how these constituents operate individually and how they interact with other components within your system's context. Know how these components behave when they share, send or request information from other components of the same or a different system. Build a solid understanding of the basics. You can learn any syntax later. That’s the easy part.

Full post here, 4 mins read

2. 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

3. How to ace the coding interview, by an ex-Facebook interviewer

• Don’t rush to write code. Think about the problem first and think out loud.
• Ask as many questions as you have about the problem before starting to solve it.
• Don’t strive to impress with the right answer, talk about all approaches you can take and talk about the tradeoffs with each.
• Plan your solution with pseudocode.
• Talk out loud about what you are doing while implementing the solution.
• Write comprehensive test cases. Pro-tip by the author in case you are stuck: Some of the best problem solving happens when you can align the strength of a specific data structure to a problem’s bottleneck.

Full post here, 8 mins read

4. How is software developed at Amazon?

Key tenets Amazon follows to ensure its obsessive customer focus:

• Decompose a monolithic organization into small, autonomous teams that own each service or product end to end.
• Deploy in a pessimistic fashion, constantly looking for problems.
• Deploy on a small scale, so that you can rollback in case of failure and expand only if successful.
• Start every project with a threat model and have it reviewed by a security engineer; also seek peer feedback before committing to a build.
• Architects do not develop the architecture of a project; developers on each team do.
• Plan from the bottom up, because teams closest to the product know best what the customer wants.
• Accept that keeping teams independent can result in occasional duplication.

Full video here, 41 mins watch time

5. Choose boring technology

• Choose boring (read old and well used) technology for your tech stack because its capabilities, as well as its failures, are well understood. 
• When choosing, you will have both known unknowns & unknown unknowns. Both sets are non-empty for all kinds of technology, boring or not. But the magnitude of unknown unknowns for new shiny technology is significantly larger. 
• Remember that the “best” tool for the job is the one that will be on the “least worst” position for as many of your problems as possible. 
• Mature developers understand that the long-term costs of keeping a system working reliably greatly exceed any inconveniences encountered while building it. 
• In cases when new technology or tool that you must choose overlap or replace things already in use, ensure you migrate old functionality to the new system.   “Mindful choice of technology gives engineering minds real freedom: the freedom to contemplate bigger questions. Technology for its own sake is snake oil.”

Full post here, 8 mins read

6. The fundamental philosophy of debugging

• Get thoroughly familiar with what a working system does.
• Realize that you don’t already know the answer. Don’t try to guess the causes.
• Look at data until you understand what is causing the problem.
• Compare the data that you have with what you know the data from a working system should look like.
• Fix the cause of this anomaly, not the symptoms.

Full post here, 8 mins read

And here is a bonus article #7 for you - Coding practices your future self will love you for. I wrote it last year and it struck quite a chord with many in the Dev community.

What did you read last year that you think young developers will find useful? Share in the comments.