published a great interview with one of the developers participating in the METR study, that was aiming to measure productivity improvements achieved with AI coding tools. As you might already know, the study showed a 19% decrease in productivity when AI coding assistants were used. Abi interviewed one of the engineers who experienced a productivity increase. I would like to see a follow-up with one developer who experienced the slowdown.

gives a great intro to office politics, which is kind of a cliffhanger. Looking forward to more content on pragmatically navigating this tricky but essential topic.

Let’s see if those will come soon.

Now, reading time! 🤓👇

Hire people who give a shit. (4 min)

“Over time interviewing, I’ve found that I mainly screen for one key thing: giving a shit. To be more specific, there’s actually two things to screen for:

1. they give a shit about Scale, and

2. they give a shit about their work in general.”

Audience: Leaders
Value: Learn who (not) to hire
ToT Rating: ⭐⭐🌟

The Politics of Software (8 min)

“I’ve seen far more people tear up when playing Monopoly than Chutes and Ladders (née Snakes and Ladders in England). And by far the game I’ve seen the most crying or near fisticuffs is Risk.

The reason is simple. Chutes and Ladders has prescribed rules from which you can’t deviate. Whereas with Monopoly, the official rules allow for negotiation (e.g. “I’ll waive your rent this round if you waive mine the next time I land on your Boardwalk”). Risk, above all, is rife with negotiated alliances and backstabbing betrayals. In a way, Risk is all about the negotiations. In fact, it’s arguably a game you can’t win if you refuse to form, and occasionally break, alliances.

Workplaces and companies operate similarly.“

Audience: Engineering Leaders
Value: Intro to office politics
ToT Rating: ⭐⭐

Unpacking METR’s findings: Does AI slow developers down? (10 min)

“It's obvious that people should be using models for refactoring, test cases, documentation, and code commenting of existing code to make it more human-readable. These are tasks any model can do today—it's very straightforward, and any company should be using AI for this. But it's the code generation and producing novel functions where things get tricky. There's a reason METR is focusing on research, because it's at the frontier of what models cannot yet quite do, and it's a common failure mode for a lot of models.

What I’m trying to emphasize is that tasks are how people should be approaching this problem. The difference between whether AI speeds you up or slows you down isn’t necessarily about the codebase or the team, it's about what specific tasks you’re using the model for.“

Audience: Software Engineers
Value: Learn why AI is slowing down some developers
ToT Rating: ⭐⭐

Vibe coding is the fast fashion industry of software engineering (5 min)

Patricio Del Boca

“TL;DR: My take on AI for programming and "vibe coding" is that it will do to software engineering what fast fashion did to the clothing industry: flood the market with cheap, low-quality products and excessive waste.“

Audience: Software Engineers
Value: Learn the “bad” of vibe coding
ToT Rating: ⭐⭐

How to be an empathetic manager (without becoming a therapist) (7 min)

“If I believe my recipient is being a bit hyperbolic, I may push back gently to help them see the situation through a different frame.

This is not only kind, but necessary.

If your direct report has an aggrandized extreme view of the situation, this has a real cost. Due to their beliefs, they may act assuming they have a moral high ground for being right, when in fact they have an incorrect or incomplete mental model about the situation.”

Audience: Engineering Managers
Value: Learn how to handle “venting” of your reports
ToT Rating: ⭐

3 toxic engineering leader types (3 min)

The third type is The Proxy. This type doesn’t understand the work, and they don’t try to. They sit in meetings, nod a lot, and then repeat what you said to their boss like it was their idea. When it’s time to present to leadership, they speak for you. When there’s a problem, they vanish. You do the real work. They take the credit. Over time, this gets tiresome. Not because you need applause, but because you need a leader who has your back. The Proxy never does.

Audience: Software Engineers
Value: Learn to recognize toxic leaders
ToT Rating: ⭐

You only need 4 promotions: The step-by-step guide from Junior to Staff+ engineer (6 min)

“I’ve seen firsthand how picking the right architecture expands influence. For example, I redesigned the API for a service by simplifying the routes, following REST principles, and coordinating with downstream teams to unblock their development with mocks. That technical decision about the API helped three teams move in parallel. Technical clarity creates leverage.

Execution matters too. If you're the one who jumps in while others sit on problems for days, you are strategically unblocking people. Influence is earned by showing you are the one who moves things forward.

The last piece is visibility. If people don’t know what you’re doing, it didn’t happen. I’ve made that mistake before. Now, I intentionally share tips about AI, send out updates of discussions with other teams, and use email and Slack to make progress public. It’s not bragging. It’s building trust.”

Audience: Software Engineers
Value: Learn how to grow as an engineer
ToT Rating: ⭐

As my family grows 👶, my free time gets thinner, and it is getting harder to prepare weekly ToT digests. Some part of this preparation goes into creating those short summaries for each article (authored by me, not LLMs).

Limited prep time forced me to rethink this. I thought, instead of spending time writing up a summary, I could just copy a paragraph or two from the source article that caught my attention the most, and use those as the summary/hook 🤔.

• This saves me time in preparing the digest ✅

• Catchy quote from the article itself is better than any summary I can conjure up ✅

Feels like a win-win 🙌

And if I ever feel the need to ramble myself, I can always author an article (like this one, for example).

Time to read, go and check it out below 👇

AI and the Imminent Death of Capitalism (14 min)

“In my mind, we either have AGI or we have jobs. Because, as I said in the above consequences section, any decent AGI means that humans as workers will become an obsolete concept.

Are you familiar with the idea of transitive properties? If A = B and B = C then A = C. Sound familiar?

Our AI companies are trying to create AGI. AGI means we don’t have jobs.

This means, through the magic of transitive properties, that a massive percentage of our economy is frantically working to make certain that no humans have jobs in the future. Which feels awfully weird. And concerning.”

Audience: Anyone really
Value: Learn about the conflict between AGI and capitalism
ToT Rating: ⭐⭐🌟

All You Need Is Feedback (9 min)

“Imagine if your manager gave you one useful piece of feedback every week which you implemented by the following week. Anyone who does this would be an astonishingly high performer, improving in 52 ways every year. If this is manifestly true, its opposite follows naturally: a key reason you aren’t growing is either because you aren’t getting feedback or you aren’t implementing it.“

Audience: All professionals
Value: Use feedback to grow
ToT Rating: ⭐⭐

Team got cut. Scope didn’t (7 min)

Audience: Engineering Leaders
Value: Learn how to handle reduced team capacity
ToT Rating: ⭐

FAANG is over. It’s the MANGO era now 🥭 (3 min)

Article source (tagged substack newsletter if available)

“In 2025, FAANG feels like a time capsule from a different internet. Today’s momentum belongs elsewhere. To be specific, to the builders of intelligence, not only infrastructure. Enter: MANGO. Meta, Apple, Nvidia, Google, OpenAI.
…
For founders, if you’re not building with intelligence at the core, you’re playing last decade’s game, dot com.”

Audience: All tech professionals
Value: Learn about 🥭
ToT Rating: ⭐

10 Leadership Lessons from 10 Years of Parenting (X min)

“When Saanvi got her first couple of teeth, we got the mandate to start brushing from her pediatrician. We tried songs, screen time, books and so many other distractions. Nothing worked for us until… we started brushing with her!

At work, this transformed how I stayed hands-on. Instead of just assigning code cleanup tasks to my team, I started picking up small refactoring tasks myself. When we had a critical production issue, I joined the war room and picked up the “low level” tasks like taking notes and helping with debugging alongside everyone else.

The shift in team dynamics was immediate. Engineers started volunteering for the "unglamorous" infrastructure work because they saw me doing it too.”

Audience: All professionals
Value: Learn how to learn from your kids
ToT Rating: ⭐

See you soon! 👋

Without further ado, let’s go! 🤓

While I was on a break, , solopreneur/author got first revenue traction on his new tool WriteStack. Not only that, but he published exactly how he did it, what mistakes he made, and how you can avoid them.

His publication is a one-man entrepreneurship reality show, and you can not help but cheer for him when you read about his struggles and wins 💪🚀. Here are his latest posts; they are all freshly squeezed from the trenches of a tireless entrepreneur.

• Why 99% of Indie Hackers Fail (And How I Finally Broke the Curse)

• $0 to $400 MRR in Weeks – The Dumb Thing That Finally Worked

• I Burned $70K Before I Learned This Profit Trick (Don’t Be Me)

• How I Turn Strangers Into Paying Customers (My Playbook)

• Using Free Tools Will Keep You Broke

He wins in this digest 🏅

Audience: Entrepreneurs
Value: Learn what not to do when building a product
ToT Rating: ⭐⭐🌟

OpenAI & Meta Distinguished Engineer (IC9) On Working With Zuck, Carmack & Career Growth | Philip Su (1h 20 min podcast 3 min summary) + Work-Life Balance Slows Careers (E9 Engineer, ex-Meta) (10 min)

+

has been popping up in several publications lately.

In ‘s podcast, you get a lot of advice on career growth from someone who has been in the trenches for a long time.

In ‘s newsletter, Philip shares some harsh truths on the costs of both work-life balance and fast career growth.

Rare gem this one 💎

Audience: Software Engineers
Value: Learn from a Meta/OpenAI distinguished engineer
ToT Rating: ⭐⭐🌟

Social Capital: The Compound Interest of Your Engineering Career (7 min)

In this article talks about “social capital”. No matter how good you are at executing work yourself, you will reach a limit at a certain point. You realise your impact is bound by how many people you can rally around your efforts. Now, the ability to gather people around you for a cause is not a given. It’s not guaranteed even if the cause is super cool. It depends quite a lot on this thing called “social capital” that Rafa is describing.

To understand how to build your social capital and why it matters, read this article.

Audience: All tech professionals
Value: Learn how to boost your impact
ToT Rating: ⭐⭐

The Rise of AI workflows (7 min)

