Big refactoring

I started to refactor a file of a few hundred lines of code. I had a vision how clean it will look. It took more days until I realized it takes more time to refactor the whole file. My tech-lead suggested to cut the task which I did and refactored only one class. It became really cleaner. It could've been used as a base class but people didn't use it but continued to use the quick and uglier way of the other classes.

I started to refactor a file of similar size now because it always takes some mental effort for me and for me coworkers to understand the structure of the file. It was written by one of the coding heroes of the company, it's dense and tangled and still verbose at the same time. It takes a few minutes to run all the tests for it so I made a relatively big change that didn't look harmful, I was just factoring out some helper functions. When I finished, I ran the tests and they failed. I got frustrated. It took me quite some time to find out that I had forgot to set an environment variable before running the tests. There was even a warning printed that could've suggested that but it was lost in the many lines of other logging output.

Who commits to deliver the least Kanban points

We set up a Kanban-board. We start every week with a commitment, team members make an estimate how many points they will have done by the end of the week. Points are not measured as working hours because it would be different from person to person. We try to have a common measure of complexity points, it doesn't have a specific meaning, it's just an abstract unit. We just had enough planning session together so that two team members will probably give a similar estimate of a task in complexity points. This is further reinforced by the weekly feedback session when we sum up the actual points we delivered and talk about what had caused the differences between the estimated and the actual values.

The commitment phase is pretty frustrating and painful for me because it's usually me who says the lowest number. It makes me feel dumb and incompetent.

Programmers as seen by an HR manager

I know these are generalizations, but...

• Good programmers tend to be good musicians
• They give straightforward answers, sometimes at the cost of hurting other people's feelings without intending to
• They grasp the general structure and the gist of complex issues
• They want to find a solution right away
• It's difficult to find out what they're feeling in a situation. It can be pretty difficult for their managers.
• They avoid conflicts and other emotionally loaded situations
• They don't want to be (perceived as) nosy
• They are afraid of being seen assholes or using their power. That's why they lean on having a laissez-faire attitude.

If I attended a conference on programmers' psychology, I'd expect to hear some stories. For example how a newly appointed manager overcame a difficult situation. Or how an introvert junior developer can share his or her ideas with the team.

Important things I don't do

I'm going home now because a guy is coming to fix the heating system. I'll work from home for a few hours. I'll take some notes for my research which I don't do at the office. It would be quite appropriate to take notes about my life as a software engineer while being in the office but I still don't do that. Just like going out to the gym to work out which I also don't do. I am considered to be a mature adult who can use his time, I'm free to come and go to the office any time. There are even some guys who have a special schedule like coming to the office only in the afternoon and work until late night. Another guy goes to late night parties one day, then takes a day off, then works two days without a stop. And I know of others who have similar issues as mine, they don't do things they find important.

I also notice while eating that I had enough but I carry on eating.

Research on programming psychology

I hereby declare that I started my research on programming psychology. It doesn't have a clearcut definition yet but there is probably a common understanding what it could mean. Software engineers prefer to talk about... er... software. They may even talk about how much they love or hate a notion, such as a programming language or a framework. They will list certain attributes to justify their love or hate but they rarely talk about their emotions per se. As one of my co-worker half-jokingly put it, he doesn't share more of his emotions because he doesn't have that much. So the psychology of programming deals with issues programmers don't deal with.
I have two goals with this research. First, I want to get into the top ten of some area. Since I avoid competition, it has to be some really weird area where there aren't many competitors. I also want this area to include as much of my skills and interests as possible. There are many awesome programmers. There are plenty of great psychotherapists. But there are really only a handful of people who are good programmers and good psychotherapists at the same time. That's my territory.
My other goal is to expand programming experience to include other sides of human nature. There is some talk about coding as an art, being in the zone, the importance of having fun while coding, etc. Some programmers even go to coding dojos or retreats or record a screencast of their performing a kata. My dream is that one day programmers will code love poems to their partner, dance a difficult algorithm to fully grasp it and meditate at the keyboard. One day a senior programmer will just set up a little game of castles and dragons and their junior will love to solve it which will be the resolution of an underlying software task. So my other goal is to make those days come a bit closer.