Flashover

Weekly blog posts about creative work in the tech industry

Skip Mockups When Building Skateboards

Nov 11, 2018

If you need to deliver a usable product version in two weeks, you should stay away from mockups.

To explain more, I need to start with a software development picture from Henrik Kniberg that I keep seeing more and more frequently:

Henrik Kniberg's drawing of the MVP process

This picture teaches us that iterative product development doesn't mean that we deliver the final product in unusable parts to our clients. Instead, iterative product development should mean that we try our best to deliver usable versions of the product that we are building.

When building a car for the purpose of moving around in the world, our first deliverable isn't a car tire—it's a skateboard. This might feel like a useless or an unproductive development step. But it's actually a step towards true learning and meaningful software.

We can't give our client a car tire and learn about how they use it to transport themselves. A car tire won't enable you to move around. Our clients can't test their product assumptions with a tire.

The skateboard is different. Our clients can use the skateboard. When using the skateboard, our clients will learn more about what are the most important things about transport in general. We the developers will learn how our clients actually interact with a vehicle.

The problem with mockups

When a client comes to you with a goal or a problem they need to solve with software, your first design step should be to figure out what's the smallest useful thing that you can build for that client. When you have that figured out, you can start thinking about the minimum amount of functionalities and requirements needed to deliver something useful.

If your first design step is to open Sketch or Adobe XD on your computer, it's very likely that the north star of your design process won't be the smallest possible usable thing. Instead, you will draft a non-embarrasing version of a product and let that guide your development.

We don't turn mockups into actual software with one iteration. High-definition mockups are never that small in scope. Because of this, we break mockups down into smaller parts; we figure out in which order to build the final product. Our deliverables become car tires and not skateboards.

Additional notes

This post is mainly inspired by a discussion between Ben Orenstein and Adam Wathan on Full Stack Radio.

1f3c0.192x192

Junot Díaz and Being a Playful Creator

Nov 4, 2018

Last year the Pulitzer Price winning writer and professor Junot Díaz visited the city I was living in. I snuck into one of his talks he gave to the writer students in the local MFA program.

This week I came across my notes from that talk. They were short and they were primarily about the art of writing. But I feel like I need to share them with you. The notes reminded me how writing code should mainly be a source of joy, not anxiety.

***

In addition to writing his own novels, Díaz teaches writing students at MIT. One of the things he is able to sense from the students is the massive stress they have from writing. There is an intense pressure to perform well. It’s much rarer to find true joy and gratitude among the students.

These are three points that Díaz would like you to remember if you are feeling a little less joyful and a little more anxious.

First, you should play. Díaz compares writing to basketball. You can earn money from both writing and playing basketball. You can also write and play basketball just for fun. Here is one major difference between these two: it’s really hard to imagine a basketball player being afraid of the ball the same way a writer can be afraid of the typewriter. That’s because it’s so much easier for the writer to forget that there is play and joy involved in the process of writing.

Second, Díaz says that you should sometimes avoid your art culture. In this context, your art culture are your peers, critics, audiences and other relevant authorities.

Why should you avoid these things? Won’t this ecosystem make you stronger in your art? Díaz argues that your culture will try to destroy your childlike wonder and genuine love for your art. Your culture says that your art doesn’t have value if the critics don’t praise it or the public give money for it.

Third, there is no one right path. Not every writer will take the same journey. And more importantly, not every journey is suitable for every writer. There are options for you. So instead of stressing over your next move, just do something. Or don’t do anything and just play with your art.

***

When Díaz sees a student in their twenties struggling with writer’s block, losing sleep because of stress, and generally taking no joy from the fact that they get to write, he can’t but wonder where will this person be in their sixties. Will their mental state still be dictated by external validation? Will they still write from a place of misery? Will they spend the next 40 years basically torturing themselves?

The problem with being a writer is that there is no guarantee that your hard work will result in success. There is no formula for writing a best seller. There is no mind control device you can use to make people like your book.

It’s so easy to set yourself up for disappointment.

23f0.192x192

Interruptions That Lead to Interruptions

Oct 27, 2018

You have probably experienced the frustration of not being able to focus when a book, research paper, tutorial, or a cognitively challenging task needs your undivided attention. Depending on your job, the majority of these feelings of frustration might occur at work.

It’s easy for us to understand how a loud office and constant calls to your phone create interruptions for you. These interruptions reduce your ability to focus. You can’t hear yourself think. You are not able to get in to flow.

But maybe after a busy morning your office quiets down. Or maybe you move yourself to a quiet space after the interruptions become too much to handle.

The interruptions disappear. Your issue with focus and attention should now be solved.

Except you will still struggle to focus. Why?