With the wide availability of AI tools, chaining those tools into workflows opens tremendous automation possibilities.

What you could never dream of doing with a classic “if/then/else” workflow is now available to build in a matter of hours with tools like n8n.

To emphasise the importance of reading about AI workflows, I will quote - “Automate or be automated.”.

Audience: All tech professionals
Value: Learn about AI workflows
ToT Rating: ⭐⭐

How to Manage your Time as an Engineer ⏱️ (10 min)

Hybrid Hacker

The Pomodoro time management technique was invented when an Italian student in the 1980s used a kitchen timer shaped like a tomato to track his focused work intervals. shares his experience with using the technique and some techniques that it enables.

Audience: Software Engineers
Value: Learn how to manage your time/energy
ToT Rating: ⭐

Till soon! 👋

Even for explaining a “simple” topic, such as load balancing algorithms used storytelling to walk you through all the algorithms through the lens of a small startup. I loved this 😍

It made me think that every system design description, blog post, or whitepaper should be written like this. The best designs are the ones strongly driven and shaped by the business constraints. Business constraints come from stories about the business. Perhaps the business needed to support the virality of celebrity posts, which requires a specific design. Or perhaps data access patterns are very much geographically colocated (think Tinder), which opens up doors to some very specific optimisations that do not apply elsewhere.

There are no good designs without a story. It’s the story that drives designs, so why not share stories always?

How Facebook Live Scaled to a Billion Users (13 min)

Facebook’s Live is one of those crazy-scale systems that needs to be designed on a planet-wide scale. This article will walk you through the core components of Facebook Live and how it deals with flaky connections, virality, and unprecedented scale 🌍.

If you are into system design, this single sentence might be enough to get you interested in this one:

When 1.2 billion users might press play, bad architecture can lead to issues.

Audience: Software Engineers
Value: Learn how Facebook designed its live video 🎥
ToT Rating: ⭐⭐

How Load Balancing Algorithms Really Work (6 min)

I loved this short article 😍. It combines some great tech explanations of load balancing algorithms with engaging storytelling through specific use cases. It is a very unique combination that makes the article content more engaging and relatable. Kudos to 👏.

Audience: Software Engineers
Value: Learn about load balancing
ToT Rating: ⭐⭐

Good struggle vs bad struggle (3 min)

Most engineers have managed to achieve success because they learned to persist through doing hard things. It might start with college/university, where you land in the hardest programs and learn to grind through those. Then at work, programming itself is a series of struggles and hard work to get past those struggles (think of all those hours of reading documentation, learning hard concepts, and debugging).

But not all struggles are the same, and not all of them are good for you. will tell you why in this article.

Audience: All professionals
Value: Learn when it is better to give up
ToT Rating: ⭐⭐

Everything Started with the Promise of Loosely Coupled Systems (6 min)

In this one talks about the pros and cons of event-driven architectures. The usual scenario goes like this: the company adopts a pub-sub solution, everyone starts publishing/consuming events, and before you know it, you end up with a monolith distributed over a queue. This article will give you some good advice on how to avoid this scenario.

The title got me hooked, I looked forward to reading it. However, it felt too much like a bulleted list. I kind of prefer some “color”/narrative even in very tech-heavy articles.

Audience: Software Engineers
Value: Learn when (not) to use event-driven architecture
ToT Rating: ⭐

2025 Guide to Prompt Engineering in your editor for Software Engineers (11 min)

For all of you doing vibe coding/prompt engineering (are these two terms interchangeable now 🤔), this article will aim to multiply your already multiplied productivity.

As if the huge boost you got from agentic coding is not enough by itself 😜

Audience: Software Engineers
Value: Learn how to prompt engineer/vibe code better
ToT Rating: ⭐

Are you still treating your team like a family? (5 min)

When you start with an engineering leadership position, you might fall into a trap of overindexing on not hurting anybody’s feelings or making sure everything is done democratically.

This article will tell you how this can seriously hurt your team and how to avoid it.

Audience: Engineering Managers
Value: Learn how to build high-performing teams
ToT Rating: ⭐

Aaaaaand we are done for today! ✅

See you soon! 🗞️

Are you focusing at all on nurturing your network? 🤔

Are you mindful of the impact non-verbal communication has on the messages you are trying to convey? 🗣️📢

Are you confident enough when making proposals?

If not, go ahead and read at least the first three articles in this digest👇.

Getting People to Listen is a Skill — Here’s Where to Start (7 min)

A big part of communication is non-verbal. There is a famous 7-38-55 rule introduced by Albert Mehrabian stating that tone of voice and body language overwhelmingly impact how your message will land. Albert later clarified that this rule only applies to situations when feelings or attitudes are being communicated. When facts are being conveyed, it’s a different story.

However, when trying to get your message through, simply relying on just conveying facts is probably not the best strategy. Other factors will impact how your message will be received. walks us through five focus areas you should be aware of when trying to communicate important ideas to your stakeholders.

Audience: All professionals
Value: Learn how to talk so people listen
ToT Rating: ⭐⭐

How Confidence Is Self-Fulfilling in High-stakes Conversations (11 min)

I learned the hard way that when presenting proposals to stakeholders, the confidence level that you are emitting is very important. Confidence is contagious. For leaders to accept your proposal, they need to get a good level of confidence from your presentation. If you are not confident in what you are proposing or do not fully believe in it, chances are your stakeholders won’t either.

In this brief article flows nicely on the topic from the previous ☝️ one, and gives you practical tips on how to manage your confidence during high-stakes meetings.

Audience: All professionals
Value: Learn the importance of confidence and how to build it
ToT Rating: ⭐⭐

How to Grow Your Personal Network 🍻 (13 min)

This article makes me ashamed that I am probably giving more attention to nurturing plants on my terrace than nurturing my social network 🫣. Here gives you several clear practices you can use to build up and retain the social network around you.

It might be too structured for some, but it will give you techniques you can use right away 👌. I like it because it makes me think about my relationship with others 🤔.

Audience: All professionals
Value: Learn how to nurture your network
ToT Rating: ⭐⭐

0 to $200 MRR in 40 days (after 600 days of nothing) (3 min)

This brief update from shows the level of persistence it takes to get traction on your solopreneurship voyage. Orel got his first income after 600+ days of trying 😮. Apart from sharing this one just because I am happy for Orel 🙌 🚀, I included it because it contains good short advice on what to focus on and how to persist until you reach the revenue-flowing milestone 📈.

Audience: Software Engineers / Founders
Value: Learn what matters when finding product-market fit
ToT Rating: ⭐

Stack overflow is almost dead (5 min) 💵

This article is paywalled, but the summary at the top gives you an idea of some recent news trends happening. I included it as one of the most loved websites for programmers seems to be on life support at this point. StackOverflow has been losing traction since 2017, roughly, but ChatGPT’s launch cemented its fate.

It served us well 😢

Audience: Software Engineers / Engineering Managers
Value: Learn about the latest trends/news in tech
ToT Rating: ⭐

Top 4 Countries in Europe for Six-Figure Remote Workers (5 min)

Based on ‘s research top four countries in Europe for digital nomads are:

• Croatia 🇭🇷

• Poland 🇵🇱

• Estonia 🇪🇪

• Czechia 🇨🇿

Read the article to learn why.

Audience: Software Engineers
Value: Learn about the best countries in Europe for digital nomads
ToT Rating: ⭐

Be Productively Pessimistic (3 min)

dontbreakprod.com

A brief read on how to use your pessimism in a productive manner - aka premortems. Which reminds me of a quote that appeared in a Nirvana song.

Just because you're paranoid doesn't mean they are not after you.

Audience: Software Engineers
Value: Learn how to anticipate problems before they happen
ToT Rating: ⭐

Why have you been stuck at the Senior level for so long? (X min)

This newsletter has mentioned many times how difficult it can be for engineers to move from senior to senior+ roles. This LinkedIn post touches on this and shares the top five behaviours correlated with successful senior+ engineers and the top five behaviours preventing senior engineers from making that leap.

Audience: Software Engineers
Value: Learn what to (not) do to get past the senior engineer
ToT Rating: ⭐

InfoQ Culture and Methods Trends Report - 2025 (11 min)

InfoQ

Here is InfoQ’s report on the latest trends in culture and methods. Of course, vibe coding landed in the Innovators segment just three months after the term was coined 🧑‍💻

Audience: Software Engineers
Value: Learn about the latest trends
ToT Rating: ⭐

Until next time! 👋

In 2025 my goals are to:

• keep the writing cadence of publishing a digest at least once a week,

• publish some of my original content,

• do at least one guest post on other newsletters and

• grow my audience to 1K+ subscribers.

I thought it might be good to reflect on those. Here is the status so far.

• Cadence at least once a week ✅ (had a two-week break but managed to get back on track; will make a break soon though)

• Original content ✅ (published my first author post on ToT on AI impact on software development)

• Guest post 🚧 (attempted, but did not manage to follow through, will attempt again)

• Audience 🚧 (only 12% of the target, with almost half a year passed 😓)

People judge the average of your achievements, not the cumulative (3 min)

This is a great 3-minute advice on framing your achievements. It is counterintuitive, but listing more achievements can reduce their value as perceived by your audience. This is because people perceive the value as an average of the input you give them, not as an accumulation.

So next time you are bragging, try mentioning your top achievements only, instead of building a huge, comprehensive list. I feel this can be useful for performance reviews, who knows, even pros/cons analysis 🤔

Audience: All professionals
Value: Learn how to frame your achievements better.
ToT Rating: ⭐⭐

Staff archetypes are anti-patterns (10 min)

When an engineer operates within a single team, roles are quite simple to define. Engineers with lower skillsets and experience are juniors, then as you gain more of those, you become a medior, and finally a senior engineer. However, when it comes to staff+ roles, things start to become a bit fuzzy.

