Weekly blog posts about creative work in the tech industry

Previous page

Page 3 of 5


Using TDD as a Mind Hack

Sep 29, 2018

In this post, I’m going to be talking about a hidden benefit of test-driven development. This benefit is not about the quality or reliability of your code. It’s about you and your mind.

I will first give you a short introduction to test-driven development (TDD). After that, I’ll discuss how you can use TDD as a tool to reduce stress and frustrations.

What is TDD?

TDD is the practice of writing tests before writing code. Here is how you ideally work as a developer if you do TDD:

  1. Write a failing test. Write a test that uses the code you wish you had.
  2. Write the code. Write the code that will make your test pass.
  3. Refactor your code. Make your code not only work but also look good.

In Test-Driven Development by Example, Kent Beck calls this process as the “Red/Green/Refactor” cycle. You are in the "red" when your initial tests are failing. You move to "green" when your tests pass. Finally, you refactor code while making sure your tests continue to pass.

"Red/Green/Refactor" as mental modes

I heard about using TDD as a mind hack by watching Tom Stuart’s RubyConf talk Get Off the Tightrope. The whole talk is built around the idea that a major cause for knowledge worker stress is people trying to do a big thing all at once.

Stuart discusses a bunch of practical examples of breaking things down into smaller chunks. But he does not say that these are the examples that will necessarily work for you. You should find your own tools. You should personally experiment and practice keeping things small and manageable.

However, Stuart’s TDD mind hack is something I’m just going to start practicing with. I don’t feel like I need to question it. It just makes sense.

This is the mind hack: treat the “red”, “green”, and “refactor” phases as separate mental modes. Each of these phases have a different goal. Because of that, you should focus on different things in each phase.

Remember that part of being focused is about identifying distractions and saying “no” to them.

When you are in the “red” phase, you are trying to write a failing test. Don’t allow yourself to get sucked into doing something else. You do have to define interfaces, but you don’t need to know what happens behind those interfaces.

When you are in the “green” phase, you are trying to make the tests pass. In Beck’s words, “quick green excuses all sins.” Don’t allow yourself to be concerned about aesthetics. Don’t allow yourself to spin your wheels and try to come up with perfect names.

When you are in the “refactor” phase, you are not focusing on the problem or the solution. You focus turning “code that works” into “good code that works”. Allow yourself to correct your sins from the “green” phase.


This hack is about reducing context switching which puts a strain on your brain. It's about understanding that your working memory has a capacity. When you start reaching that capacity, you become more irritable to outside distractions.

When we are talking about being irritable or stressed out, we are not talking about code quality. We are talking about things that prevent you from becoming a happier, more balanced coder. Your family, friends, and co-workers will thank you.


Craftsmanship Is Not About the Customer. It’s About You.

Sep 22, 2018

A month ago, I had a chance to read The Case for Slow Design by Jesse Weaver. It was suggested to me as an example of how you can misunderstand the concept of minimum viable product (MVP).

You don’t have to read The Case for Slow Design to continue reading this post. I’m going to summarize Weaver’s main point here: Craftsmanship is the new advantage for product companies. Being a craftsman means that you “sweat the details”, “pour [your] soul into the work” and “spend untold hours creating [your] masterpiece.” We shouldn’t consider getting a product out to be better than getting it perfect. We shouldn’t strive for minimum viable.

My initial problem with Weaver was his argument that MVPs lead to impossible deadlines, lack of focus, and products that aren’t meaningful. I believe that building an MVP means that you resize your project so that you can set a reasonable deadline. I believe that an MVP forces you to define the core essentials of your product. There is no room for lack of focus. I believe that an MVP is much more about what your customer wants rather than what you want as a creator. At the end of the day, your customer will be the one defining the meaning and value of your product.

A couple of weeks went by and I was still thinking about the article. I couldn’t stop wondering what made Weaver dislike MVPs so much. What’s so wrong about making a product that is just enough to help you figure out whether you’re on to something or not.

And then it hit me. I think Weaver’s article might be a cry for employee happiness. An argument for craftsmanship in terms of what it can add to a worker’s life.

An argument for craftsmanship

We humans value craftsmanship. We value the craftsmanship of other people. But even more, we value our own craftsmanship.

