5 articles every software engineer should read

Vincent de Lagabbe
Alan Product and Technical Blog
4 min readApr 19, 2023


At Alan we like sharing blog posts and interesting articles. We even have a #meta_reading_list channel on Slack where employees (and our CEO, daily) post links to interesting reads with their key take away.

screenshot of a post of an article shared in the #meta_reading_list channel of Alan slack channel by it’s CEO Jean-Charles Samuelian-Werve. The article talks about hiring questions, JC explains why he shared the article and pings the @talent slack group then lists some of the article questions.
Our CEO sharing an article on our #meta_reading_list channel

Here we share five of engineering’s favorites.

You Are Not Google

by Oz Nova

GAFAM have a unique set of problems created by the massive amount of data and traffic they have to handle

  • They developed specific tooling to tackle these challenges. Your organization probably doesn’t have the same kind of issues
  • You should focus on building systems that meet your own needs rather than trying to emulate Google because “it works for them”
  • Building systems that are too complex or too scalable can lead to wasted time, effort, and resources, and can even harm the organization’s ability to innovate and respond to changing needs.
  • Instead you should build simple systems that can evolve

We are very much in line with this approach, you can read how we approach this here: Boring Tech, Pragmatic Engineering, and Complex Challenges

Write code that is easy to delete, not easy to extend.

by tef

Good code isn’t about getting it right the first time. Good code is just legacy code that doesn’t get in the way.”

  • If you can avoid writing any code: don’t write it
  • Writing code is an iterative process: start simple and add complexity when and where needed
  • You should embrace change and view it as an opportunity to improve rather than trying to anticipate every possible situation
  • You will move faster if it’s easier to remove or replace parts than trying to adapt them

You can read about how we approach refactoring our code to adapt to changing business needs here: What we learned from a large refactoring

The Engineer/Manager Pendulum

by Charity Majors

  • It feels that the only way to get “career progression” for a senior developer is to move to management
  • Instead you should do both. But not simultaneously: do it serially
  • Management experience will help you with priorities, team motivation, delegating tasks, conflict resolution
  • Development experience will help your reverse-engineer how the company works to make it better
  • Companies shouldn’t regard management as a promotion but as a change of role

To know more about how we operate without strict management by using “leads” and “coaches” roles, check out this one: How our engineering teams run without managers

How to tell what level of developer you are, junior to senior

by Jackson Gabbard

  • While developers of all experiences should write maintainable code, collaborate well with others or take ownership of projects, expectations change over time
  • Junior developers are typically early in their careers and focus on learning and executing specific tasks under supervision
  • Mid-Level developers can work independently and are comfortable with a range of programming concepts and technologies.
  • Senior developers have deep technical expertise and can provide guidance and mentorship to less experienced team members
  • Staff developers are highly experienced and can shape the direction of a company’s technical strategy and culture.

To understand how we approach career progression at Alan for developers you can refer to Engineering career path at Alan

Introductory bullshit detection for non-technical managers

by Mike Acton

This one gives many techniques and questions to ask to help non-engineers understand developers project proposals.

It’s also very helpful for individual contributors to:

  • understand what their stakeholders want to know
  • asking themself the right questions when defining a project
  • avoid jargon in their communication

At Alan we expect engineers to write proposals and be challenged by other engineers but also product managers, designers or other stakeholders.

To avoid bullshit when making important product or technical decision we try to stick to a few guidelines you can read about here: Engineering Principles at Alan

We hope you enjoyed this selection! What would you add to the list?