shared recently an introduction to the staff role. This created a clear picture of what should be the responsibilities of this role. Out there in the wild, however, there are many deviations from this, and there are roles called “staff” without real staff responsibilities in them. Alex shares how even some well-known archetypes alone are not enough to justify a well-rounded staff role.

Audience: Software Engineers / Staff Engineers / Engineering Managers
Value: Learn the pitfalls of the staff engineer role
ToT Rating: ⭐⭐

The time zones of Engineering Managers (6 min)

This article describes several mindsets that engineering managers (and people in general) can have concerning time. You might always be stuck in the past, overanalyzing past decisions. Or you live very much in the moment and are a great executor focused on what matters today. Or you are focused on the vision, the future, and what will be in the years to come.

states that these modes of thinking are not fixed. You should use them as appropriate, as all of them have utility in certain situations. The article will make you self-reflect, which is good.

Audience: Engineering Managers
Value: Learn which type of EM you are
ToT Rating: ⭐⭐

This engineer tracked his time for more than a year and this is what he learned (7 min)

In this article shares how tracking every minute of his work time for the last two years in 15-minute labeled chunks helped him to be much more productive. This might get you inspired to better track and manage how you are spending your time, which is your most valuable asset. I personally never tried tracking my time, and I have a personal aversion to it (as Luca mentions, some people might).

I like the technique of picking the top three most important things you can do every day and focusing your attention/energy on those. However, I might still try tracking/categorizing time.

Audience: Software Engineers
Value: Learn about time management
ToT Rating: ⭐

What helped me level up in Big Tech (that no one talks about) (5 min)

A very brief and clear overview of different engineering levels. shares what each engineering level operates with and what are the main focus points for it. If you are somewhere between junior and staff engineer, these distinction will be useful for you.

Audience: Software Engineers
Value: Learn about the software engineer level distinctions
ToT Rating: ⭐

Heroic culture is anti-engineering (2 min)

I often skip Luca’s Monday ideas as they are mostly brief notes and not fully developed articles. However, this one I really liked, as it plays with the survivorship bias and talks about how organizations often end up rewarding engineers that put out fires and do duct-taping as opposed to engineers that prevent problems in the first place. This happens mostly because fires are more visible than really good, boring engineering work.

Audience: Software Engineers / Engineering Managers
Value: Learn about firefighter anti-pattern
ToT Rating: ⭐

That’s all, everyone! 🙌

See you soon!

Some context first.

I got hooked on “vibe coding” recently 😬.

This got me excited on two fronts.

• Shipping features. Simply shipping features so fast is addictive. I can sit for days and just ship features to a small product I am building (which I did already 🥲).

• Triggers thinking. Productivity improvements that AI brings to software development make me think about how this productivity improvement can impact the whole software engineering landscape. It is hard to stop your mind from thinking about this and extrapolating in the process.

So this post will be a brain dump 🧠 of my thought process around this.

It will contain some predictions that I am very hesitant to share for two reasons.

• Realm of possibilities. The range of all possible outcomes of AI's impact on software development is quite broad, from complete obsolescence to Jevons’ paradox (mentioned here a lot). Meaning any prediction has a high chance of turning out to be false. This makes writing about this a bit uncomfortable, as I do not want to be proven wrong in the future 🫣 (it will be fun to read this article in 5 years though).

• Expertise. I am far from being an expert on AI. So this could very well end up appearing as ramblings of someone who does not know what the hell he is talking about 🤷‍♂️. I have some expertise in software development, though. That should soften the fall (I hope).

This is what the post will cover.

• 👀 Current situation. We will take a look at the current software development process and see how it works right now. This will give us a base that we can use to do our extrapolating.

• 🤖 Potential future. Here we will start extrapolating. This will already contain some wild and not-so-wild guesses.

• 🫢 Impacted roles. A lot of articles “flirting” with the potential AI future are not very explicit in trying to predict the actual impact (probably due to the same reasons I mentioned above 👆). In this one, we will try to explicitly predict which roles will be impacted and how.

• 💪 Preparing. How can you prepare for the software development shift that AI brings? The first two sections will already be hypotheses with a high chance of being proven wrong. We will go all-in and attach one more section that will speculate on how to prepare for this potential future scenario that might not even happen. Why not? If we are already speculating, let’s speculate all the way! 🎲

Let’s start with the current state of software development.

Where are we right now?

How are we developing software today?

Or perhaps it is more useful to take a year or so in the past as the baseline, as we already have AI impacting software development heavily (especially with startups).

If we look at how software development worked before AI coding tools, it looked kind of like this:

• PM/Designer/UX researcher first works on formulating the idea.

• When there is a clear enough idea for a feature, the PM will define requirements, and the designer will draft a design for the team to work on.

• Finally, a team of engineers picks up the implementation and focuses on shipping it to users.

Where is the bottleneck?

How we build software right now contains an inherent bottleneck.

This is what is often referred to as the “maker-to-decider gap”.

The "maker-to-decider gap" term describes a well-recognized imbalance:

“One "decider" (PM, designer, or exec) can define work far faster than multiple "makers" (engineers, QA, infra) can build and ship it.”

The idea is:

• It's relatively cheap and fast to come up with ideas, designs, strategies, or product specs.

• It's slow and expensive to translate those into real, working, production-quality software.

So, implementing software has been generally slow so far.

How are we addressing the bottleneck?

So far, as implementing software has been generally slow compared to other activities involved, we were solving this by throwing more manpower at the bottleneck.

This bottleneck, combined with the huge demand for more software, is what has put software engineers in a very favourable position, compared to other professions.

There was no other way to solve the bottleneck than to throw money at it 💰. And if bags of money are being thrown somewhere, this is where you want to be.

Of course, this is not without limits. There is a limit to how much additional manpower will keep helping before it starts to slow things down. This is expressed through the famous Brooks’ law (read the seminal “The Mythical Man-Month” for more on this).

“Adding manpower to a late software project makes it later.”

Brooks argued that one of the main contributors to the fact that the addition of manpower starts to slow down software projects at a certain threshold is the communication overhead. We will come back to this later in the article.

So, in summary, the current state is described below.

• ✅ Roughly speaking, software development consists of activities that define what needs to be built and activities that build it (implementation).

• ✅ So far, the main bottleneck has been on the implementation side.

• ✅ We have been solving this by throwing more people (engineers) at the bottleneck.

• ✅ This created an imbalance between the “deciders” and “makers”.

Value / Cost ratio

We will digress a bit now to talk about the value/cost ratio.

Roughly speaking, whenever we are doing product development, two activities are happening all the time:

• Betting. We are determining what the right bets to focus on are. We want to choose the most valuable features for our customers to maximise the value we create.

• Delivering. We are delivering on those bets, shipping code to production, and getting that value in the hands of customers.

Both of these activities are important for an organization to be successful.

If we are not betting on the right things and wrongly estimate the potential value for the customer, then it does not matter how fast we ship it. If the product is not valuable, flawless delivery does not do anything.

On the other hand, if our delivery is very slow, we will not be successful either. If we are not able to get anything in the customer’s hands in a reasonable amount of time, or with a reasonable amount of quality, no matter how much potential the bet has, that potential will never be realised.

To summarise, product development roughly speaking comes down to:

• determining the right bets and

• executing on those bets.

To be successful, both of those need to align well.

Some inherent biases that are making it harder for organizations to be successful are:

• builders are often overly-optimistic when estimating the time it takes to build something and

• deciders are often overly-optimistic when estimating the value of a specific bet (this one is often overlooked).

Bottleneck shift

Today, we already have many AI-powered, agentic coding tools (Cursor, Windsurf, etc). These tools are already making a huge impact on software development in the startup segment, where rapid bootstrapping of greenfield MVPs to reach product-market fit is paramount. Engineers in this segment are reporting 10x gains in productivity.

I was vibe-coding an app recently, and it was ridiculously easy to keep adding features.

Segment where AI coding tools are not best at (yet) is working with existing, large codebases.

At this point, we can make our first guess.

Guess 1: AI coding tools will work flawlessly with existing, large codebases.

If we assume the above, it would follow that shipping features will become less costly.

As the product development process involves not only implementing software, but also the “betting” activities that “deciders” are working on, we need to look at it as a whole to extrapolate how things might change in the future.

It’s important to note that it is not only the implementation phase that is getting productivity boosts from AI.

The definition phase is getting faster as well.

Right now, there is a rough ratio of how much time it takes to define what to build vs how much time it takes to build it.

Let’s call it the F/B ratio for simplicity.

F/B ratio has been somewhat stable in the last decades. Software development has been consistently “slow” compared to deciding what to build, so the ratio did not change much.

Now, with the AI-powered productivity gains, things can branch out differently depending on how much productivity gains both of these activities will receive from AI assistance.

Guess 1.1: AI will introduce exactly the same rate of productivity improvements both for “defining” and for “building” activities.

If productivity gains both on the “defining” and on the “building” fronts are the same, it means the F/B ratio stays the same. Which means the bottleneck stays where it was so far, in the implementation phase.

Now, it’s important to note that there are two areas where we can focus our predictions.

• How will the software development process and organizations doing it be impacted by AI?

• How will the software economy in general be impacted by AI?

For now, we will focus on how processes and organizations doing software development might change.

In the 1.1 scenario, the process and the organizations around software development remain the least impacted of all scenarios. If the F/B ratio remains unchanged, you will still need to structure your processes and organizations similarly they are structured now to optimise software development.

Having the same productivity gains both for “defining” and “building” activities seems like a highly unlikely scenario. This is because these activities are inherently different. They consist of different sub-activities, and the amount of manual work prone to automation involved in them is different.

Which leads us to the next guess.

Guess 1.2: AI will introduce bigger productivity improvements for “building” and equalise how much time it takes to define something to how much time it takes to build it.

If “building” becomes equally expensive as “defining”, it means that we don’t need to throw that much money at “building”. We would roughly need an equal amount of “deciders” and “builders” to have an optimal process.

