5 articles every software engineer should read
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.
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
- 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
- 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?
