You may be wondering why I have not written over the past five months or maybe forgot all about me and my blog. First things first, I confirm that this is not due to a pack of angry developers sending me to the hospital for my previous entry. I had a pretty busy time and struggled with the personal expectation of writing a post as interesting as the previous. Indeed, I did write a whole host of drafts but could not quite put my finger on what missed. It is not until recently that I realized I should ignore the pressure. Take action and just jump into it.
The worst that can happen is that I publish a bunch of ramblings that don’t get viral and it is perfectly fine. Funnily enough that realization made me see a pattern in my previous draft attempts. Despite all being very different, they all revolved around an idea: Taking action.
Taking action to move towards a goal
Over the years I have learned that no matter the domain nor area nothing was worse than inaction. I always urge people to take action because in the end you most likely will fall short. You can make all the preparation you want, practice over and over again and things might still go south. I believe that what matters is how you react when things do not go your way. Anyone can follow a set of instructions or a plan when the sky is blue and birds singing. True story time! Until a few months back I had a colleague who was great at following instructions. However, the moment anything threw the plan off the window he would be completely lost. Fast-forward to now he is a former colleague, you draw your conclusions.
Don’t get me wrong, it is perfectly fine to prepare implementations and this is not specific to software development. As a matter of fact you would be a fool not to prepare for anything. But this should not put you in a state of paralysis.
You will want to shop around and visit a few properties before buying a house. Indeed, have been visiting places in London for a bit more than a year now and just found one that might do the trick. But you would not want to plan for a perfect house that you may not see before a decade. That would depend of what your goal is. Personally I would rather pay off a mortgage slightly higher in a better property rather than rent ten years longer. At least if I sell the property I will likely get away with more than a month and a half of rent worth of cash.
The point being, plan yes but make your plan and goals concise enough. If you follow that principle I can guarantee you will be able to take action faster in a context still aligned with your goal. If you don’t make it in the first try at least you learn and move slowly towards your goal. Let’s take
Misaligned goals can lead to inaction too
A specific goal is a huge help to list actions to take and follow through. Over time, I found in a wide area of pull requests and a lot of them can get stuck due to the lack of a common goal. Or at least a lack of understanding of said common goal. Let’s take a the tech example of a pull request for a feature to be built.
What is a pull request?
Usually a developer would get a ticket ideally written by a business analyst that would give you the assertions that need to pass. As TDD goes that developer should not go beyond these assertions unless a missed assertion would ruin your software. There is a clear goal, writing software that matches a set of business assertions. There is also an implicit list of actions to be taken. First, writing some automated tests representing the business assertions. Then, writing some code to build the feature. Next the developer would have a build system validating their changes do not break anything existing. Eventually, someone, potentially you, would review the code and merge it. An exception would be that something heinous hides in the pull request that is likely to harm the whole system and you request for its removal or adjustment.
The lost reviewer
The problem is when as a reviewer your goal is different from the reviewee. Most likely you need to hit your own target for the sprint and skip the pull request altogether. Maybe you think you need to check every bit of detail in that code and you need to book a day even for a minor piece of code. Picture having all the basics safeguards in place. Business-based automated tests, continuous integration and fairly clean code. What’s holding you from pressing that “Approve” button? From my experience it’s the fear of missing something.
Something that more often than not has nothing to do with what the changes are about. That is a perfectly fine fear to have as long as it doesn’t paralyze you or your colleague. I have seen pull requests held for hours, days and even months in the most extreme cases. Every single time I saw a pull request taking months to go through without much changes to it would be due to different goals within a team. Even then, it is better to address the issue and try to resolve rather than avoiding a conversation that will help everyone. Once again, inaction will only cause harm especially when sought after.
And you know the funny part about it? You will most definitely miss something that will bite back days, months later. Resulting in time wasted for yourself and your colleague for potentially nothing. Obviously if you’re writing software for a nuclear reactor you may want to be more careful than say for a shopping app.
The jet-ski action
Let’s pick a fresh example closer to home. A few days ago I returned from an Arubia holiday. While there, I went to Eagle beach with my girl friend. While talking, the fact neither of us ever went on a jet-ski came up. I was not super pumped for it as I had a few concerns about what could go wrong. Mainly around falling off the machine. The biggest concern with a low chance was falling off and dying getting hitting my head somewhere. Another concern with a higher chance of occurring would be falling off and not be able to climb back up in the middle of the sea. I’m a pretty big guy and despite my return to regular exercise over the past couple of weeks the risk was real. I carefully followed the instructor’s guidelines and prepared as much as I could.
When the time came I went for it with my girlfriend sitting behind me. You will not believe what happened next. After a couple minutes riding, well more like bouncing off water, what was bound to happen did. We fell off. I’m a terrible swimmer yet managed to swim back a bit behind my girlfriend who is surprisingly good at it. All within a few seconds also managed to climb back pulling from my arms. From there my worries were gone. I faced the worst that could reasonably happen. I dealt with it using the strength built exercising at the gym. This made me learn it is okay to fall because I know how to get back up. If I spent too much time evaluating unlikely risks I may have missed out on the fun I ended up having.
And more in the taking action section, I recently started recording a podcast as I wanted a hobby further away from tech. One last action in this post is plugging it in. It’s called People + Drink = Words and is available on iTunes, Spotify or straight from the website. Go and check it out!
