Do you ship your code fast enough?

Learn how to deliver your work faster and not make some industry-proven project planning mistakes

A lot about your career growth as a software engineer and beyond depends on how fast you can ship code to users. The below article will give you very practical advice on how you can be more effective as a software engineer and where you can improve so you get that code to production faster.

On that theme, I shipped a new feature for this newsletter that is available already with this digest. Can you spot what it is?

---

Everything I Know About Shipping Code Faster (7 min)

The Developing Dev

We all want to ship code faster. In this article,

Ryan Peterman

is looking at shipping code faster as the leverage for growing your career faster, as shipping fast frees up more of your time for growth opportunities. There is some golden advice there that every software engineer should use. I love the advice for reducing friction for PR reviewers 😻. Not only does that help your reviewers, but it helps you to ship faster, thus helping you focus more on your career growth 🚀.

Do you have any other advice for shipping code faster? I am always on the lookout for those, post them in the comments 💬.

Audience: Software Engineers
Value: Learn how to ship code fast
ToT Rating: ⭐⭐🌟

4 Common But Insidious Patterns That Derail Software Projects (7 min) 💵

Scarlet Ink

This paywalled article contains four patterns of potential failure causes for your projects. However, even the free version is valuable, as it gives you one important failure cause - the famous “big bang release”. Read

Dave Anderson

‘s advice on why you should almost never do big bang releases.

Audience: Engineering Managers / Product Managers
Value: Make your release planning better
ToT Rating: ⭐⭐

How to create a culture of ownership in your engineering team (6 min)

Engineering Leadership

I feel like there are three phases of managerial growth in terms of delegating ownership. In the very early phase, you are still trying to do many things yourself, and you end up being a bottleneck for your team. Once you learn not to do that, you delegate, but you push your engineers relentlessly, thinking that’s the only way to get them to own up. Finally, in the third phase, you find smarter ways to empower your team. In this post,

Taha Husain

talks about how to transition to that third phase.

Source: Engineering Leadership

Audience: Engineering Managers
Value: Learn how to build stronger ownership in your team
ToT Rating: ⭐⭐

Getting exec buy-in for developer productivity initiatives (3 min)

Have you ever struggled to convince your leadership to sponsor your initiative? This brief article from

Abi Noda

shares advice on how to get buy-in for developer productivity initiatives. However, I believe you can use this advice for an even broader purpose - to get buy-in for tech initiatives in general. If you need to get sponsorship for your tech initiative, this one is a worthwhile read

Audience: Software Engineers / Engineering Managers
Value: Learn how to get buy-in for tech initiatives
ToT Rating: ⭐⭐

Introducing Swark: Automatic Architecture Diagrams from Code (3 min)

Oz Anani

With the advent of LLMs, everybody is using AI for writing code. In this brief article, you get introduced to Swark, a simple VS Code extension that generates Mermaid.js architecture diagrams of your whole repository.

Audience: Software Engineers
Value: Generate architecture diagrams automatically
ToT Rating: ⭐

Organizations are distributed systems (4 min)

Industrial Empathy

If I had to summarise this article, it would come down to “It’s better to ask for forgiveness than for permission.”.

Malte Ubl

uses a database transaction analogy to find ways how to improve change approval processes in an organization.

Audience: Software Engineers / Engineering Managers
Value: Optimise your approval processes
ToT Rating: ⭐

How to Estimate like a Superstar Tech Lead? (4 min)

The Hustling Engineer

Estimation is one of those evergreen topics most engineers deal with. In this article,

Hemant Pandey

gives you some sound advice on how to estimate like a boss. One thing that stands out is a 10-20% buffer for unknowns.

In the famous “The Mythical Man-Month”, Fred Brooks provided a guideline to triple your initial estimate, although that was (exactly) half a century ago 🙂. I tend to lean towards doubling the initial estimate. I am curious about your opinions, drop them in the comments 💬.

Audience: Software Engineers
Value: Learn how to estimate
ToT Rating: ⭐

---

Hope you enjoyed this Tuesday’s digest!
Happy coding! 🙌