In January, I had a chance encounter with Julien Smith’s book The Flinch. It’s not a long read and feels like it came straight out of Fight Club — except you’re the main character and the book is your guide to life as written by Tyler Durden. If you’re unfamiliar with the movie, you should go and watch it — it’s a modern classic.

The main premise of the book is that you should face your flinch in order to expand your comfort zone. The flinch is the thing that makes you tense up and your palms sweat, its the thing that seems crazy but not really. The flinch is the thing that scares you but shouldn’t. It is the things that you make excuses for in order to get out of doing it. The flinch is your boundary line and facing your flinch expands it.

After the initial wave of learning has worn away and we settle into our day jobs, we become complacent with our skills and knowledge. We opt for Netflix and chill until there is nothing much else other than Netflix and chill. We tell ourselves that we already know enough of what we need. We stop learning. We stop exploring. We stop growing.

We stop everything that got us to where we are, stick to our comfort zone and become accidentally stagnant.

Tread the unknown. Learn what is uncomfortable.

As developers, we often become comfortable in a certain framework, library, mode of thinking, methods of coding and language that we use on a daily basis. We think of ourselves as grand masters of our craft — but we’re not. Things are always changing as updates get released and standards morph.

When was the last time you looked at something with an open mind? Are you aware of your biases and prejudices towards code? Do you get annoyed by updates, changes and complete upheavals that are outside of your control? The more entrenched we are in our ways, the bigger our flinch and fragility towards change.

A well-seasoned developer isn’t defined by their number of years but how open and resilient they are to change. It doesn’t matter if you have 5, 10 or half a century’s worth of work history in the industry, if you’re still coding the same way you did 5, 10 or 20 years ago, then you haven’t tickled your flinch and grown.

For me, React is an uncomfortable space. For the uninitiated React developer, Angular will feel equally as strange. But I’m learning something new and I’m seeing what I already know from a different angle. I’ve been tickling my flinch and in return, I’ve gained perspectives and new knowledge.

The power of projects

YouTube, tutorials, and code along can be great but when you are able to create something from scratch, you tend to learn a lot more. You learn the mistakes, errors, kinks, and quirks of a library, framework or language.

As developers, we are code engineers. Real life requirements do not come in cookie cutter solutions. When you create something from scratch, you learn things that are taught on a routine basis.

Projects let you discover your weaknesses and gaps in your knowledge. Projects force you to learn in order to achieve results.

Many developers stop creating after they get their first job. They neglect or give up their side projects. They become complacent to the 9–5. They blame the commute and lack of time. Life itself becomes an excuse and whatever priorities they have fall wayside with it. They use their day jobs as examples for their portfolios — but they can’t really show it off because the actual code they wrote is probably proprietor and can’t truly be shared.

Many developers do this because it’s easy. Projects often require you to tickle your flinch — to learn something new and implement it without guidance or help.

Projects are hard because you have to think, you have to plan your time and shift your routines to make room. Projects are hard because they require a certain priority in an already overstuffed life filled with other priorities.

And for that, we come with excuses.

Transform your life in quarters

The thing with tickling your flinch is that you don’t have to keep doing the thing that makes you flinch forever — just enough to expand your boundaries and make you less fragile to change.

Some people take up 30-day challenges for this reason. Others join #100DaysOfCode and hold themselves accountable on Twitter, even if its just 30 minutes of coding or learning something that’s not work-related.

100 days is not that long. That’s approximately just over three months, a little bit over a quarter of a year, or 14 weeks, or three full moons, or one school term, or whatever unit of measurement you want to compare it to in order to make it seem shorter. Life is long and 100 days is short when pitted against how long we’ve got left as a developer.

Final Words

What’s your flinch? For me, it’s learning React and contributing back to the community. I’ve forced myself to do both lately through writing and actively creating little experimental projects.

Some people complain that I’m writing too much and that I’ll burn myself out. But that’s not the point. I’m just working on expanding my comfort zone. Tickling my flinch has been the thing that’s helping me stay committed to my depth year. As the first quarter of the year is coming to an end, I’ve taken a step back and reassessed what my new flinches are. They are now the premise for my next major projects.

Fear of judgment used to be the reason for my flinch but now it’s not — well, not as much. Publishing frequently is my equivalent of taking a cold shower. It challenges my brain and flexes my ability to succinctly arrange my thoughts. It exposes my personal and professional weaknesses and helps me figure out how to be a better developer and a better human.

You gain a new sense of satisfaction when you tickle your flinch. You begin to recognize and realize that the things that are stopping you from doing what you need to do are just monsters in the closet.

So if you want to grow as a developer or reverse the effects of professional stagnation, start tickling your flinch until you don’t flinch anymore.