Initiative

Some months ago we wanted to get a new developer on the team. My personal desire was to get him as soon as possible and of course I needed our recruiter's help with this. We had a short discussion with the lady about the kind of a person we'd like to hire and I was sure that we got on the same page and seeing the right candidate is only a matter of days. However, some weeks passed and I wasn't getting any resumés and not a single interview was scheduled. I was concerned almost to the point of going to the recruiter with the WTF?! expression in my face. Fortunately, though I chose to spend some 20 minutes writing a short description of two types of candidates that fitted my needs and emailing these to her.

What happened next surprised me a lot. Almost instantly I started getting a constant stream of CVs that matched my descriptions. It took us a couple days to schedule the first interview and only two or three weeks later (which means pretty soon in this context) we made an offer to a bright young fellow.

This story taught me a great lesson. I may believe that I have agreed on the goals and plans with someone, but if there is a slightest chance that doing some simple thing may help them get going I should do it without doubt and waiting. Spoken agreements made with your peers in a walkway are rarely clear and may easily get pushed away by newer and more comprehensible tasks coming from elsewhere. On the other side, taking some initiative to follow up and elaborate the problem may bring tremendous results.

Another example that I have on the same matter is concerned with an internal knowledgebase for developers. Despite having a vast code base rich with patterns and non-trivial solutions to various problems, we had limited guidance on this treasure and the reasoning behind its bits. Certainly our developers could benefit from a knowledgebase that would collect advice on various development questions.

I had a plenty of ideas on why we didn't have the knowledgebase, including the conspiracy theory that my other colleagues knew why such a thing wouldn't work. It turned out, though, that the only real reason for its absence was that being loaded with other tasks we simply didn't chose to set it up at some point. Thus, once a dedicated section was created in our internal wiki and declared a place to store all development-related knowledge, I started seeing different people contributing an article or two or simply voicing  support for the idea.

Starting things is difficult and if that's true for you, it's likely the same way for your friends and colleagues. Sometimes people lack a clear picture of the destination, in other cases they simply don't perceive the goal as important to anyone. No matter what's the core reason, just showing some gentle initiative may be enough to start the fire and get things going. It's only important to remember that initiative is not just about talking or thinking - it's all about acting, making the first step and showing the way.

Focus

There was obviously little activity in this blog during the recent months and I feel great returning here. The blog always gave me an opportunity to step back and think over my actions and choices. However, this year I was so focused on a single thing - my day job - that only one post had made it here. Now I want to check with myself what this attitude gave me and what it stole from me.

Last February my priorities changed dramatically. In about two months after becoming a team-lead I discovered that whatever I was doing was not enough to do good with new duties. I was both overwhelmed with the tasks and problems that fell on our team and saw clearly that we don't perform as good as we could do. Part of my natural response to this discovery was to ramp up the amount of time that I dedicated to the job.

There are lots of reasons why I'm happy with this choice. Firstly, putting more effort into work made me learn a lot and build up new skills in the areas of my responsibility. Because it was my duty to process all the requests that arrived at our queue, I learnt to do this efficiently and obtained a lot of domain knowledge. In other words, it turned out that it's enough to push me into a partially familiar field and show no way out to make me learn it deeply. My expertise grew enormously over the last year and being really focused on the job helped here a lot (yes, there are lots of things in my field that I still don't know or understand not good enough - I'm speaking only of the delta). Moreover, spending a lot of time studying and resolving various issues - some being totally unclear at first - I not only learnt new areas of the domain, but also developed a skill of learning faster.

At the same time, through spending extra hours on duty I came to see clear that sometimes one cannot address problems by simply working harder. When you do a lot and it doesn't help, you start to see deficiencies and acknowledge the need for changes in one aspect of the job or another. A different edge of this same idea is that one cannot do everything on his own. No matter how hard you try, there is always less done than left to do. These discoveries, combined with high exposure to the issues that we face, constant analysis of our work and search for means to improve it - all of these being enabled by having extra time - certainly brought positive results and helped me develop myself both as a developer and as a manager.

On the other side, the same willingness to work more than 5x9 had a negative impact on the manager role of me, because having more time I could in many cases take the responsibility for any new urgent issue or task. While this attitude helped me tackle problems in time and develop my own skills, it hampered the team's collective progress. Any problem brings new knowledge and shows ways for development, so I simply stole a lot of opportunities from my fellow team-members and hampered knowledge distribution.

Generally speaking, while my attitude helped me grow in terms of knowledge, skills and career, it also shadowed both opportunities and problems. It is a very important lesson for me: whenever one decides to tackle a surge in the amount of tasks by throwing in more (his own) manforce, he misses an opportunity to find more intelligent ways to solve problems and to use them as the points of growth .

These are the effects of the extra work on my job, but there are also those that go beyond my office life. First of all, I left the attempts to do programming and software development in the outside - this means all side jobs and projects. While these used to bring new opportunities and ability to study unfamiliar areas, that's not something that I regret much. Being focused on one area allowed me to grow more than attempts to handle both the main job and one or two similarly looking activities would permit.

