Monthly Archives: December 2009

The whole idea of “learn a new language every year” is that you are a programmer. Programming is what you do. You are defined by being a programmer, by writing code. That is you, right? And it is a type of craft, and it requires craftsmanship. And in order to develop that in yourself, you learn a new language every year, and you develop yourself as a programmer.

Chapter 3: A Problem-Solving Style

(This is part 3 in a series of posts where I document my progress through reading Becoming a Technical Leader: An Organic Problem-Solving Approach by Gerald Weinberg, answering the questions at the end of each chapter)

1.  Observe someone you consider a leader.

“Make a list of this person’s activities when working with others, and see how many of them fit into the categories of understanding the problem, managing the flow of ideas, and controlling the quality. Are there activities on this list that you never do? Why not?”

For this, I’m going with a project manager I used to work for. His way of working was first to get a cursory understanding of the problem. Sometimes he’d go deeper, sometimes he’d decide it was something he didn’t need to understand it thoroughly, so he’d just dish it out to the team. At that point, he would “fan the flames” for every spark of an idea anyone had, and if there was nothing, he’d try seeding the discussion with an idea of his own – sometimes a sane one, sometimes a clearly ridiculous one. Anything to keep the floodgates open. He also had a knack for figuring out ways to test our solutions. A little bit of something for every category, then.

I’d say that while I’m fairly apt at understanding problems and testing the quality of solutions, I’m not very good at encouraging ideas. In fact, I tend to either quietly think to myself or dominate the whole discussion, being more of a participant than a moderator.

2. Observe someone you don’t consider much of a leader.

“Make a list of some simple opportunities for exercising leadership that this person misses. Do you miss these same opportunities? Why?”

I know one person whose role in the team officially sets him up as a leader. Yet he would much rather delegate the day-to-day leadership to someone who is officially in a position of less responsibility. I do think I miss some opportunities just like he does – sometimes even on purpose, if I’m not feeling up to it.

Back when I was officially a “senior software engineer”, my mistakes were of a different sort. I put myself up on a pedestal, but then didn’t actually live up to that image, and didn’t really lead at all.

3. Do you ever have trouble getting people to pay attention to your ideas?

“How do you react to their ideas?”

Sometimes I see people so stuck in their particular train of thought, that they won’t actually consider any idea that doesn’t fit their mental model of the problem. It’s tolerable for a while, but if repeats often enough, I tend to flip the bozo bit on them. After that, I typically dismiss their ideas without thinking them over – not consciously, though. Sometimes I manage to catch myself in time and actually consider what they’re saying, after which I assess the idea on its own merits.

4. What techniques do you use for gaining perspective on what you are doing when you are working in a group?

“when you are working alone? How might you improve your ability to see your own actions?”

Usually, if my approach doesn’t work and I get frustrated, I launch into meta-mode, circling around the problem and my mental model of it. If I’m actively working with a group at the moment, I’m likely to fall quiet and zone out. When I’m already alone, I don’t need that extra distance. Sometimes I use instrumental music to focus. I tend to reflect on my own actions a lot afterwards, but if I’m in a particularly emotional state, I can’t view my own actions very subjectively even in meta-mode. I need to learn how to keep my cool.

5. Next time you work with a group, list all the things you do to exercise leadership.

“If you don’t have at least ten items, do the assignment again, and keep doing it until you get a list of ten things out of one activity. When you have your list, put the items into categories of understanding the problem, managing the flow of ideas, and controlling the quality. Does your style tend to favor one category over the others? Which of your actions don’t fit into any of these categories?”

This one is hard to answer now, because I’m about to leave my current team, and most everyone else is on vacation. I’ll have to come back to this one later.

6. Overall, what new actions would you need to practice to strengthen your style as a problem-solving leader?

I need to set my own need for approval aside, and instead of obsessing over being the one who solves the problem, learn to be the catalyst for it.


Previously: Chapter 2: Models of Leadership Style Next up: Chapter 4: How Leaders Develop