This also means that the money saved on building can be reinvested into having more decider/builder pairs so we can deliver more software.

Now, here we can take another step and even explore the scenario below.

Guess 1.3: Productivity gains in “building” will be so drastic that it will become much simpler to build than to define what exactly to build.

So roughly speaking, with the above two guesses, we are exploring a scenario where productivity gains both in “defining” and “building” activities are high, and building becomes equal to or less expensive than defining.

Where will the bottleneck be then?

One clear bottleneck is users of the product itself.
You can not just ship features infinitely fast and expect that to pay off. You can not release something at 2 pm and then release a completely revamped version of it at 3 pm and then decide to drop it and ship something completely different at 4 pm. Software adoption takes time, and measuring the adoption and success of features takes time because there are humans involved.

There is another bottleneck, though. So far, the slowdown has always been caused by the manual work. By “manual” here, I am referring to coding or UX designing activities. The activities that involve a person producing some digital artefact via some form of a language (programming language or design language). If we assume that these activities have drastic productivity improvements, then the remaining bottleneck might now lie in human communication.

Merge of “deciders” and “builders”

As building stuff and producing artefacts become simpler, communication between people is the remaining source of slowness.

Which could lead to the merge of “deciders” and “builders”.

If things are simple to ship, no decider will bother to communicate their vision to another builder and then wait for the builder to build it - they will just ship it themselves.

The other way around as well, if building is simple, then a lot of builders will exercise their “deciding” abilities that they never had a chance to do before. And the risk of failing will be smaller as they will not invest as much effort as before in testing their hypotheses. And as they test their bets more and more, their “deciding” intuition will improve over time.

This leads to the scenario where everyone is a CEO (something wrote about here).

Let’s elaborate a bit more, why a “merge”, if it becomes feasible, would be beneficial. Right now, there is a lot of back and forth between the person defining the requirements and the engineers who are implementing those requirements. Most of this is because a lot of context needs to be transferred from the PM’s brain to the engineer’s brain. There is a quote from (the creator of the event storming technique) that goes like this:

It’s developer (mis)understanding that’s released in production, not the experts’ knowledge.

If only one brain 🧠 handles everything, full context will be with the builder from the get-go. Then the experts’ knowledge will go to production. A nice example of this is GIT, where Linus acts both as a “PM” and as an engineer, leading to one of the most successful pieces of software ever built.

Ok, those are the guesses we will cover for now ✅ .

Note that there is also a potential future where defining work becomes much faster than executing it. We will not explore this alternative here. Both because I perceive it as less likely (due to a lot of manual work that is happening in the execution phase right now) and because in that scenario execution remains a bottleneck and the assumption is that money will keep pouring there, so it is a “good” scenario for software engineers and I will skip it.

Who will be impacted?

From the above guesswork, we can extrapolate who will be impacted by these changes.

• Software engineers who lack customer-centricity, product mindset (whether their customer is an end user or another engineer in their org, or their product is a SaaS tool or an internal platform), system design skills, and are solely focused on execution/coding. If you are basing your career simply on your ability to know a programming language and write code, that skillset alone might not cut it in this era.

• Product managers simply because when the “merge” starts happening, there will be more engineers than PMs competing for the new merged role. This is due to the above-mentioned imbalance created by the maker-to-decider gap. Not saying that all PMs will be gone, but those that will not be able to ship things themselves might be heavily impacted, as they will be going against more competition from engineers.

Impact on the economy of software

If we are talking about the software economy as a whole, several scenarios are being thrown around. Often, they are mentioned in some mutually exclusive either/or manner. I believe all of those will happen to a degree. Here are some I observed being mentioned.

• Everyone who is building software right now will keep building it. They will do it faster, so they will produce more of it. In addition to that, there is a segment of people who never considered building software before, but will consider it now, as building becomes more available. More software will come from them as well. So, more software all around! 🚀

• One scenario that comes up is that, because it becomes cheaper to build software, we will simply be building the same amount of it cheaper, and cut costs by cutting extra manpower. Some reject that this will happen, however, there are companies where exactly this might happen due to the nature of the role that software plays for that company.

• In another scenario, a term called Jevons’ paradox pops up that states that the reduction in the price of a resource may, counterintuitively, yield higher demand for the resource. Mainly because the resource (in our case software engineer) becomes more widely available to consumers who could not afford it before. Think about all those friends you have who asked you to build them an app for an idea they had, because they could not build or fund it. Some segment of those people will get into the software economy now, either directly as a vibe-coder or as an investor (as building is accessible to them now).

• As building software becomes cheaper, some bets that were too ambitious before and did not have a good enough value/cost ratio might get prioritised now. Meaning, again, more demand for builders to work on those ambitious projects.

• Software should become more awesome, as we can build faster, we can iterate on feedback faster, and evolve it like we never could before. Also, who knows what those more ambitious projects will yield.

How to prepare?

For both software engineers and PMs, the preparation for the future could look the same.

• Go and vibe-code an app you've always wanted to build 👩‍💻 🚀

It can be a small note-taking app for yourself, or a game you always wanted to create, but never had time for 💪.

As an engineer, building your product will put you in the driver’s seat and force you to think about how to market your product, how to get feedback, how to monetize it, etc. Perhaps you will even be inspired to read a book about marketing or finding a product market fit. Be the CEO of your own company.

As a PM, it will finally give you that superpower that in the past required a dependency on someone else. In all honesty, from my experience, agentic coding tools (although amazing) might not be fully there yet to support someone with exactly zero knowledge on how to build software. But I would recommend at least trying to see where this leads you. I am basing this on the fact that in the last app I was building, I think 95% of my prompts were PM prompts.

Final words

Ok, that was a lot for a first ToT article I fully authored.

I am very curious to hear your thought process around this topic.
If you believe that some of the guesses do not make sense and you have your own, do drop them in the comments 💬.
I would like to learn more about how you think about this.

All that guessing is tiring 😓.
I will go back to the relaxing vibes of shipping features now ☕ 🧑‍💻

See you soon! 👋

So grab a coffee and sharpen those architectural skills ☕ 👀.

How Halo on Xbox Scaled to 10+ Million Players using the Saga Pattern (15 min)

The Saga pattern is not something that often comes up. This article will first introduce you to this important architectural pattern and then walk you through how the Halo team on Xbox implemented this pattern. One interesting note is that instead of using the backward recovery mechanism (where you undo all successful sub-transactions and then try the whole saga again), they used forward recovery, where they just retry (with a backoff) the sub-transactions that failed/remained.

Audience: Software Engineers
Value: Learn about the Saga pattern
ToT Rating: ⭐⭐

Why You Can’t Ignore Change Data Capture in Event-Driven Architectures (7 min)

A nice introduction to the Change Data Capture architectural pattern. goes into making a distinction between the CDC and business events. The distinction is very important to know, so do not miss it if you have microservices that need to keep data in sync.

Audience: Software Engineers
Value: Learn about the Change Data Capture pattern
ToT Rating: ⭐⭐

What you give airtime to will expand (6 min)

This brief article contains a simple message - focus the attention of your listeners towards what you can do, not towards what you can not. Once again gives very practical advice (with multiple examples) on how to communicate more effectively. This technique will help you get your message across and emit the aura of someone who can get things done.

Audience: All professionals
Value: Learn how to sound more positive when communicating
ToT Rating: ⭐⭐

Are You a Hero Engineering Manager? (And Why It’s a Problem) (8 min)

A lot of new managers fall into the trap of playing the role of a hero for their team. They save the day by making the toughest technical decisions, they protect their team’s focus from all the distractions happening around them, and fight to the death for raises and PTO days. In this article will tell you why those behaviours can be harmful and how you can avoid them.

Audience: Engineering Managers
Value: Learn how not to overprotect your team
ToT Rating: ⭐

What’s Changed in 50 Years of Computing: Part 4 (9 min)

This is the fourth part covering the seminal book “The Mythical Man-Month” by Fred Brooks. If you do not have time to read the book, this series of articles could be good enough to cover the main ideas expressed there. For me, the book was a time machine into how software was built 50 years ago. The most fun parts were the ones that describe the same problems we are facing even now, half a century later 😅

Audience: Software Engineers / Engineering Managers
Value: Learn how software was built half a century ago
ToT Rating: ⭐

That’s all for this Thursday, see you soon! 👋

I hope these will inspire you to go search for those most impactful opportunities and get around boilerplate processes to get them done quickly 🚀

How I Grew From Engineer to CTO (17 min)

shares his road from a junior software engineer without a CS degree to the CTO. Gregor shares that these three things can skyrocket your career much faster than a CS degree: a sense of ownership and responsibility, drive and motivation for improving, and being a team player and making others around you better. This theme came up in some articles we’ve been reading before, and I call this “hyper-proactivity”.

Audience: Software Engineers / Engineering Managers
Value: Learn about the path to CTO
ToT Rating: ⭐

How To Drive Exceptional Performance With Exceptions (8 min)

In this one, talks about avoiding being bound by organizational constraints when those stifle great outcomes. By properly asking for an exception, you can deliver value faster and be more successful. When you are following a process that someone established long ago, think twice. There might be an opportunity there to “cut some fat” and ship value much faster.

Audience: Engineering Leaders
Value: Learn how to skip process overhead properly
ToT Rating: ⭐

Introduction to Sociotechnical Architecture: Why & What is it (10 min)

Eduardo De Silva

In the last InfoQ Software Architecture and Design Trends Report, one term that popped up in the Early Adopters segment is “socio-technical architecture”.

The term “Socio-Technical System” was coined in WW2 era and is getting more and more traction lately. This article will give you an introduction to this term.

Audience: Software Engineers / Architects / Engineering Leaders
Value: Learn about socio-technical architecture
ToT Rating: ⭐⭐

How DNS Works (3 min)

