Sunday, July 27, 2014

Who commits to deliver the least Kanban points

We set up a Kanban-board. We start every week with a commitment, team member 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.

Wednesday, July 23, 2014

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.

Monday, July 21, 2014

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.

Saturday, April 12, 2014

SMART goals vs organic growth

I suppose there is a book on goal-oriented activity vs organic growth. This is a short review of that possibly fictional book.

The basic idea is that there have been two ways of being in the world. One can be characterized as putting Man in the middle. The most important question is what Men want and need, what Men can achieve and get. The other way of being puts Man to the second rank, removes the capitals and claims that men are subordinated to X. What X is depends on many things, it can range from the greater good of humanity to God.

Image by Seier

Both approaches have inspired people to create wonderful buildings, books, and gadgets. And both approaches contributed to bloody wars and injustices. So none of them is right and none of them is better. Both have their strengths and their weaknesses. They have a lot to learn and borrow from each other and this is very difficult sometimes.

There are ages when the one has a lead, at other ages the other has the upper hand. The Medieval Age in Europe was about subjecting ourselves to a higher entity. The Renaissance turned it upside down.
Religion belongs to the organic growth approach most of the time, it emphasizes that the rules of life are way too complex for us to completely understand them. We are small balls on a huge snooker table of greater forces. It’s not something we should be sad about, those balls can have a full and wonderful life. They are just not the main characters or directors of the play.

Rationality, on the other hand, has typically a goal-oriented world view. That’s the dominant and powerful ideology of our age. Since it doesn’t trust any higher forces to arrange things for us, it needs to invent methods to do that. Ethics is replaced by management. What shall we do to others? It’s a question of how me manage them. What shall we do to our life? It’s a question of how we manage ourselves. Spirituality is replaced by goals, even SMART goals. SMART is an acronym that stands for Specific, Measurable, Assignable, Relevant, Time-bound.

The first part of the book goes to great lengths to analyze the two sides of this dichotomy. A number of issues are discussed from both view points. My favorite chapter is about how we make decisions based on these models and how we justify them. The modern way to evaluate an option is to use what the book calls economic justification which is based on a simple (and flawed) syllogism.
If people buy more of something, they think it’s more valuable.
If many people consider something valueable, then it is valuable.

If people buy more of something, then it is valuable.
The second part of the book takes an unexpected turn. It’s basically about software companies and their methodologies. Traditional software development is considered to be an example of a goal-oriented activity with lots of process, systems, all measurable and managed. The Agile turn gave rise to dynamic startups that have a different mindset. They say mantras, like Release early and often which may result, oh horrors, in missing features and buggy code. They say, YAGNI, short for You ain’t gonna need it, when a smart guy implements something for the sake of a possible future request.

But agile startups haven’t realized yet they differ not only in their methodology (and budget), but also in their philosophy. They are to become the new advocates of organic growth. To grow software organically is a humble and controversial approach. It basically says, don’t plan large systems, because they are impossible to implement. Create a small program, share it, find a place in the large ecosystem where it fits. This is exactly how open-source components and repositories work.

The last chapter of the book is a bit inconclusive. What I like about is the idea that software development will fully recognize its potential when the SMART goal will have its organic counterpart. Let me give it a try how it would sound
  • Holistic
  • Subjective
  • It’s done by many people, some of them even anonymous
  • Dreamlike
  • Take your time