Chapter 2: Models of Leadership Style

(This is part 2 in a series of posts where I document my progress through reading Becoming a Technical Leader: An Organic Problem-Solving Approach by Gerald Weinberg, answering the questions at the end of each chapter)

This chapter develops a model for discussing an environment for leadership. The model has three parts: Motivation, Organization and Ideas, abbreviated MOI.

[Edit: I missed one question when I typed these up. The missing question was number 5, and what I posted as question 5 is now question 6]

1. How would you characterize yourself in MOI terms?

“What were you like five years ago?”

Currently I’d say I’m highly motivated and fairly well stocked in ideas. In the last five years, the biggest change has been in the idea department, as I’ve gathered experience, read up on new ideas and tried them out. My motivation has been fairly high all the time, and stable at that. I’ve never been very organized, ever. I’ve even tried a bunch of ways for keeping organized. Some of them even worked (for example, making a daily list of things to do). I tend to abandon them after a run of success, though, after which the inevitable decline happens.

2. How much are you willing to do to change your MOI profile?

“What specific actions do you have planned for the next five years? next year? next month? tomorrow? today?”

The previous answer highlights one of the things I know to be my, let’s say *cough* less strong aspects. I don’t really feel much of a need to change the M axis, and the I axis is covered in my constant push for learning. However, the O axis clearly needs work.

I’m willing to give almost any sane method a try. It doesn’t make sense to try fixing this problem on the very long term, but evidently the short term isn’t right either. Perhaps a month of practice coupled with weekly notes on how well things worked would be a good start.

3. Can you think of specific events that triggered an agreeable change in your MOI profile?

“Do these events have anything in common? What can you do to increase the frequency of such events?”

The last clear milestone I can think of was when I began to have a kind of focus in learning. It was approximately five years ago, when I realized I couldn’t expect my co-workers or bosses to tell me how things should be done. The previous one was triggered by uncertainty of my own proficiency at work. The events are almost polar opposites, but both drove my motivation which in turn helped me stock up on ideas.

The best way to drive this sort of change is likely actively going outside my comfort zone.

4. Do you have a different MOI profile at work than you have in your life outside of work?

“What does this tell you about yourself?”

I think the differences are negligible. I very much identify with my professional persona, for better and for worse, which is probably the main cause for the similarity. One interesting difference is that outside work, I’m more comfortable taking a leadership position and being a catalyst, possibly due to the less severe responsibilities involved.

5. Is your current leadership style contributing to your happiness?

“to the happiness of the people around you? to making the world a better place for everyone?”

Outside work, yes. At work, a little less, maybe. I don’t think I have a significant contribution in making the world a better place, but just like you can die from a thousand paper cuts, a thousand tiny little things that are better make up for one bigger thing. In that sense, yes.

6. At the moment, does your principal motivation for change come from promise of reward of fear of punishment?

“Is this the best mode for you? If not, what can you do to get more of the other kind? How about some other kind of motivation entirely, such as an increased sense of self-worth?”

I could have chosen to stay where I am now, as I am now, and gain rewards for that. On the other hand, trying to step outside the bounds of what I usually do is, at least in my mind, more risk-prone, and as such, more likely to result in ‘punishment’. Therefore I’d say neither of the two apply. Instead, an increased sense of self-worth is a fitting description for my motivation for change in general, not just this particular exercise in changing.


Previously: Chapter 1: What is Leadership, anyway? Next up: Chapter 3: A Problem-Solving Style

Evolving code and the language of programming

Some days ago I stumbled across this passage in a blog post titled “Code fast”:

“Students simply cannot code fast enough to express themselves. When confronted with a problem, particularly a small algorithms problem, my first instinct is to write a little snippet of code for every solution I dream up. I can do this, because I write code very quickly.

My students can’t. They simply do not have the practice at expressing themselves rapidly using these thinking machines which surround us, which means that any and all of their programs are arduous constructions which must be carefully planned in advance because the cost of doing it wrong is many hours wasted.”