In 3 minutes of your time, this article will describe the whole DNS system architecture 🌐. You will learn what are resolver, toot, TLD and an authoritative name servers.

Audience: Software Engineers
Value: Learn how DNS works
ToT Rating: ⭐

That was short and sweet ✅

See you soon!

I was quite busy on the personal front, and the newsletter took a hit 😔. I also got addicted to vibe coding, which probably contributed as well 😬.

I learned so much by going over top tech newsletters and summarising them that it became an addiction at this point. I feel bad when I am not doing that 🙂.

Two themes are emerging in this one. Learning how to stay relevant in the age of AI and how to manage your career with the right expectations at senior+ positions.

Top of the Tech is back! 💪 Read on!

How to avoid sleepwalking into irrelevance in the age of AI (6 min)

We are all riding the AI wave, whether we are aware of that or not. shares her thoughts about what you can do to stay on top and not get thrown to the sidelines. If you are aware of OpenAI’s five-stage roadmap to AGI, one of ‘s thoughts that resonates well with that is that you should start “thinking like a CEO”. Which makes perfect sense if we have agents that are “organizational equivalents”.

Audience: All tech professionals
Value: Learn how to stay on top of the AI wave 🌊
ToT Rating: ⭐⭐

13 Tech Career Misconceptions — Things I Wish I'd Learned Earlier (9 min)

The free version of this article by has 4 misconceptions that are very common in the engineering industry. If you think that you should be rewarded for doing hard things, or you think your career is limited by the opportunities you get from your manager, you should read this one 🚿😉.

Audience: Software Engineers / Engineering Managers
Value: Learn about misconceptions that are blocking your career growth
ToT Rating: ⭐⭐

Your Career Growth Is Not Your Manager's Top Priority - And What To Do About It (7 min)

This article blends well with ‘s article above ☝️. It shares three realities you must acknowledge at senior+ positions.

• 💡 Your manager is no longer an expert in your domain; thus, his ability to teach you specific expertise is limited.

• 💡 Your work goes beyond the boundaries of your team.

• 💡 Your manager no longer controls your opportunities, nor can he provide them for you.

Audience: All tech professionals
Value: Learn harsh realities of senior+ career growth
ToT Rating: ⭐⭐

The Importance of Writing in the Engineering Industry (7 min) 💵

Writing is an essential skill for tech professionals as you reach a certain seniority. A lot of your work boils down to communicating ideas to your peers (think Slack, emails, PR reviews, tech designs, etc.). People who communicate ideas well can make a bigger impact than people who do not. That’s why good writing skills give you an edge. The article is paywalled, but the free part still conveys the importance of writing well.

Audience: Software Engineers / Engineering Managers
Value: Learn the importance of writing
ToT Rating: ⭐

Vibe-coding workflows (13 min)

I recently got addicted to vibe coding. I used Windsurf and was blown away by the power of agentic coding. This article walks you through a vibe coding workflow and some stages you can follow by using ‘s example prompts. Vibe coding I did so far was mostly on a greenfield project and did not require any special workflow. The tool was simply amazing at delivering features. I wrote zero code myself (if we exclude adding some API keys and secrets in configs), and 95% of my prompts were PM prompts, not engineering ones.

Although the article contains a lot of prompt examples, I feel that it would work better if it were a video of doing live coding and explaining the workflow.

Audience: Software Engineers
Value: Learn how to vibe code as a pro
ToT Rating: ⭐

Avoiding Skill Atrophy in the Age of AI (15 min)

This article by is somewhat touching a similar topic as the one on top ☝️ from . How software is being developed is changing rapidly. And more and more of the craft is being done by AI. Addy talks about inevitable skills atrophy that comes with that. If you don’t use it, you lose it.

I would be very curious to re-read these articles in a year or two, and see which one of them held up the best.

Audience: Software Engineers
Value: Learn how not to lose your critical thinking
ToT Rating: ⭐

Thanks for reading, and see you soon! 👋

Read on 🖖

Less Is More: How to Cut Features Without Losing Impact (4 min)

More content on cutting scope! 😍 Engineers often accept enormous feature scope without questioning why it needs to be delivered and what value it will bring for users. Further, some even tend to delegate all decision-making on scope to be delivered to product managers. This mindset does not make teams successful and does not maximize their impact. We all know that engineers tend to be overly optimistic when estimating effort. However, shares a critical insight as well - PMs are excessively optimistic when evaluating the value of a feature.

This article will give you a simple, actionable framework you can use to fight these biases of everyone involved.

Audience: Software Engineers / Engineering Managers / Product Managers
Value: Learn why and how to cut scope
ToT Rating: ⭐⭐

How to Stop the Feature Factory (7 min) 💵

This is a paywalled article on how to deal with being in a feature factory. The article first gives you some indicators you can use to determine if you are in a feature factory. It then goes on to explain the impact new features have on your team’s capacity. This is best explained with this neat chart below 😍.

Audience: Engineering Managers / Software Engineers
Value: Learn the residual cost of features
ToT Rating: ⭐⭐

What High Performers Know About Doing Hard Things (X min)

If you struggle with procrastination and especially with delaying hard but important tasks, this article is for you. shares how plowing through hard tasks rewires your brain 🧠 and makes it stronger. She shares six tips high performers do to get through difficult tasks. However, just the fact that you learned that plowing through hard work will make your brain stronger should boost your motivation to get things done 💪.

Audience: Software Engineers
Value: Learn the value of doing hard things
ToT Rating: ⭐⭐

Binstack: Making a maximal multi-dimensional decision (18 min)

A Smart Bear

Above, we mentioned the tendency of PMs to be excessively optimistic about the value of a feature. This article will not help PMs to determine the exact value of their features. However, it will give them a framework (nicknamed Binstack) for evaluating which features are most impactful. Additionally, it will force PMs to think about what “impactful” means right now at the current stage of their company/

Audience: Product Managers / Engineering Managers
Value: Learn how to determine the most impactful feature
ToT Rating: ⭐

5 AI tools to build to be a better Engineering Leader in 2025 (10 min)

In this article gives you five use cases for building your own AI agent that will help you both:

• “scratch your itch” and

• learn about LLMs.

Audience: Engineering Managers
Value: Learn good use cases for building LLM tooling
ToT Rating: ⭐

One Hidden Skill That Makes You Thrive in Tech (Hint: It’s Not Coding) (4 min)

Your coding skills are amazing. You design perfect, scalable, and neat systems. However, you still feel your career is stuck. Perhaps your non-technical skills are to blame? Every engineer operates in a sociotechnical system, and in such systems, the “socio” part matters a lot. Read about the value of social capital for engineers.

Audience: Software Engineers
Value: Learn why social capital is important for engineers
ToT Rating: ⭐

How To Convince Others That You Are Qualified and Ready To Lead (You Know You Are!) (6 min)

This article talks about how framing your accomplishments in a way that will maximise perception of your leadership abilities. shares three tactics you can use during your performance reviews or interviews for leadership positions. One sentence that resonated well with me is:

Pivot your story from “how you execute given constraints” to “how you set constraints for others to do their best work”.

This one summarizes well the difference between an individual contributor and a manager.

• As an IC, you are bounded by all kinds of constraints (slow CI/CD, siloed teams, lack of clear requirements, etc.), and you are then trying to make the best possible impact within your given constraints.

• As a manager, you are the one responsible for tweaking the constraints in such a way so that your ICs can have the best possible impact.

Audience: Software Engineers
Value: Learn how to frame your leadership impact well
ToT Rating: ⭐

See you soon, rock on 🚀

There are two great reads on engineering communication to sharpen your communication toolbox. The top one is super short and super-concrete 😍 so jump right in.

Use "but" strategically (6 min)

This is one of those gems 💎 on communication that will take only 6 minutes to give you super practical advice you can start using immediately. You will learn how to use “but” in a smart way. As “but” has this magical power to cancel (or soften) everything that comes before it, shares a tip to put the thing you want softened before the “but”. All is explained through very simple examples, so read on.

Audience: All professionals
Value: Improve how you communicate feedback
ToT Rating: ⭐⭐🌟

How Linux is built with Greg Kroah-Hartman (10 min read, 1h 21 mins podcast)

Linux is probably one of the most successful pieces of software out there. It powers mobile phones, servers, routers, smart TVs, cars, it’s even used in the International freaking Space Station 🤯. If you want to learn more about how Linux is being built, read/watch/listen to this episode with one of the 3 Linux Kernel Foundation Fellows (the other two are Linus Torvalds and Shuah Khan).

Audience: Software Engineers
Value: Learn the development process of Linux
ToT Rating: ⭐⭐

Why I'm No Longer Talking to Architects About Microservices (7 min)

Ian Miell

The term microservice is almost 15 years old 🤯👴. It is quite funny to read that in 2025, still no one agrees on what "microservice" means. This article talks about challenges engineers can face when discussing microservices. It is a bit of a digression, but I found this quote from the article that reflects on the origins of the term “DevOps” and its current usage hilarious:

• DevOps

  • Originally a rejection of the standard separation of development and operation teams, it became perfectly normal to talk about separate and centralised ‘DevOps teams’ centred around deployment tooling

Audience: Software Engineers / Software Architects
Value: Learn about the problems of microservices
ToT Rating: ⭐⭐

Bluesky: The Decentralized Social Media App with 30 Million Users (12 min)

Bluesky is a social platform that is a bit more than 2 years old. Their motto is that “Social media is too important to be controlled by a few corporations” and their architecture reflects this. It enables users to decide where their social media content is stored and how they will view the content of other users. Decentralizing a social network is not a simple engineering feat and this article will tell you all about the complexities involved.

Audience: Software Engineers
Value: Learn about the architecture of Bluesky
ToT Rating: ⭐⭐

What engineers get wrong about communication (11 min)

Engineers can sometimes fall into certain communication patterns that lead to undesired outcomes. They can get caught up in technical details so much to completely forget why they are building what they are building. They forget about customers, which almost always leads to unsuccessful projects.

