Hi there,

I've been thinking a bit about a few things, and I would love your help. You see, I live in two worlds professionally. By day I help companies build phenomenal software teams, and by night I help people get the tech careers they want. Now I know the best way to see success is to satisfy both of my audiences, but most things I try seem not to stick. So I need your help.

What can I write about that will help you TODAY?

Living in two worlds there was thankfully some overlap as I found myself pacing around my office thinking.

I was having a conversation with a client and asked them what good looks like for this next project. "Fast," they said without hesitation. So I asked if the software needed to work when the coding was done. This question was extremely important because the teams and managers hatched a plan for speed, but secretly accepted the risk that the software will not work.

I was also reflecting on some of my career clients and the recent conference talks I gave. I typically don't coach my career folk on specific skills or how to actually do their jobs, but occasionally I do. Most early-career folk I meet have already formed the opinion that the speed at which they code is the most desirable trait they can develop. The whole hiring process encourages it.

So we have a generation of developers who are devoting nights and weekends to honing their coding speed, but not their quality.

I hope the relation between these two things is pretty clear.

The one skill that I try to impress on teams and my career clients consistently is Test-Driven Development

While many people think it's impractical or doesn't work, it is a technique that has been at the backbone of me and my clients delivering bug-free software for almost six years. It has eliminated tech-debt before it collected interest. It removed conversations like, "Oh we should rebuild it." It taught me and others what we really needed to know about well-designed software without even realizing it.

I've read books on software, tried other techniques, configurations of teams, and workflows. Nothing gets close to sustained quality like TDD. Nothing more rapidly improves skills like TDD.

My most recent team was typical in that they had lots of objections to trying TDD. Mostly because they were afraid of how slow they'd become. After a few months though the most common refrain was, "I don't ever want to go back. I grew more these few months than I have in my whole career."

There is a lot more to say about TDD, and how to start, but this email is getting too long. Maybe I should write more about it?

I want to leave you with another question though, and I do care about your answer!

What would it take for you to give TDD an honest try?

Here's my weekly update for August 27th, 2021...

@recursivefaults

Time for a thread on tech interviews. In particular, how they actually happen and what that means.As in, I aim to answer, why interviews tend to happen the way they do.

7:08 PM · Aug 25, 2021

View on Twitter

Enjoy,

Ryan Latta

PS: You'll notice at the bottom of this email is a referral campaign.

The idea is simple. I want this community to grow, and I want to reward those of you who share my newsletter with your peers. Using your custom referral link you can get copies of my books, and consultations with me that normally cost $200 an hour.

If there is a prize you think that you'd really want from me, let me know!