This managed to give shape to a thought I’ve had on more than one occasion. While the time I spend at the university is too little for me to observe this in students, I see it a lot at work.

I keep being amazed by programmers, who would rather tack on an extra ‘if’ clause and make code more complicated, rather than take a step back and recognize that it could be dramatically simplified. This usually happens when either the problem statement – or their understanding of it – changes.

Where I see code as a living thing, they see it as a static construct. The first time I really paid attention to this difference in views was when a co-worker in my current project came to ask me for assistance.

A while earlier I helped draft a solution to a problem we had, but I didn’t spell out the exact details. Instead, I just explained the gist of the idea and waved my hands about regarding the implementation. This wasn’t quite enough to get him started, though, so he came to me to ask for more specific things.

I don’t have much faith in UML, and I didn’t feel like drawing a picture anyway, because I didn’t yet have a clear design in mind.  Instead, I explored the problem and potential solutions by writing code.

First, I wrote a bit of structure that got me started. Next, a bit of actual, working code. A moment later I needed a similar block in another place, so I quickly extracted out a method. Then, after a few additions and modifications, the extracted method became unnecessary, so I inlined it again. I wrote a conditional clause, and the next moment inverted it because I felt it would be clearer that way.

When I was finished, the co-worker fell quiet for a moment, then said: “well, this was certainly a learning experience. I believe I saw four different versions of that code in under a minute.”

It’s a language in more ways than one

“Programs must be written for people to read, and only incidentally for machines to execute.”

Harold Abelson and Gerald Sussman

Expressing yourself requires a language. Expressing yourself in the form of a program requires a very specific kind of language, and that language is called ‘programming’.

A writer should always be willing to change their text to better convey the message. A programmer should always be willing to change the shape of the solution to better match the idea behind it. Unwillingness on the writer’s part leads to sentences that are tiresome to read. On the programmer’s part it leads to programs that are hard to understand.

Willingness alone is not enough, though – to pull it off, you need fluency in your language. When you’re a beginning programmer, programming is a foreign language, and you have a small vocabulary. Imperative programming suits this skill level pretty well, because you can just string together a run-on sentence that you call your program.

After a while, you become more proficient, and learn how to shape longer expressions. At this point, the programming language plays a larger role, as it encourages certain sorts of expressions and limits others. The differences here are most pronounced between classes of programming languages – rather a lot like families of natural languages.

Finally, there is the culture behind the language. You can’t expect to be proficient in a foreign language without at least a cursory understanding of the culture that shapes the language. In programming, that culture teaches us to think in abstractions, keep our abstractions cohesive, our dependencies minimal and our interfaces clean, among other things.

A programmer in touch with the culture is far better equipped to communicate a solution to both the computer and the maintainers of the code than a programmer having trouble putting together a succinct sentence.

Parting words

I’m not sure I’m even close to anything resembling a conclusion here, and I’m finding this post particularly hard to wrap up. There are a lot of related things I would like to write about, but this is already the fourth revision of this post, and as they say, “real artists ship”. In the end, I’m leaving you with a promise to return to the subject, along with yet another quote:

“A language that doesn’t affect the way you think about programming, is not worth knowing.”

Alan Perlis: “Epigrams in Programming

Chapter 1: What is Leadership, anyway?

(This is part 1 in a series of posts where I document my progress through reading Becoming a Technical Leader: An Organic Problem-Solving Approach by Gerald Weinberg, answering the questions at the end of each chapter)

1. Observe someone you consider a leader.

“How is this person’s life different from yours? Which of these differences are a result of being a leader? Which of them are a cause of being a leader?”

The first three times I read this question, I tried to search my memories for true leadership from my own work history. Then I realized that my perspective is far too narrow.

I have an old friend who is a natural leader. He was clearly the alpha, but for the most part, he also made a point of caring about people around him. Back in the day I’d disagree with him over a lot of things, yet happily follow him most of the time. I think he also has a narcissistic streak – at the very least, from time to time he would obviously put his own agenda or ego before everything else. But then, he’d also be brutally honest about that side in his personality, which made it tolerable.