Some might hoard knowledge, which leads to a high bus factor and bad team culture.

Often, I see examples where an engineer feels that their job is only to surface data and that decisions should be made by EMs or PMs. So they draft large documents with a tremendous amount of information and zero opinions.

It also happens that engineers are not making sure to “bring everyone along” when communicating. They communicate as if everyone in the audience has the same amount of context as they do.

This article is a good digest of all those communication traps that engineers often fall into.

Audience: Software Engineers
Value: Improve your communication as an engineer
ToT Rating: ⭐⭐

Revisiting the Minimum Viable Product strategy and its strengths/weaknesses (12 min)

If you’ve read a few of my recent digests, you might have noticed that I am a fan of brutally de-scoping MVPs and measuring success via metrics. With the massive success of LLMs that require huge investments, effort, and time, the MVP strategy gets questioned a lot these days. I love reading content that challenges the opinions I hold, and this article is one of those. Read all about how MVP strategy can be harmful. The article is a reflection on an interview with DoorDash’s CEO.

Audience: Product Managers / Engineering Managers
Value: Learn about the weaknesses of MVP strategy
ToT Rating: ⭐

How vibe coding will affect Engineering Managers (11 min)

Vibe coding is the hot term these days. LLMs are transforming how software is created rapidly, and it is not clear how coding will look in the next several years. is attempting to extrapolate from today and give you his best guess on how vibe coding will impact our industry.

Audience: Engineering Managers
Value: Read about the impact of vibe coding on software engineering
ToT Rating: ⭐

See you soon! 😎

I am always on the lookout for great tech content. If you know great newsletter/blog authors drop a comment 💬 I will make sure to take it into account. Every piece of good engineering content will make this digest more valuable.

Being an Engineering Manager at Flo (10 min)

In this article and share some great insights from their time working at Flo. The article is packed with practical advice coming from their real-world experience. It covers Flo’s engineering structure, A/B testing challenges, and platformization efforts.

The article contains a beautiful example of an “Inverse Conway Maneuver”. Flo is a health mobile app. Shipping apps to users frequently is hard. However, shipping backend code frequently can be done much faster. So to increase their delivery speed, they formed teams with more backend engineers and fewer mobile engineers. This incentivizes architecture decisions that move more logic to the backend 👌🌟. Simple & beautiful, love it 😍

Audience: Software Engineers / Engineering Managers
Value: Learn great tech practices from the trenches
ToT Rating: ⭐⭐🌟

Knowing where your engineer salary comes from (8 min)

Sean Goedecke

Engineers tend to be disconnected from the business models of their companies. We focus on writing clean code, making sleek designs, and doing smart optimizations 🧑‍💻. Seldom do we ask ourselves whether our work brings enough money to pay for our salaries 🤔 🫰.

If you look at your team of engineers, and add up all their yearly salaries, you will probably get quite a large number (let’s mark it with X). You should ask yourself “How is my team contributing X+ to the company’s ARR?”. If you do not have a clear answer to that (ideally supported by numbers and metrics) your job might not be that stable 😬.

This article gives you a good framework to think about the value that you are bringing to your company.

Audience: Software Engineers
Value: Learn how your engineering work brings money to the company
ToT Rating: ⭐⭐🌟

A Production Incident is an Opportunity for You (6 min)

Production incidents are usually not something engineers view as great career opportunities. Usually focus is on driving impactful initiatives. This article will show you how you can use incidents to your advantage and bring benefits both for your company and for your career.

As it is focused on finding a way to thrive in incidents it reminds me of a quote from another article “Why Firefighting Ruins Your Company“.

It easily leads to a culture where the normal, day-to-day work is not taken quite as serious as it should and people are almost waiting for things to be escalated, the task force formed and fun starting. Rather than focusing on the root causes of escalations and making changes to architectures, processes, ways of working and the culture to avoid escalations in the future, the company spirals down a path where escalations, crises and task forces become the normal way of operating.

