Wisen Tanasa Profile picture
Oct 7 30 tweets 7 min read
Many of the software engineers I talked to told me that they practice TDD out of guilt.

That's not right, we need a different way to think about TDD.

I've been practising TDD for almost a decade, here's how I currently think about it:
Current literature focuses on how TDD is the best design technique out there, therefore we have to adopt it.

But, I don't use a hammer merely because it's the best tool to drive nails, it's also because I can't drive nails without a tool.

Let's try that angle instead.
Effective techniques or tools circumvent our biological limits.

Usain Bolt can't outrun a domestic cat, but on a bicycle, he could.
When it comes to creative works, such as programming, our biological limits are in our heads.

It's difficult to recognise what our limits are when it's in our heads. We're not going to visibly bleed if we're not using any tools to drive those metaphorical nails.
Therefore I think it's important for us to describe what our limits are so that we can recognise and address them.

Here are three limits that I observed throughout my career:
1️⃣ Willpower

Not all of the work that we do to keep the business running is interesting or exciting. To motivate ourselves to do the work, we use our willpower.
Unfortunately, willpower is a resource that depletes quickly. We will run out of mental energy, which is quite limited per day.

That dopamine boost coming from chasing something shiny is also hard to resist.

We need to have an alternative resource to motivate ourselves.
2️⃣ Working memory

There is a lot of information that we have to juggle in our heads to ship a change. We need to think about the user needs, UX design, architecture, engineering principles, tech debts, writing tests, those old libraries, and the list goes on.
Unfortunately, we can only hold 7±2 things in our heads at the same time. We often think about the wrong thing at the wrong time e.g. we would refactor or optimise before our code is working.

We need to have the right information in our working memory at the right time.
3️⃣ Wit

We need to apply our intelligence to our work. There are many business and technical challenges that we need to solve, therefore we would think about the best solution to tackle all those challenges.
Unfortunately, our wit often introduces a whole set of new problems. We don't spend enough time thinking about simpler alternatives. We try to be clever at the wrong time.
We also tend to jump to conclude that we know enough about what needs to be solved and start coding without thinking ahead.

We need a system that helps us control when or when not to be clever.
Those three limits are what we need to circumvent, and we need a technique to help us work better.

The answer to that is an effective workflow.
Seriously, a workflow?

Yes. Niklas Luhmann famously wrote more than 70 books and 400 articles on various subjects. The amount of writing he had written is not only a matter of quantity but of quality as well.

The secret to his abnormally impressive productivity is his workflow.
What does an effective workflow look like in our software engineering world?

I'll describe them below whilst connecting them to TDD.
1️⃣ Effective workflow forms a positive feedback loop

The answer to our limited willpower is not stronger willpower, but to think about how we can live without willpower. The answer to this in creative works is a positive feedback loop.
We motivate ourselves by making a progress, and we know we're making a progress by getting feedback. The best kind of feedback that we should look for is the feedback that we get from the work itself, which will create a feedback loop.
When you practice TDD, every time you make your red tests turn green, you are making a progress. That's a positive feedback loop.
2️⃣ Effective workflow embeds a sequence (via a mnemonic device)

We would like to fill our working memory with the right things in the right sequence. A mnemonic device helps us remember this. We can recite the sequence of the alphabet by singing the ABC song as a mnemonic.
TDD's mnemonic device is Red > Green > Refactor. Each of these steps pulls different information into our heads in the right sequence, circumventing our working memory.
The separation of Green and Refactor is also the answer to circumvent our wit. The green step encourages us to think simple. What's the simplest way for us to make this red test green? That will reframe our heads differently.
3️⃣ Finally, effective workflow enables flow state

Flow state is correlated to happiness. Who doesn't want to be happy at work?

The prerequisites of a flow state are clear goals and immediate feedback.
Each of the steps in TDD defines clear and smaller goals for your task.

Each of the completion of the step, each of the green tests you're getting, and each of the commits you're making after the refactoring step is a form of immediate feedback.
In summary, an effective workflow is required to organise our heads better and circumvent our biological limits.

TDD may not be an answer for everyone, but it's one of the workflows that I found effective so far (I do have other workflows that complement TDD).
If you have a workflow that circumvents our limits, I'll be keen to know.

And don't feel guilty if you don't practice TDD!
I would appreciate your thoughts and feedback on this rambling 🙏🏼 @RonJeffries @GeePawHill @KentBeck @hillelogram @allenholub @tottinge @unclebobmartin @davefarley77
I write a thread every Friday, follow me @ceilfors for these threads to show up on your feed.

Like/Retweet the first tweet below if you can:
I thought was talking to the void, but this blew up, thanks all for your support 🙇🏻‍♂️

I don't have any soundcloud or newsletter!

Spread kindness, and consider donating to effective charities
givingwhatwecan.org/best-charities…
If you're a small team that works in a charity/education/health that might benefit from coaching or advising, please do reach out and I'll like to learn more 🙂
You can read the unrolled version of this thread here: typefully.com/ceilfors/y0U74…

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Wisen Tanasa

Wisen Tanasa Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @ceilfors

Sep 29
Smaller commits help retain my flow state, therefore improving my productivity.

To have smaller commits, you have to be able to slice your task into nano-slices. I have found adopting Angular's commit format to be helpful in the slicing activity.
The part of the commit format that helps me slice my work is the definition of commit types.

You don't have to remember all of the commit types to start with. In day-to-day development, I'd only use four of them: feat, fix, test, and refactor commit types.
Before I start my work, I tend to have these commit types in my head.

What is it that I'm doing now? Is it a `feat` or `fix`? Is it a `test`? Is it a `refactor`? Then I'll start coding, attempt to consciously stop when I'm done, and then commit.
Read 12 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us on Twitter!

:(