What I do regret is that leaving less time for myself I started to pay less attention to continued study and learning new things - both around software development and outside this field. I totally stopped exploration of new programming languages and tools and did much less learning in other areas than I used to - namely, I didn't complete a single online course over the recent months. That's certainly something that I shouldn't have forsaken:  these activities could both help me do my job better and make me expand my knowledge and interests.

Another thing that I dislike is that I quit writing for the blog. Here the reason is not only that the blog has become a silent and lonely place - it was never crowded here. The real problem is that writing less I lost the habit to deeply think over whatever I do and to search for interesting problems and irregularities in my activities. Of course, I do reflect on my decisions and actions, but without regular writing I hardly do it in a systematic and efficient way. Moreover, without posting to the blog I avoid sharing my ideas, which is not a big loss for society, but a shameful cowardice of me.

As with any choice, there do exist both positive and negative sides to putting most of your effort into one area of your life. I see these and despite the cons I am going to continue along the road that I started almost a year ago. However, even though I will continue to pursue that sweet feeling of exhaustion, I do need to make certain adjustments to address some of the problems. In particular I will certainly pay more attention to the supporting activities like learning and blogging - these allow to widen perspective and spot issues that stay invisible when you are constantly inside the problem-solving loop. At the same time, staying focused on my job I will have to pay more attention to the things that I am busy with. After all, being totally occupied with the day-to-day activities is a direct way to keep doing wrong things. So I only need more thinking, more analysis, more writing and the same amount of job. Good to know the solution to one's problems, huh?

A Project Makes You Sick? Just Work Harder!

A couple weeks or so ago I faced a problem with a project I am working on now. On that stage I was busy creating a mobile application and really struggled with it. I felt that the UI is ugly, usability sucks in every possible way and some features are almost impossible to implement with the approach that I have chosen. This all led to a wave of disappointment – maybe the strongest one over the last months – crushing on me and to a sensible desire to give the whole thing up. Fortunately, this time I managed to overcome these feelings relatively easy and soon got excited over the project once more – at least in comparison with how severely negative I felt about it in the middle. The way I did this was very simple: I used a pretty effective weapon to fight tiredness – I have chosen to merely put more time and effort into what pissed me off.

I can’t remember where I picked up the idea that when feeling tired one has to work harder and it will get easier – it just feels pretty natural to me and I have been trying to follow this piece of wisdom for several years already. This way when I really feel exhausted with everything that I am busy with at the moment, I can use this idea to give myself a shake and get going further. The truth is that even though I don’t completely understand how this can possibly work, it keeps helping me get rid of apathy and tiredness. Besides, it is cool to be that nasty guy who responds to someone lamenting about being too tired with a phrase like “you just don’t work hard enough”.

At the same time I always thought that this approach to getting out of "too tired" mindset has anything to do only with the amount of work that one does and the actual tiredness. However, it turns out that it’s not the case and this same approach scales down to the level of particular projects pretty well. In my most recent case just forcing myself to fight through the unwillingness to continue the project literally made me see a lot of important things from different angles and actually understand much of what I failed to grasp before. However, even though it might seem that I got an “energy replenishment” of some sort from this act of overcoming exhaustiveness, I believe this works in a bit different way.

The real reason behind my apathy was that I started seeing a lot of mistakes that I had made in both design and implementation of the application and didn’t know how to fix them in any reasonable way other than rewriting everything from scratch. Moreover, the more I worked on the thing the more problems surfaced and the more depressed I got with them – finally arriving at the state where I wished nothing more than quitting the project. On the other side, when I built up some strength to overcome this desire and continue pushing the thing further it did get much better. Quite quickly I got valuable insights from my furious attempts to improve the application in various ways, which made me see all my faults and problems clearly. These, in turn, gave me the idea of the right way to tweak existing code, which would both save me from some of those errors and allow to move further.

The overall lesson is that the advice of just working harder when one feels tired is not as dumb as it may sound at first. Of course, sometimes it is a good idea to actually get some rest, but in other cases making yourself continue to put effort into a project even when you can’t stand it anymore may be very fruitful. Part of the trick is that, like with my mobile application, the same issues that make you hate the project in combination with the time spent thinking about it will likely help you understand what you want the thing to look like. So, when you face the idea that what you are working on is utter crap and you don’t want to see it even a moment longer, consider putting these thoughts away. Instead simply try to push harder, hack some code and make a bad UI even uglier – I am sure this will help you see your problems clearly and give you and idea where to go next.

What do you do when a project of your's becomes unbearable? How do you help yourself pass the stage of despair and apathy? Or maybe something deep in your mind allows you to work smoothly without even facing the problems of this kind? It'd be cool to hear from you in the comments!

(By the way, it may be not evident but I was literally on the edge of giving up this post somewhere between the 2^nd and 3^rd paragraphs. Still, I made myself continue and finally ended up with something that I can publish.)

TDD: Tests are for Focus

In recent posts I have written much about testing as an inherent component of the software development process – the last one, for example, was devoted to some drawbacks of having tests. Now, to keep things in balance I will turn to an advantage of TDD which I happen to mention much less frequently than it deserves.