To be very clear ‘s article is not promoting the above culture (there is even a big disclaimer on top of the article on that.

Audience: Software Engineers
Value: Learn how to use production incidents to your advantage
ToT Rating: ⭐⭐

The Power of Reframing To Change Your Career Trajectory (9 min)

Our brains are inevitably filled with biases, wrong assumptions, and negative emotions. All these quirks are not helping us to think rationally and find the best way forward. We often tend to frame situations much more negative than what they are. We see potential opportunities as dreadful challenges, potential collaborations as fierce competition, and we fear change.

This way of thinking can lead us to spend effort in the wrong direction and miss valuable opportunities coming our way. In this article talks about how building a positive mindset can impact your career perhaps even more than any other self-improvement you can do.

Audience: All professionals
Value: Learn how changing your mindset can create different outcomes
ToT Rating: ⭐

You Have Metrics — Now What? (11 min)

A few digests back we had an article on setting up DX Core 4 metrics to measure developer productivity in your engineering organization. In this one describes how to use those metrics once you have them. She makes a good distinction between diagnostic and improvement metrics which will help you with making an action plan for acting on the results of measuring productivity.

Audience: Engineering Managers / DevEx
Value: Learn how to use developer productivity metrics
ToT Rating: ⭐

Stop being so nice (5 min)

Engineering managers (especially the ones new in the role) tend to measure their success by how much their reports like them. This mindset will affect your team negatively for many reasons and this article by will explain all of those.

Audience: Engineering Managers
Value: Learn why being nice is not nice for your team
ToT Rating: ⭐

That’s all for today! ✅

See you soon!

If you are reading this newsletter, you are in some way connected to software engineers and thus you probably know how bad software engineers are with estimates. Properly estimating a project is hard, and things like Parkinson’s law even make you question if there is a “proper” estimate at all.

To avoid overthinking and analysis paralysis on this, read the below article that will give you a practical checklist you can use to inform your estimate better.

Estimating Invisible Work (8 min)

This article reminds me of this quote:

Even a perfect estimate, if it existed, would be too low 50% of the time.

We are usually terrible with estimates; there is no news there. This article will give you some structure you can use to fight estimates' two worst enemies: overconfidence and Parkinson’s Law.

Audience: Software Engineers
Value: Learn how to make better estimates
ToT Rating: ⭐⭐

How to optimize for career growth - Engineers who win know this is holding them back (5 min)

Imagine this situation: you are coding, and you want to run a unit test, but it does not work locally due to some weird error. You don’t have time right now to fix it. You just push the change to Github and wait for the whole pipeline to complete to give you feedback on whether the test is good or not. You lose some time, but that’s ok 🤷. After a few days you are in the same situation. Again, you don’t have time, and use the whole pipeline to get the feedback. You lose a bit more time. Next thing you know you wasted 10x more time than the time it would take you to fix the damn tests on your local machine. Not only that, but you also compensate for the time lost by putting in extra hours.

This article talks about the huge compound value of small optimizations you can do in your development workflow.

Audience: Software Engineers
Value: Learn why optimizing how you work matters
ToT Rating: ⭐⭐

How GitHub engineers learn new codebases (5 min)

github.blog

If you want to grow your impact and influence as a software engineer, chances are you will need to operate with many different codebases. Getting your head around new code is not easy and it takes time and effort. This article will give you strategies you can use for learning new code (+ a markdown template for discovering new code).

Audience: Software Engineers
Value: Learn how to learn new codebases
ToT Rating: ⭐

All done for today! 👏

Vibe coding, some thoughts and predictions (11 min)

Last digest included a video introducing Manus - an AI agent going viral in China. That was a brief introduction into the latest AI agents. In this article shares his perspective of the current AI landscape and makes predictions on a topic we are all interested in - how AI will transform software engineering.

Audience: Software Engineers / Engineering Managers
Value: Learn how AI will transform software engineering
ToT Rating: ⭐⭐🌟

How Engineering Teams are Using AI (13 min)

This is one of the three articles in this digest mentioning “vibe coding” - the term introduced by Andrej Karpathy this February. There is definitelly hype forming around this. Similar to the above article in this one talks about AI impact on software engineering as well. And again both articles mention Jevons paradox - an economic concept I just learned that might save software engineers from an agentic AI doom.

Audience: Software Engineers
Value: Learn about AI in software engineering
ToT Rating: ⭐⭐

Why I decided to quit a Director's job (X min)

Two digests ago we had an article on the dark sides of solopreneurship, last digest contained one on the similar topic but from a more positive perspective. In this one shares the “why” behind embarking on his solopreneurship journey.

Audience: Software Engineers
Value: Read about solopreneurship
ToT Rating: ⭐

Developer Experience at Uber with Gautam Korlam (6 min read, 1h 20 min podcast)

In this podcast/article you get some insight into DevEx at Uber. Gautam Korlam talks about the benefits of Uber’s monorepo, his career growth, how he accidentally deleted Uber’s Java monorepo 🙂 and many other topics.

He even mentions vibe coding which is a hot topic in today’s digest.

Audience: Software Engineers / Engineering Managers
Value: Learn about Uber’s engineering culture
ToT Rating: ⭐

AI fakers exposed in tech dev recruitment: postmortem (13 min)

Things are getting trickier and trickier for tech interviewers - we have our first fully deepfake candidates now 😆 🤯. Everything was AI-generated for this candidate, LinkedIn profile, resume, code that was written during the interviews and even their video. Read all about that in this deepdive.

Audience: Software Engineers / Engineering Managers
Value: Learn about deepfaked interviewers
ToT Rating: ⭐

Facebook’s Database Handling Billions of Messages (Apache Cassandra® Deep Dive) (13 min)

This is a deepdive into Facebook’s famous database system - Apache Cassandra. You will learn about the use case for which Cassandra was created, it’s data model and architecture that involves fun concepts like consistent hashing and the Gossip protocol 💬.

Audience: Software Engineers
Value: Learn about Apache Cassandra
ToT Rating: ⭐

The Key to Asking Great Questions (8 min)

In order to communicate better and extract more information from your communication you need to be willing to ask questions. Sometimes, we don’t ask important questions, either from fear of looking incompetent of from fear that we will annoy the other person. In this article will share strategies on how to ask the questions the right way, so you do not appear incompetent and do not trigger people into being deffensive.

Audience: All tech professionals
Value: Learn best way to frame your questions
ToT Rating: ⭐

Until next week!

The One Tip to Faster Promotions That No One Is Telling You (5 min)

A great advice I heard about getting a promotion faster is to act as if you are already promoted. In this article goes a bit further than that and shares important people to focus on in order to increase chances of your promotion. There are four important personas he shares, and each of them has something unique that will help you get there.

Audience: Software Engineers / Engineering Managers
Value: Learn how to increase chances for promotion
ToT Rating: ⭐⭐🌟

Introducing Manus: The General AI Agent (4 min video)

Manus AI

Take a look at this AI agent 🤖 that is going viral in China 🇨🇳 right now.

Audience: All tech professionals
Value: Learn about bleeding-edge AI
ToT Rating: ⭐⭐🌟

(Naive) Reuse Considered Harmful? (5 min)

The Architect Elevator

Reuse is considered a good practice in coding. It streamlines implementations, reduces code and makes things simpler to reason about. Architecturally, however, there are cases where good old reuse is not optimal and can even cause more harm than good. This goes against the intuition we have developed for so long as engineers.

Audience: Software Engineers / Architects
Value: Learn when/how reuse can be harmful
ToT Rating: ⭐⭐

How To Not Lose Your Star Performers (8 min)

As an engineering manager, your team members’ performance lies on a wide spectrum. Some are rockstar ninjas 🥷🧑‍💻 that spit out high quality features in no time, while some struggle and require a lot of handholding. As a manager, it is very natural to slip into the habit of focusing your attention on the reports that struggle. However, this might lead to churn of your high-performers. In this article will bust 4 myths about high performers that will help you avoid this unwanted scenario.

Audience: Engineering Managers
Value: Learn how to manage high-performers
ToT Rating: ⭐⭐

Unspoken git secrets that save you mountains ⛰️ of time as an engineer (6 min)

As software engineers, GIT is one of the most heavily used tools in our toolchain. This article goes beyond basics, and shares some GIT superpowers that will save you time and help you be a more productive coder.

Audience: Software Engineers
Value: Learn about advanced GIT tricks
ToT Rating: ⭐⭐

How to Be a Solopreneur? (8 min)

Last week we had an article on the dark sides of solopreneurship. In this one shares quite an opinionated positive perspective on solopreneurship. Read it to get excited about the positive aspects of this life choice.

Audience: All tech professionals
Value: Learn about solopreneurship
ToT Rating: ⭐

Remove the question tax: Why the best engineers ask more questions (6 min)

In this great article, talks about a benefit that LLMs revolution brought that I did not think about. Imposter syndrome is no stranger in the tech industry. And it often prevents us from asking questions for fear of appearing dumb or incompetent. As this fear is a social one, LLMs eliminate it, as you can ask them whatever you want without fear of being judged or scrutinized. Fran further argues that with the advance of AI, the skill of asking the right questions (aka prompting) will be much more important than pure knowledge hoarding.

Audience: Software Engineers
Value: Learn the power of asking questions (or the weakness of not asking them)
ToT Rating: ⭐

Should managers still code? (9 min)

The Engineering Manager by James Stanier

In this article goes on to answer an evergreen question. It is not easy to determine the right level of involvement in the code for an EM. This article will help you by giving you the exact list of what you should do or be able to do as an EM.

Audience: Engineering Managers
Value: Learn how much you should code as an EM
ToT Rating: ⭐

See you next week! 👋

I love the article as it kind of raises the awareness on this topic.

Not many articles in this digest, only five, so dive right in!

The Art of Simplification: Why We (over) Build When We Should Simplify (5 min) 💵

This article reminds me of the concepts of accidental and essential complexity introduced by Fred Brooks in the year when I was born 🙂 Essential complexity is inherent to the problem you are solving and accidental complexity is the complexity you added as part of the solution for the problem you are solving (there was a great article on this ToT digest in December). argues that removing complexity and simplifying things is very much underestimated.

When you add a feature, push code, or collaborate with many engineers, your contribution is very visible. Whereas activities such as sunseting a feature, removing unnecessary UX, brutally descoping the thing that your PM calls an “MVP”, removing code, or never even writing it at first place (aka best code is no code at all) have very low visibility. Even though being less visible, often these “simplification” activities have higher value than their visible counterparts.

Keep that in mind next time you add five different design patterns to implement a simple CRUD operation. Or when you define your MVP, where 80% of it are nice-to-haves that will take up the same percentage of efforts to implement as well.

Be brutal when de-scoping features🫸. Simplify, remove, or even better, don’t write code at all if possible.

Audience: Software Engineers / Engineering Managers / Product Managers
Value: Learn the value of removing features, code (best code is no code), and many other things
ToT Rating: ⭐⭐🌟

20 Business terms every Engineering Manager should know (10 min)

I recently read a company-wide document outlining the company’s business strategy for the next several years. The document contained many business terms whose meaning I did not understand. I asked ChatGPT for help, it gave me some great explanations and at the end I even created an annotated version of the document and shared it with others. The timing of ’s article coincides with this, so I fully get the value of learning these terms.

As an EM, you need to know business terminology to understand the business you are operating in, and communicating business strategy to your engineers is important as well. The good thing is that although the terms seem scary at first, they are quite simple to grasp.

Audience: All professionals
Value: Learn 20 important business terms
ToT Rating: ⭐⭐🌟

6 Simple Ways To Answer Unexpected Question From Leaders (5 min)

You are presenting a feature, technical design, or an improvement proposal, and boom, there comes a question that you never thought of and for which you do not have an answer 😧. You freeze, don’t know what to say, and you feel stupid for setting up a meeting without knowing the answer to this question. You start sweating 😓 and get nervous and don’t know what to do. This article will tell you how to handle this like a boss 😎.

Audience: All professionals
Value: Learn how to answer hard questions during important meetings
ToT Rating: ⭐

The dark side of solopreneurship: Myths vs. reality (6 min)

Perhaps you dreamed of starting your own business and still did not do it due to being anxious about the things that could go wrong. In this article, shares five myths associated with solopreneurship and realities behind them. These might either help with removing some of that anxiety (as you will at least learn about the reality of the solopreneurship journey) or amplify it 😆 and you will realize that being your own boss is not your cup of tea.

Audience: (Potential) Entrepreneurs / Solopreneurs
Value: Learn about the downsides of solopreneurship
ToT Rating: ⭐

Thinking in Maximums (13 min)

Arjun Shah

There is a lot of thought out there that promotes “MVP mindset” where you ship something fast, get it into the hands of customers and then learn and iterate from it. Even in this very digest I advocate for “brutal MVP de-scoping”. This article talks about the downsides of the MVP mindset if not combined with a proper long-term vision.

Audience: Software Engineers / Engineering Managers
Value: Learn about the downsides of “MVP mindset”
ToT Rating: ⭐

Today’s digest was not that long, hopefully you made it to the end!

See you on Monday! 👋

Additionally, Dan Na shares why ownership and urgency are the two most important characteristics to look for in workers.

So have a healthy experimentation/fail-fast mindset like an entrepreneur, take strong ownership of your area and drive with a sense of urgency to be a rock-star performer 🚀. Read on!

What makes entrepreneurs entrepreneurial? (4 min)

Murat Demirbas

This article aims to get to the essence of entrepreneurs by contrasting them with the mindset that regular corporate managers and leaders have. Entrepreneurs use effectual reasoning as opposed to casual reasoning taught and applied almost everywhere. Entrepreneurs try, fail, learn and do not get stuck on an idea or a business model. They do not obsess about their ideas, they adapt to what they learn about the world through trial and error.

The article includes a very short monologue by Steve Jobs that talks exactly about this one small difference that entrepreneurs have - the ability to “poke the world” around them.

Audience: All tech professionals
Value: Learn how entrepreneurs think
ToT Rating: ⭐⭐🌟

High Ownership, High Urgency (10 min)

Dan Na

This article talks about two very important characteristics that are shared by the most effective workers - ownership and urgency. Engineers with a strong sense of ownership are self-guided and self-driven. They feel they own the thing. When you own the thing, you do not accept annoying bugs, spaghetti code or convoluted architecture. No one has to tell you to deal with tech debt or respond to that urgent support request from a customer. You do it because it is your backyard. You don’t allow crap 💩 in your backyard. Contrast that with the engineers with no sense of ownership. They need constant guidance, they need to be told what to do, and they need to be told what is important.

Reading about urgency reminds me of a paragraph from the famous book The Mythical Man-Month that talks about a non-physical talent called hustle.

Fred Brooks wrote the paragraph 60 years ago 🤯 recognizing the value of people with a strong sense of urgency. 60 years later, this article again emphasizes it. That’s an evergreen right there.

Audience: Software Engineers / Engineering Managers
Value: Learn the most important characteristics of an effective worker
ToT Rating: ⭐⭐🌟

Leveling Up Hacks - Active Listening (6 min)

If you want to support your peers or reports better, you need to be good at listening to them👂. You need to be silent and let others speak 😶. You talk only to summarise or ask clarifying questions. You assess how good you are listening through self-reflection and feedback.

Audience: Anyone really
Value: Learn how to be a better listener
ToT Rating: ⭐⭐

5 lessons learned setting up a global engineering org at Google (8 min)

In this article shares her experience building a global team of 30+ people spread out in the US and Bangalore, India. She shares some great advice on how to build culture in your teams through repetition. I also love the Leader-Leader model and “I intend to…” approach that aims to empower your team through boosting the ownership and accountability.

Audience: Engineering Managers
Value: Learn how to build great (remote) team culture
ToT Rating: ⭐⭐

Law of Demeter - Talk to Friends, Not to Strangers (6 min)

Have you heard about the famous programming design guideline called the Law of Demeter? If not, this article is a great source for familiarizing yourself with this guideline, which aims to reduce the coupling of your code.

Audience: Software Engineers
Value: Learn how to write less coupled code 🍝📉
ToT Rating: ⭐

How Amazon S3 Stores 350 Trillion Objects with 11 Nines of Durability (13 min)

Amazon S3 is among the top three most successful products from AWS. There is a lot under the hood of this technological marvel, like index partitioning with lexicographic distribution, caching of frequently accessed objects and automatic rebalancing based on access patterns. Learn how this system, composed of 350+ microservices, stores data with 11 nines of durability (99.999999999%) 🤯.

Audience: Software Engineers
Value: Learn about Amazon S3
ToT Rating: ⭐

My strategy to learn faster than anyone else: Copying from the best (3 min)

We engineers think very highly about our craft and often overemphasize the ratio of creativity in it (t-shirts that say “people think it’s magic, we call it engineering 😎”). Truth be told, there is tons of copying going on in our craft. You copy others’ code, presentation decks, design documents, even PR comments 🙂. With all that copying going on, this article will help you do it properly.

Audience: Software Engineers
Value: Learn how to copy from others properly
ToT Rating: ⭐

Amazon Principal Engineer On Layoffs, Interviewing & Career Growth | Steve Huynh (6 min read, 1h 18 min podcast)

In this podcast/article you will hear ‘s experiences from his almost 20 years working at Amazon. Steve talks about interview prep, Amazon’s performance-based layoff culture and many other insights. When seeing the podcast, I remembered Steve also defined a very insightful concept called the “promotion donut” 🍩.

Audience: Software Engineers
Value: Learn about Amazon
ToT Rating: ⭐

You made it to the end! 🙌
See you in the next digest!

The below article by Marc G Gauthier proposes treating both technical projects and product projects in the same manner. This resonated with me as I feel that all the problems start the moment you segregate the two. Properly including tech work in the product work leads to stronger engineering organization and stronger trust between engineering and product.

So be very clear about what’s not up for debate with your product partners, communicate how/why that is important for the business, and keep your engineering posture in good shape 💪.

PS: I am curious how you are balancing tech vs product work in your teams, let me know in the comments 💬.

All Projects Are Business Projects (13 min)

marccg.com

Balancing technical work with business/product work is an evergreen topic in software development. A lot of organizations separate these two workstreams and treat tech work as a cost source and business work as the sole value source. Often tech work is parked for “later”. Very early you learn that there is no such thing as “later” and “later” almost never happens. This article argues for treating all project as business projects (which I love 😍) and even gives you example of how you can frame some common “tech projects” through a business lens. This should help you to communicate with more confidence when explaining why that refactoring/migration/re-architecture is necessary to your non-technical partners.

Audience: Software Engineers / Engineering Managers
Value: Learn how to incorporate technical work in your roadmap
ToT Rating: ⭐⭐🌟

Engineer to CEO in 3 years: These key lessons got me there (8 min)

There are a lot of articles on career growth and what you can do to get promotions faster. This article is unique as it shares lessons through an amazing hyper-speed career growth story 🚀 from . There are three important lessons there, but overarching theme that pops out is being hyper proactive. Proactivity leads to spotting most pressing problems/opportunities for your business. Proactivity in addressing those could mean you stepping completely out of your role - for example engineer to product or product to sales (talk about stepping out of your comfort zone). While everyone else sits in their comfort zones, you will grow both skill-wise and career-wise.

Audience: All tech professionals
Value: Learn how to make huge impact on your org
ToT Rating: ⭐⭐

5 mindset shifts needed to grow from engineer to leader (9 min)

Switching from an engineer to an engineering manager will require you to learn new skills that you did not need that much before. Most importantly you will need to unlearn certain things that were very useful to you before. I am sure a lot of engineers making this switch are making same few mistakes (I know I did all of them). In this article will walk you through midset shifts you need to make to minimize the impact of these mistakes.

Audience: Software Engineers / Engineering Managers
Value: Learn how to switch from an engineer to an engineering manager
ToT Rating: ⭐⭐

Why fixing weaknesses is killing your leadership (3 min)

There are many super powers that any given engineer can have. Some are coding at the speed of light 🧑‍💻 🚀 shipping PRs before you can review them. Some communicate and present like trained TV show hosts making it super easy to get everyone onboard. Apart from strenthgts every engineer has accompanying weaknesses as well. This article promotes “strenght-based leadership” where, instead of focusing on fixing weaknesses of your reports, you should focus on optimizing their strenghts.

Audience: Engineering managers
Value: Learn about strength-based leadership to improve engagement and productivity of your team
ToT Rating: ⭐

The Sidecar Pattern: Scaling Microservices on AWS (3 min + 50m bonus vide)

If you know about the sidecar pattern you can skip this article. If you are working with microservices and want to learn more about this “sidecar” word that keeps popping up, this article is for you.

As Istio’s architecture (usually, but not necessarily) relies on sidecars this article reminded me of a great talk by Eitan Suez where he is describing the purpose behind Istio and its architecture. Great talk that might give you a bit more context on how sidecards could be used.

Audience: Software Engineers
Value: Learn about sidecar pattern
ToT Rating: ⭐

How to WOW your engineers without budget (4 min)

Engineering managers often tend to follow a very boring routine when it comes to important events of their reports (newcommers joining, anniversaries, birthdays, etc.). This article might shake you out of that routine and inspire you to be more creative when celebrating important milestones for your team members.

Audience: Engineering Managers
Value: Learn how to boost motivation of your team
ToT Rating: ⭐

Robotics for software engineers (11 min) 💵

In this one walks us through the evergreen topic of robotics 🤖. Article is paywalled, but the intro is a good enough overview of the current state of robotics and how it can be the next “big thing” after AI.

Audience: Software Engineers
Value: Learn about robotics
ToT Rating: ⭐

From Debugging Code to Debugging Teams (6 min)

If you are an engineer contemplating going for an engineering management position this article will help you understand whether this move is right for you.

Audience: Software Engineers
Value: Learn if you want to be an engineering manager
ToT Rating: ⭐

Hope that was useful, see you on Monday! 👋

Last week, I hit 100 subscribers after getting 10 subscribers from the last post 🚀.

In my newbie newsletter world, getting 10 subscribers on a single post is the definition of “viral” 😆
Thank you for being a part of the ToT community, let’s keep learning together! 🙌

Why Engineers Must Care About Product-Market Fit (And How To Do It) (7 min)

It is not rare that engineering teams ship features without any idea if those features are bringing value to users or if they are adopted. Organizations where “Getting it to GA” becomes the main goal risk going completely blind on how their users use their product. In this one, shares the value of measuring the success of what you are building 📊 and some practical advice on how you can do that. If you are building a product, reading this will make you a better engineer and your organization will benefit from you caring about the impact of what you are building.

Audience: Software Engineers
Value: Learn why and how to measure your features
ToT Rating: ⭐⭐🌟

15 lessons from 15 years in tech (7 min)

In this one, shares a lesson from each of his 15 years in tech. From the power of product-first thinking and avoiding overengineering to career growth tips, Owen will give you actionable tips you can start using today 👌.

Audience: Software Engineers
Value: Learn tips from experienced techie
ToT Rating: ⭐⭐

How Instagram Scaled Its Infrastructure To Support a Billion Users (15 min)

This system design piece shares a story of how Instagram went from developers manually adding servers before the weekend to avoid crashes to where it is today. You will learn about some neat system design nuances, such as solving the “thundering herd” problem with the Memcache Lease mechanism.

Audience: Software Engineers
Value: Learn about Instagram’s architecture
ToT Rating: ⭐⭐

Software engineering job openings hit five-year low? (11 min)

Software Developers job listings have hit a five-year low, and in this episode of Pragmatic Engineering, we get an analysis of why that could be the case. By the end of the article shares that he is “sure that LLMs are a leading cause of the fall in software developer job postings”. Read all about this gloomy trend in the tech industry.

Audience: Software Engineers
Value: Learn why developer jobs are going down 📉
ToT Rating: ⭐⭐

The Six Steps to Saying No — Why Being a Team Player is Not Necessarily Great (7 min)

If you are a high-achieving engineer/manager, saying no is a skill to learn. Otherwise, you could end up burned out burning the midnight oil on non-impactful endeavors. This article introduces you to why saying no is important and what can go wrong if you keep saying yes to everything.

Audience: All tech professionals
Value: Learn why to say “no”🫸
ToT Rating: ⭐

Managing people you don't like (7 min)

Humans are very biased creatures, and often, those biases lead to irrational decisions. Even our engineering brains, despite emphasis on rationality and logic, are flawed in many ways. In this article, and share their experiences working with people they did not like, challenge the popular “beer test” 🍺, and talk about how being biased towards people you do like can make you build weaker teams.

Audience: Engineering Managers
Value: Learn how and why to work with people you do not like
ToT Rating: ⭐

Mentoring doesn't solve all problems. The 4 people every software engineer needs to grow fast without burnout (5 min)

We often have wrong expectations from mentoring. We confuse mentorship with coaching, teaching, or consulting. This article gives a great overview of all these learning relationships, which can help us better focus our growth.

Audience: Software Engineers
Value: Learn about (non) mentoring
ToT Rating: ⭐

Your First Step to Engineering Leadership: Becoming a Senior Dev (6 min)

This article talks about how becoming an Engineering Manager requires you to be a Senior Engineer first. shares the different types of engineering leaders and how to act like a senior engineer.

Audience: Software Engineers
Value: Learn about the road to Engineering Management
ToT Rating: ⭐

See you soon! 👋