From what I hear, he has things pretty well in order these days. Family, kids, whatnot, whereas I’m still figuring out what and who I want to be. I think he’s always had an inner vision of what life for him should be. The differences between me and him are probably mostly the cause, not the effect, of him being a leader.

2. How would you expect your life to be better if you increased your leadership skills?

“Which of these improvements will arise from your changed behavior, and which from recognition of the changed behavior from other people?”

Increased confidence, I think, primarily. A self-image that isn’t in constant flux. This answer may be a bit misleading in that I don’t expect that to happen as a result of the things I need to change. Rather, that is the first thing that I need to change. If recognition from others will drive positive things, it will probably be a sort of a feedback loop. I don’t think any good change can come entirely from the outside.

3. How would your life change for the worse if your leadership skills increased?

“Will these changes be worth the rewards? How can you change, yet behave in such a way that these changes do not affect you so adversely?”

I tend to fluctuate between bouts of really low self-esteem and feeling like I’m the most important person in the world. Now, if the change improves my self-esteem, I’ll probably have a hard time keeping my ego in check. I’m hoping I can avoid the worst by keeping a keen eye on the mirror.

4. Make a list of situations in which your presence seems to increase the productivity of others.

“Alongside this list, identify situations in which your presence seems to decrease the productivity. How can you characterize the differences between these situations? (Fore example, increases in productivity might involve working with people you know well, or working on a problem that is new and different. Or perhaps just the reverse is true for you.) What do these lists tell you about yourself and the environments that empower you?”


  • When I’m the most experienced programmer on the team
  • When I’m allowed to work as a free agent, researching the issues that are giving others grief.


  • When I’m the other party to a personality conflict. Arguing with someone instead of arguing for a case is very tiring. It drains me, and I’m sure it drains others as well.
  • When I manage to sidetrack another person, or even the whole team.

I tend to carve myself a niche where I get the warm glow of appreciation from people. Typically I stay well within my comfort zone, which is sort of a bummer, growth-wise.

5. Based on the two lists from the previous question, are you statistically an asset to groups, or a liability?

“Do you seek out situations in which your leadership will be positive, or do you more often look for situations in which you can learn to do better? Do you, in fact, learn from these situations, or do you just keep repeating yourself?”

I think I’m a net benefit, but then if I didn’t, I wouldn’t be writing this, I guess.

A lot of the time it seems like projects start out promising really interesting learning opportunities, but end up being a bunch of boring grinding. Whether that’s due to unrealistic expectations, or learning the lessons quickly, or merely me being fickle is really hard to say – the jury is still out on that. Still, I feel like I’ve learned something on every project I’ve been on.


Next up: Chapter 2: Models of Leadership Style.

Becoming a Technical Leader

(… in several really really difficult steps.)

A day before Christmas Eve the postman was kind enough to bring me a copy of The Deadline and Becoming a Technical Leader: An Organic Problem-Solving Approach. I read them both in two days. Such a quick read does neither of them justice, but it’s particularly not suited for Becoming a Technical Leader, which is more of a “getting to know yourself” work book than it is a how-to-manual.

The book is divided into five parts, each dividing a particular theme into chapters. At the end of each chapter is a list of questions for the reader. The book suggests that the reader keep a journal of things learned (an idea neatly mirrored by the protagonist in The Deadline). Among the things to document in this journal would be written answers to each question.

I thought I’d give the book another read, and this time, pause after each chapter to write down my answers to each of the questions, and perhaps learn something in the process. I’m going to post each chapter’s questions and answers as an individual post, and link them all back here when I’m done.




Network problems

A few weeks ago I tried installing Visual Studio 2010. The installer failed a couple of times, but after the successful install, I quickly had to remove it because of an issue that came up: every program that tried to access the network simply hung instead of running.

Uninstalling VS helped, so I figured the beta was buggy and forgot about it. Until yesterday, when installing VMWare Workstation 7 caused the exact same issue. Obviously the culprit had to be something else, then.

