It's in your process

Don’t touch my code

Starting career from zero to hero we all focus on technical skills. How many languages, frameworks, technologies we know, how efficient our sorting algorithm is, how optimal our query is, how fast we can refactor your code, and lots of other “hows.” Later, when minimal valuable level of professional knowledge is archived, people start focusing on so called soft skills. According to Wiki they include combination of communication, social, emotional skills, including but not limited with common sense, positive attitudes, and ability to deal with people. Then we become more mature and our professional interests diverse from “what” and “when” to “who” and “why.”

Based on questions that are interesting to us our professional career goes into directions of managers (if you like to control an uncontrollable environment of idealistic developers) and architects (if you like to control an uncontrollable environment of development ideas), technological guru (if you understand that only thing, you can control, is you and your code), entrepreneurs (if you want to control everything at once), agile coaches (if you really love colorful stickers) and surfers (when you finally understand that it’s much easier to control nature).

But before that magical idea bulb of understanding finally appears, we work as developers. There are many skills we need to have to be professionals. But there is a one skill that is, on my opinion, completely underestimated. Mostly nobody puts it explicitly to job description, nobody teaches it, but everyone faces lack of it at some point. This skill is to let your code go… to trash.


It's in your process

Why 55 is a perfect length

Procrastination and lack of motivation happen all over and anytime. If you google, you can find lots of pages describing difference between procrastination, laziness and motivation gap. In most cases they describe a problem from individual, personal prospective, some of them however take the topic more specific as lack of motivation in a company in general or on specific project. Especially LinkedIn is full of such articles, mostly sponsored ones. But how to understand that your project stuck with progress, motivation is low in general although some individuals are still fighting with circumstances?

You still deliver necessary functionality, and you still get your story points and necessary velocity, but something is wrong. Especially hard to understand if it’s a temporary state or first sign of hard-to-solve problems. Here is when we understood that our project was facing procrastination in full strength.

…when you understand that you have nothing to do

We use wide know procedure of cross-team code review. Also, we have a dedicated people who is responsible for specific parts of a system, and as you may understand, get all code-reviews on dedicated topic. There is an example we had recently.



Starting with…

Everything has a beginning.

Morning starts with coffee; day starts from a stand-up; problems start with “let me change one line”, questions start with “why”, answers start with “have no f*cking idea, but I guess”, refinement starts with a delay, meeting starts with “round drink” bell, annual appraisal with “you know it was a tough year”.

The code starts with the first line; problems start earlier with vague concepts, wrong assumptions, badly refined tasks, poor requirements, architect’s day-off, broken coffee machine, wrong version of node.js. Code generates bugs together with added value to solve functional problems. It may take hours to solve a problem, and even more to find it. Problems and bugs irritate us, make us angry and grumpy. I’ve never met a person happy with bugs, neither among developers, nor within management team. But everything has a purpose even if it’s not clear from the beginning.

Despite obvious purpose to postpone release or spend some extra overtime, the main purpose of problems is to move us further, to let us try more, break more, fix more. But if we want to achieve this Code-without-bugs nirvana, we need to reflect on problems, spend time analyzing not only solutions, but a root causes, wrong prerequisites, mistakes. It’s important to find a solution, but it’s not less important to trace a path to this solution. Because you may need to do it again. Or at least to use it as an ode to the one’s genius between juniors. In this blog we will try not only show the solution but the way to solve it, an environment where problems occurred, specific conditions that made a ground to grow mistakes.

Not all problems are in you code. But those that are in you code apparently are much easier to solve, even if it takes hours to parse logs, takes days to reproduce, takes nights to think about. You need to search, read, apply, throw solution away, search again, read, try, ask somebody, try again, drink coffee, curse loudly, preferably on foreign language, try again and again, and again.

Everything has a beginning, and it starts in your code.