When you try to perfect your cooking, you are adding craftsmanship to your everyday life. You get a thrill of putting effort into something and seeing your skills improve in extremely concrete ways.

You don’t try to perfect your cooking so that you can start selling lunches on the street. There are no customers for whom you are creating value. But you might share your cooking with your friends and family. Your hobby is not purely a narcissistic effort. In addition to seeing your own skills improve, you see your work improving the lives of other people.

You feel satisfied. You feel good about yourself. And this is happening even when nobody is giving you any money to validate your pursuit for craftsmanship.

In my free time I write this blog and I code things. I don’t get paid for either of those spare time activities. I’m talking about personal projects here. I do work as a software developer and for that I get a monthly paycheck. But when I get to write and code on my own terms, I feel a sense of deep satisfaction. I can experiment more. I can tinker.

In addition, the results of my writing and coding have utility. Other people besides me can enjoy them. This adds to my satisfaction.

Let me bring this back to work life. Unlike Weaver, I’m not comfortable making the argument that craftsmanship will directly translate to customer value. I’m not comfortable making the argument that craftsmanship will save your company.

Craftsmanship is not the new advantage. Craftsmanship is not even the sign of a real artist. The phrase “real artists ship” still holds true. Getting your product out is more important than getting it perfect.

What is true is that craftsmanship can make you feel more balanced. It can give you energy. It can make you feel like you aren’t wasting your life away.

But what are you really willing to give up for those feelings?

Are you willing to pass a client project that compromises your ideas of craftsmanship? Are you willing to earn less money than your friends in return for greater meaning in your work? If so, how much less are you willing to earn?

Right now, would you rather make more money or would you rather have more fulfilling work hours?

I’m not saying you can’t have both. A great income and a great life of craftsmanship do not contradict each other. But when you prioritize things, you have to be willing to accept that sometimes you won’t get everything you want.

If salary has a greater meaning to you than craftsmanship when looking for a job, you are literally prioritizing great income over great craftsmanship. And if those are your values, then why shouldn’t your employer have those values as well? Why should your employer care more about craftsmanship than you?


Deep Work and the 4 Disciplines of Execution

Sep 15, 2018

This is the last part of the two-part blog series about my goal to publish and maintain three open-source projects. Last week I wrote about the personal struggles I have with managing flow state. You can read the post here.

This week I’m going to cover my strategy for working towards my goal.

Pretty much all the credit of this post goes to Cal Newport and his book Deep Work. I’m literally taking a chapter from his book and applying it into my current situation.

The basic idea of Deep Work is that there are two types of work in the world, shallow work and deep work, and that these two different types of work require different work practices from us.

A good example of shallow work is reading your email. You don’t really need to get into the zone to go through your inbox. You can do it while sitting in the train or attending a mandatory meeting.

Writing and coding are examples of deep work. These activities require more focus. You can’t really multi-task and write. If you get interrupted while coding, it’s hard to collect your thoughts even after the interruption is over.

I love Newport’s Deep Work. It’s a book that led me to reflect on the real and meaningful emotional aspects of solo work. It helped me understand why I sometimes struggle to get in to the flow state. It taught me to keep pushing forward when I’m feeling sluggish.

Since the book has been so influential to me, I have tried to push it to my friends more than any other book. However, the response I have received from those who actually read it hasn’t been so great. So I’m not trying to convince you to read Deep Work. Maybe the message of the book won’t resonate with you or it’s stuff that’s self-evident to you.

I’m also not going to go over the whole book here. I’m not even focusing on the most important message of the book. I’m going to discuss a chapter about applying The 4 Disciplines of Execution (4DX) to your personal work.

4DX is a management framework made for businesses. It’s based on the idea that executing a strategy is a lot more difficult than creating one. If you want to learn more about 4DX, there is the book (which I haven’t read) and bunch of other materials you can find by Googling.

What follows is me going through each discipline of 4DX and applying it to my current situation.

1. Focus on the wildly important

You start by defining the wildly important goals. A wildly important goal is a goal that can make a difference. It’s a goal that will make you excited.

The key is also to focus and limit yourself. You shouldn’t have ten wildly important goals. Instead, pick one or two goals that you’ll pursue in a relentless way.

