Flashover

Weekly blog posts about creative work in the tech industry

Previous page

Page 2 of 5

1f504.192x192

Back to Basics with Agile

Oct 5, 2018

This week Harvard Business Review published Why Agile Goes Awry — and How to Fix It by Lindsay McGregor and Neel Doshi. The article argues that many of the companies who claim to be agile have actually forgotten the four agile software development values defined in the Manifesto for Agile Software Development:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

It’s been a while since I read those values. It’s actually possible that the last time I read them carefully was when I was still studying at university. This is when I had no real-life experience in software development projects. I had no idea how much is contained in these simple statements.

Before we continue, let me acknowledge the fact that I currently have zero professional certifications. Since my university studies I haven’t done any formal courses related to agile software development practices.

I do read and listen to content related to project management. I work in a company that promotes agile working methods. However, I wouldn’t be able to give you a detailed explanation on how Scrum works for example.

I’m telling you this because I don’t want you to read this post as a guideline to how agile works. Instead, I’m hoping that this post will inspire you to reflect on the agile values themselves.

You might be now thinking that, unlike me, you do remember these values. You know agile. But keep in mind that agile is not like riding a bike. You don’t learn it once. You will forget what agile is really about. Bad software development habits will creep in if you don’t pay close attention.

You will diverge from the agile software development values because it’s so easy to keep your focus on processes and tools instead of individuals and interactions. You will try to ignore change by following your carefully made plan.

You might also go to the other extreme: you’ll start remembering “Responding to change over following a plan” as “Don’t try to make plans.”

McGregor and Doshi suggest that your team should have a habit of “constantly diagnosing and iterating [your] operating model.” Some teams do this diagnosing on a monthly basis.

These teams know that being agile is about finding a balance over and over again.

***

Lately I have found myself obsessing over processes and best practices in software development. At my work I’m going to take a pause with that stuff for now. Instead, I’m going to obsess over the four agile values.

At the time of writing I still don’t have a good idea of how to make this reflection a regular habit. I’m starting by taping the agile values next to my desk.

Printout of the agile software development values

1f6a6.192x192

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.

1f3a8.192x192

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?

2699.192x192

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.

1f4cf.192x192

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.

Next page