Researchers Laura Dabbish, Gloria Mark, and Victor Gonzalez have found out that external interruptions lead to self-interruptions (Why Do I Keep Interrupting Myself?: Environment, Habit and Self-Interruption). External interruptions are interruptions caused by other people or, for example, software notifications. Self-interruptions occur when you abandon an ongoing task or switch your focus without an external cause.

A classic self-interruption is you switching your browser tab to Twitter or Facebook just because you felt like it.

Even though external and self-initiated interruptions differ in their nature, they are connected to each other. If you experience a lot of external interruptions you are more likely to have increased amounts of self-interruptions throughout your day. In their research, Dabbish, Mark, and Gonzalez conclude that “external interruptions experienced in the previous hour significantly increase the incidence of self interruption in the subsequent hour.”

We get used to a certain interruption level: People working in open offices experience more self-interruptions. People who feed their habit of multitasking experience more self-interruptions.

We are interrupted in our work every 4 to 11 minutes. And half of those interruptions are self-interruptions. The significance of self-initiated interruptions in your ability to focus is much larger than you probably thought.

What are the actions that you will take in order to reduce those interruptions?

1f6a3 1f3fe.192x192

Individuals and Interactions over Processes and Tools

Oct 21, 2018

Two weeks ago I wrote about the four agile software development values and how it would be great for all of us to every now and then stop and think what do these values mean to us and our communities. Here’s a link to that post.

The very first agile value is ”Individuals and interactions over processes and tools.”

For example, author and software engineer Scott Ambler decodes this value to mean that the most important factors you need to consider in a software team are the people and their ability to work together. Processes and tools aren’t of any use if the team doesn’t have the required technical skills or they just can’t work together effectively.

Before reading Ambler's essay, I had already started unraveling the first value by myself. My conclusion was a little different.

First of all, I interpreted “interactions over tools” as “discussions and experiences over Slack and email.” I’m willing to argue that in order to build shared understanding inside your team, you have to have real discussions around user stories or mockups. You can make communication more efficient inside your team with different tools but you can’t replace meaningful discussions with them.

You as a developer should also have empathy with your users and customers. This is where the experiences come in. For example Kevin Hale of Y Combinator suggests that your developers should work in customer support every now and then in order to live through the problems that your users have to deal with.

Second, a month ago I wrote about appreciating craftsmanship in your work. After sharing this post with my friends, one of them pointed out Daniel H. Pink’s book Drive. In Drive, Pink argues that employee motivation is a result of autonomy, mastery, and purpose. We are motivated when we can be self-directed, we can improve our skills, and when there is important meaning in our work. For a great summary of Pink’s book, I suggest you check out RSA Animate’s video about it.

These three sources of motivation were on top of my mind when I read the word “individuals.” Bureaucratic processes can reduce your sense of autonomy. Tools that do their job, but are out-dated or poorly maintained, can reduce your sense of mastery and craftsmanship.

I believe that purpose and empathy go hand in hand. When you have a deep understanding of how your product solves a problem in someone’s life, you get a sense of meaning in your work.

***

This is what my interpretation of the first agile value looks like:

Autonomy, mastery, shared understanding, and empathy over tools and processes.

I get it, It’s a mouthful. It’s also one possible interpretation of the first agile value. I’m not disagreeing with Ambler here. I think Ambler’s explanation is an important reminder that we can’t make all teams greater than the sum of their parts by trying to invent the perfect processes and tools.

***

Let me leave you with a question: What does “individuals and interactions over processes and tools” mean to you?

1f366.192x192

The Ice Cream Principle

Oct 13, 2018

Couple of weeks ago I was having lunch at our office. Me and my colleagues were talking about ice cream and our favorite flavors. Pistachio and salted caramel got mentioned. I personally like fruit flavored ice creams.

We didn’t even mention vanilla ice cream. No-one has a problem with vanilla but it’s rarely someone’s favorite. Yet, if we had gotten ice cream for the whole office after lunch, we probably would have gone with vanilla.

In fact, in Finland (and many other countries), vanilla is the most sold ice cream.

In Don’t Call It That: A Naming Workbook, Eli Altman calls this the “Ice Cream Principle.” It goes like this:

“Tell 10 people to go get ice cream with one condition: they all have to agree on one flavor. The flavor is going to be chocolate or vanilla every time. Groups of people don’t agree on what’s cool or interesting, they agree on what’s easy to agree on.”

Altman’s book is about giving names to products. The Ice Cream Principle reminds you not to make the naming process too democratic. However, you can still take this principle and apply it to other parts of your work.

If your goal is to move people instead of writing code, you need to incite people to action. You need to move people emotionally.

One way of doing this is to be interesting and cool. And vanilla isn’t cool. Wisdom of the crowd applies poorly to creating interesting things.

Next page