Publishing and maintaining three open-source projects is my wildly important goal. It’s a goal that allows me to move forward as a developer. It will force me to not only expand my skills in coding, but also my skills in making work that’s consistent and meaningful for other people.

The reason why I'm choosing to publish and maintain three projects instead of just one, is that the challenge of three projects excites me. If I get one project out, I have reached a reasonable goal. If I get three projects out, I have outdone myself.

2. Act on lead measures

There are two types of measures: lag and lead measures. My goal of three open-source projects is a lag measure because it measures my actual goal of contributing to open-source. But that lag measure of three projects doesn’t really guide me in my daily work.

Lead measures are the things that lead you to your goal.

If your goal is to write a book, your lead measure could be the number of words you write per day. In my situation, I’m following Cal Newport and using his primary lead measure: the number of deep work hours. I define deep work hours as hours that are fully dedicated to the code work. This means no emails, no multitasking, and no unplanned breaks.

3. Keep a compelling scoreboard

Your scoreboard is the place where you mark your progress. It’s a visual reminder of your goals and lead measures.

On my apartment wall, there is a piece of paper with a table drawn on it. The leftmost column of the table has the week numbers from the current week all the way up to the last week of the year. Next to each number there is a row of empty cells. Those cells are for my deep work hours. When I get one hour of deep work done, I draw a little “x” inside one of the cells.

4. Create a cadence of accountability

4DX advocates for holding each other accountable for our progress. Inside your team, you should have weekly meetings to review and update the scoreboard. Each person in your team will verbally commit to actions that move the team along the lead measures.

Creating a cadence of accountability is harder when you are working by yourself. There is no social pressure. And there is no support network when things get tough.

The first step in my attempt to manufacture this cadence of accountability, is to put a weekly reminder in my calendar to go over this week’s deep work hours. I’m doing this so that I will regularly review my progress and figure out how I could get more deep work hours done during my next weeks.

The second step is to publish this blog post. The main purpose of this post is to inspire you to keep moving towards your goals. But this post will also push me forward.

I’m going to be fully honest here. I’m a little uncomfortable publishing this post. I’m afraid to publicly commit to my goals because I know it’s going to suck if I don’t reach them. If I fail, I will fail in public.

But this is what social pressure feels like. It’s not a nice feeling. But in moderation it’s good for you.


From Flow to Crash to Steady

Sep 7, 2018

Code is not only work for me. It’s also a hobby. It’s a creative outlet. It’s something I do on my free time.

Couple of weeks ago this hobby of mine had, however, taken a bigger role in my life that I would have wanted. I’m going to tell you what happened and how I’m taking back control. This the first part of a two-part series.

Flow state is a double-edged sword

I believe everybody who has achieved fluency with a programming language and written code with it, has experienced the flow state. Maybe you haven’t completely lost your sense of space and time. But you probably have experienced that exciting feeling of concentration and absorption.

The flow state gives you a natural high. But with every high there is a low. When you go up, you eventually come down.

I don’t know about you, but at least for me, an intensive state of flow can end up in a crash. If I don’t manage my way of working, my dopamine levels come down too fast and the exhaustion kicks in.

I’ve found that steady progress works much better for me than intense bursts of productivity and creation.

Yet every now and then I find myself doing the exact opposite. Suddenly I realize that I’m not managing my time. I’m not managing my progress. I’m not taking breaks from the flow state.

Two months ago I started working on a new open-source library. In summary, I was trying to turn HTML files into text-based user interfaces. I had no idea how hard it was going to be. But I was very excited about the idea and the challenges I had to solve.

Initially, I thought I would get the first version of the library done in two weeks. So I didn’t prepare myself for a marathon. I just started running as fast I could.

One month later and no end in sight, I realized that this project was turning into a monster that would devour me if I didn’t pay attention.

I could feel the initial enthusiasm wear off and the exhaustion creep in. I could sense what would happen if I didn’t step back and reassess the project.

My goal for 2018

This is where I’m now. I have taken the much needed break. I have re-evaluated what I want to achieve in terms of my code.

My new goal isn't to finish this one project.

My new goal is to publish and maintain three open-source projects by the end of this year.

I have a reason why I doubled down on my goals instead of dialing it back. I have a strategy for reaching this goal. I will cover the details next week.


Innovation Doesn't Sell and Ego Sells Even Less

Sep 1, 2018