I had installed a NetLimiter 3 trial  a while back, and let it expire since I decided I didn’t need it after all. Having a hunch that it might be the root cause, I tried to uninstall it. However, the state of my OS was such that even the uninstall failed.

Fortunately, a reboot later, I was able to first uninstall VMWare, then reboot again and finally remove NetLimiter. And wouldn’t you know it, after reinstalling VMWare, everything still works. So apparently VMWare did something with the network that NetLimiter really didn’t like.

This also means I wrongly blamed VS 2010 Beta 2 for the issue, so it might be appropriate to give it another shot. I’m really looking forward to trying ReSharper 5, particularly Structured Patterns and Call Tracking.

Good times.

Plenty of Fail

I’ve kept quiet recently mostly due to a single reason: I’ve encountered a person at work with whom I find working particularly difficult. I’m uncertain as to how I should phrase the situation. Objectively, his style of interaction and mine don’t match, and Unfortunately, the topic of the day is a different kind of fail.neither one of us is willing to adapt to the other.

Subjectively, he drives me fucking nuts.

I don’t want to cast blame, but I’m inevitably going to, anyway. He comes to ask me a question, interrupts me mid-answer, visibly ignores me when I’m trying to emphasize a point that I feel is essential in understanding what I’m trying to say, zones off, and acts in a seemingly arrogant way. He doesn’t respect me as a developer, regardless of the countless times he’s dropped a problem in my lap and I’ve solved it for him. And rest assured, every time he does something that I find genuinely good, I commend him for it. And if I find that I was wrong and he was right, I admit it. Right away, even.

Now, my style of discussing things may be a bit extreme to some people. I raise my voice when I get frustrated, particularly if I have to explain the same thing FOR THE SIXTH GODDAMN TIME AND YOU’RE IGNORING THE ANSWER AGAIN, AREN’T YOU, AAAARGH STAB STAB STAB.

Easy now. Deep breaths.

As I was saying, my style may not suit everybody, and for a while I was willing to accept that the fault might be entirely in me. Intellectual honesty demands me to admit that I might be the cause.

However, having discreetly approached the issue with fellow workers, five people out of five found him exceptionally difficult to work with. So although I’m certainly responsible for my part, maybe, just maybe I’m not entirely wrong in pointing a finger in his direction.

A bit of Great Success, too.

This friction (which hadn’t quite escalated this far at the time) was one of the primary reasons I agreed to a job interview at Sininen Meteoriitti, back in August.

I’ve only been to a couple of interviews during what passes as my career. But there was one distinct difference between this one and the ones I had been to earlier. I decided to bring my personal quirks on the table from the get-go, and I kept an eye on how they reacted to me. In essence, I did what I should have done every time, and interviewed them right back.

In September, I got a call from Meteoriitti. The caller told me they couldn’t hire me yet, but would it be OK if they kept my contact details anyway? Of course, I said, and pushed the idea to the back of my head, feeling a bit disappointed, since in my book “later” means “next decade, if ever.”

Apparently not so for Meteoriitti. Just over a month later I got another call, this time saying it’s a definite “Go” if I’d still be interested. Hell yes I was!

So yeah, I’m switching jobs again, after only a year and a half. But I’d like to emphasize, that while I took the interview mainly because of things I was dissatisfied with at my current job (and felt I was unable to change at the time), I’m taking the job because I really feel that things clicked here.

Let’s see how I can rock the boat there. :)

Security warning redux

Back in January I wrote about the security dialog for downloaded content in Windows Vista. Today, Jouni Heikniemi explains the mechanism behind the warning. In my post I pondered thusly:

Obviously the information about the original location of the file is stored somewhere, otherwise the button couldn’t have appeared when I moved it there.

Well, perhaps it isn’t that obvious. Jouni gives an example of the metadata stored within:


So the metadata identifies the originating zone. I’m left wondering why I wasn’t able to grant full trust without moving the file back to the original location. Perhaps there is more than one stream?