Programming = Climbing a Huge Mountain

2018-04-30

Just a year ago I was deep-train traveling southern Europe and I worked on ApiGen (here is a short story about that work/). I worked on a migration of the most coupled dependency, which was unmaintained for 3 years, to new one. You can imagine it like migration your application from Nette to Symfony or from Doctrine to Eloquent (or vice versa).

Rushing Up is Rushing to Fuck-Up

First I approached this problem in very... how do they say it... agile way. Let's start committing and see what happens. I was sure I'll be over after a week. Well, I wasn't and I was angry at myself. The faster I tried to finish it the slower I went.

And this rush got me to a situation I had to revert the whole PR and start over again, after a week of work.

Know Your Path

Then I stopped for a while and thought: Okay, I'm here under the mountain, there is the peak and want to get there. I don't see the peak or the way, I just know I want to climb this mountain.

I had one package and I wanted to switch to the other. What are the minimal steps?

Make Safe Spots

When you climb a mountain for the first time, you have rope, a buddy and clinch along the whole way.

These are all the safe spots and it's ok to use them. Well, unless you'd like to die climbing.

In programming I apply the same principles: I have tests, static analysis, coding standard fixers and CI. Without them, I'd be lost.

And are there no safe spots? I take a time before climbing and prepare these spots. I'll increase the code coverage for code part I'd like to work with - and that already gives me some hints, what the path looks like.

The same way you prepare for the climbing - you ask other climbers how it went, what are the hacks, where are the places to rest and where you should be careful.

Be Safe like a Pro

As you can see, it's no shame to use the spots, even mainly professional climbers do that.

Because the safer you feel, the better your brain operates and the faster you climb - either a mountain or a code you write.

Use Safe Spots

If you already have such safe spots, be sure to use them. I've seen many applications that had over 30 tests but didn't actually use them - no continuous integration, no simple scripts in composer that could run them locally with composer run-tests.

It doesn't matter that other programmer made it, that they don't cover 100 % of the code or that they use the other test framework I don't prefer. I'm grateful there is something that will help me to climb faster and that another climber made it for me, even though he didn't have to.

Staying in the Present Moment - One Move at a Time

Zen, Kaizen, Ikigai, Present moment, Deep Work, Flow. Whatever you call it, it matters.

When I program, I don't know what will happen in next 15 minutes. Maybe it will be over, or maybe I'll find a bug that I'll investigate for 2 hours in a row and then use this workaround.

I don't see the end, only the next step. Same is for climbing, I don't see the top of the mountain. I barely see 5 meters ahead of me. But even if I see the top of the mountain it doesn't matter. I can only move my hands or legs just a few feet ahead of me.

The present moment contains past and future.
The secret of transformation is in the way we handle this very moment.

One Peace Step at a Time (great book, just reading it). One commit at a time. One merged pull-request at a time. Not 2, just 1.

Take a Break

When you're tired, frustrated, angry or sad, will you rush to climb more and more steps? No, you'd take a break. Just hang on the rope for a while (not by the neck, it's not healthy!)... well, for 17 minutes as I learned in one of the amazing Pinkcasts.

It might be a coffee, it might be a transfer to another train, it might be toilet visit.

You probably won't believe it, but most breakthroughs come to me in the toilet room (intellectual, not physical damaging any part of the toilet).

Why? Because when the brain enters the serendipity-mode, it starts to think subconsciously and connect thoughts more effectively than with active thinking. For example, a few paragraphs up I made a workaround because key in the array didn't match the PostFile id in one spot. It worked in 3 other places in the application, but 1 just missed it. Then in my toilet time, it came to me that this can be solved by using a collection. One iterable immutable object everywhere.

Well, now it's like standing on the top of the hill and seeing the elevator that was on the left side all along. But when I was under the mountain, I didn't see it. I needed to take a break to see.

The Mountain Climber Way

So this is my climbing approach to code (I'm not a climber, to be clear).

The more you climb, the better you know the terrain and the more you can improvise. Like this guy, who climbed a 3000-feet tall mountain in 4 hours. Without a rope.

And how do you approach your coding?

Happy climbing!

---

Do you learn from my contents or use open-source packages like Rector every day?
Consider supporting it on GitHub Sponsors. I'd really appreciate it!