This week I got pointed out that I had missed an important part when it comes to selling innovation-as-a-service. The part I missed was the concept of external and internal innovation.

External innovations are the new methods, ideas, and products that are introduced by external parties such as innovation-as-a-service businesses or other companies selling consultation and training.

Internal innovations are the innovations that are brought into attention by important stakeholders and people inside your own organization. I’m talking about new ideas generated by your colleagues and customers.

There is hostility towards external innovations. First of all, this reaction of hostility is understandable because we humans in general don’t like to be told what to do by outsiders. The second, and a more important, reason for hostility is that the motivations of the external party might be bad or the advice given by the external party might be coming from a place of ignorance rather than understanding.

When I say that the motivations might be bad, I’m not saying that the outsider is trying to screw you over.

I’m saying that the motivations might be fueled by ego rather than desire to serve.

This is the part where I’m going to move away from selling innovation-as-a-service and sales in general.

Because what I’m going to say next has importance to you whether you’re working primarily in sales or primarily as a developer like I do. I’m going to talk about making action happen inside your organization or inside your client’s organization. After that I’m going to bring it back to the idea of ego and innovation.

Let’s start with action

You are currently trying to sell both your clients and colleagues new ideas, methods or products even if you don’t realize it. You might be trying to introduce a new feature for your users. You might be trying to change the way your current project is managed. You might be trying to get your co-workers to switch from one developer tool to another.

It takes effort for people to change the way they do things. If someone adopts an innovation, big or small, they need to be sold on it. They need to be convinced that it’s beneficial for them to give their attention, time, money, or social status now in order to make their life better in the future.

Simply put, you need to generate action that takes effort.

Larry Ferlazzo is an award-winning high-school teacher and a known blogger and columnist. When it comes to moving people into action, Ferlazzo makes a distinction between two different approaches: irritation and agitation. Irritation is trying to make people do something that we want them to do. Agitation is trying to make people do something that they want to do.

When you come from outside of the team or the organization and try to make things happen in the way that you feel is the best way, you are irritating people. You are trying to make people dance in your tune. You are trying to generate action around external innovations.

By way of agitation, you try to listen to people and find out what they really want but fail to achieve. You move the obstacles from their way and you give them the nudge they need in order to take actual steps towards their goals.

It’s easy to see how agitation can lead to more meaningful action compared to irritation. But in general, it’s more common to experience irritation than it is to experience agitation.

I’m not going to deny that I don’t irritate. Cause I definitely do irritate. This blog post is inspired not only by discussions that I have had with other people but also by my own actions of irritation.

To err is human. To irritate is human as well.

However, even though I am an irritator, I would like to say that I’m a remorseful irritator. I'm also an aspiring agitator.

Ego is not an agitator

Why is it easier for me to irritate than it is to agitate? Why is it easier for the people you know to irritate? Why is it easier for you to irritate?

Let’s bring the idea of ego, your sense of self-esteem and self-worth, back to the discussion. Because I'm willing to argue that it is your ego that wants to irritate, not you. Your ego doesn’t want to agitate. Your ego doesn’t want you to be humble or understanding (important skills needed for agitation) because those characteristics are in direct conflict with it.

Humility challenges your sense of self-importance. Willingness to learn from mistakes challenges your sense of intellect. When you get humbled, or when you realize that you can be a real dummy at times, it hurts because your ego takes a blow.

Naturally, things that can increase your sense of self-importance are in harmony with your ego. There is no conflict. There are no uncomfortable feelings.

A thing that can give you this kind of an ego comfort is if you can become a savior or a visionary inside your or your client’s organization. Maybe there is a project that is going through a rough patch. You want to be the one who comes in guns blazing, lays out the action plan, and leads the team to victory. Or maybe there is a problem inside your client’s organization that you want to solve with your own creative ideas.

If things are done in your way, you'll get the credit. You’ll be praised as the savior or the visionary. Your ego will get what it wants.

But of course this won’t happen. Your clients and colleagues will see your ego in action way before you even realize that the ego has taken over. They will experience the irritation, not the agitation.

No sale, no action, no change.

Additional notes

I first learned about agitation, irritation and Larry Ferlazzo from Daniel H. Pink’s book To Sell Is Human: The Surprising Truth About Moving Others.

Next page