At work: more software installations. Visual Studio, Resharper, SQL Server Management Studio, TortoiseSVN, AnkhSVN, CCTray, Notepad++, Office, Filezilla, and probably some that I’ve forgotten already.

During the afternoon I replanted the three tomato plants I bought 10 days ago, and cleaned out all the paper junk that’s accumulated in Ingrid’s room. Almost every day she brings paper home from nursery, sometimes with drawings, sometimes with scribbles, sometimes just folded up and wrapped up with sticky tape. Of course she wants to save them all, but then a few days later she forgets all about them. I plan to go through all her toys someday soon, too.

Adrian is still semi-ill, and eating and sleeping badly. I think I got about four hours of sleep this past night, in three separate pieces. But tonight he fell asleep on his own: we nursed, I turned him on his tummy, he twisted and tossed for a while, and then he was asleep.

Eric took him to his 8-month checkup and it was uneventful. He can sit unsupported, he is not cross-eyed, his babbling includes non-vowel sounds: check, check, check. 9.4 kg and 69.7 cm.

We had a lovely storm during dinner, with lightning and thunder and hail and pouring rain. Falling cherry petals filling the air made the storm look even more fierce.

My first day back at work. It wasn’t a good day for going back to work: Adrian’s teething cough transformed into a plain and simple cold during the weekend and he was feverish and unwell all day yesterday. Neither of us got much sleep during the night. And he was totally not interested in food and just wanted to nurse, so I left Eric and him with a bottle and a heavy heart – and hurried back as soon as I’d finished my half-day of work.

In the end they managed pretty well of course, and Adrian had accepted the bottle, but he was happy to nurse when I got home.

At work I spent most of the day getting my new computer up and running and installing Windows. Installing stuff is, I think, my least favourite task at work. I’d rather scrub the kitchen than battle with network card drivers or look for the right download files on MSDN. A gazillion flavours of Windows 7, all of them with long names that look almost identical at a glance, so finding the right one is a real chore.

By the time I left the office my lower back hurt. Even though I only worked a half-day, and I do not sit still when sitting in front of a computer. I am just not used to this much sitting any more.

I had also forgotten that it is a good idea to bring something to read on the train.

I’m in Gothenburg for two days for ScanDevConf 2010. With a long train ride yesterday, and an evening in a hotel room today, you’d think I’d finally have time to blog… but no. I spent my hours on the train reading China Miéville’s The City and the City, and this evening at a bar/pub almost-watching football (yes, football) with some fellow developers I met at the conference.

I was also expecting to blog about the conference during the day. But access to power outlets was less than generous, so I couldn’t type my notes during the sessions themselves, meaning I’ll have to process them before they’re in a bloggable state. A real blog post will be coming soon.

We’ve started work on a new help system at work. The old one uses a CMS from 2001 and we all loathe it. “Updating the help files” is the least popular task of each release. We’ve had enough; we’re starting afresh with Drupal.

So I’ve spent today setting up a Linux VPS, configuring the web server, installing Drupal and all sorts of plugin modules for it. And it’s a painful experience. Every step I take is based on something Google tells me. I have no feeling for what I’m doing, no intuition as to whether it’s dangerous or not. So with every other step, I’m wondering – if I get this wrong, how much of the system will blow up?. How wrong am I allowed to get my changes in httpd.conf before the web server will stop responding at all?

It gives me an all new perspective on what it must feel like to be an inexperienced computer user. Afraid to click on anything, afraid to change a setting, just in case they make the computer blow up.

Another perspective on this is if it hurts do it more often. It was not meant quite in this sense originally but it still makes sense. Unfortunately it’s very rare that I have a meaningful need to tinker with Linux sysadmin tasks or web server settings.

Since we lost a third of our developer team a few months ago, we’re looking to hire a new one. We’ve interviewed half a dozen candidates of quite varying quality, and discarded many more CVs. After most interviews we’ve felt guardedly hopeful – “this might work” – and gone on to the next step (a take-home exam, a programming task that the candidate solves at home and sends to us for review). After today’s interview I felt pity instead.

The candidate had worked as a developer since 1995: first 4 years in one place and then 10 years in the next. But she didn’t have 14 years of experience – she had 1 year of experience, 14 times over. She failed technical questions that a competent developer who’d worked with these technologies for more than a few years should be able to answer without hesitation. (Example: in ASP.NET, name some ways of storing state – ViewState, Session, Application etc – and name the differences between them.) Her career had totally stagnated.

And the reason was obvious: she was passive, waiting to be served the necessary experience and learning. She wasn’t stupid, she just lacked drive. Had she read any interesting books about software development recently? No. Blogs? No. Did she have any hobby projects aside from her main work? No. Then I asked her point blank, how do you keep your skills up to date? And she said, I expect that to happen at work, through the work I do.

I’m sorry, but it doesn’t work like that.

The sad part was that even though she had more or less seen the problem, and wanted to move on, she was not at all aware of the cause of the problem. She’s going to have a very hard time finding a satisfying job. A recruiting manager might accept the weak skill set, but who’s going to hire a candidate who tells you quite honestly that she takes no initiative to learn? And when she finds a job, it will be in a team with low expectations, and thus more stagnation for her. In another ten years, she’ll be stuck in some dead-end job, maintaining boring obsolescent non-essential applications. And she will be bitter and frustrated.

What a waste. She was a nice person and I really don’t want that to happen to her. I felt tempted to write to her, after she gets the rejection email from my boss, and tell her all this. Wake up! Take charge! Ask questions! But I’m afraid it would be perceived as insulting, and would be unlikely to have the desired effect.

I held a presentation again today, jointly with a colleague, at a conference organized by Konsultbolag1. (Ours is the last talk on the programme. I know my name isn’t there; the initial plan was that someone else would do this but I stepped in instead.) We spoke for 40 minutes, in front of ~60 people. I’m starting to think that I should do more of this: I enjoyed it even more than I anticipated, and got better feedback than expected.

Observations:

• I need to feel comfortable with the content and the presentation materials, but once I have that, and a rough idea of what I want to say about each point, further preparation is not useful to me. Some people rehearse and memorize individual phrases they intend to use. I sometimes try that, thinking of good ways of expressing things, but when I’m standing there on the stage that all disappears, flies right out of my brain, and I end up improvising anyway.
• Surprisingly many people deliver presentations without thinking through what they want to achieve. What is the purpose? What should the audience know or think or want or do after hearing your presentation? How does each page work towards that aim?
• You don’t need to be a leading-edge expert in order to deliver a useful talk. You just need to know more than your audience, and know your limitations.

Our head of development (let’s call him T), who was also 33% of the development team, left us in March, which makes me the new head of development. It’s not something I was aiming for at all (I’ve always been more drawn towards the technical specialist career track rather than management) but since there was no one else available, I’m now the manager of our two-person team.

In a way it’s nice to be manager, as it does give me greater say in how we develop (and to some extent what we develop). There will be even greater focus on design and architecture, on code quality and automated testing, and on paying down our technical debt.

The handover was very undramatic. I just slipped into the vacated shoes. We had three weeks of handover time, during which I was getting used to thinking and acting as head of development, and T worked part-time as an ordinary developer. Very smooth.

Last week was our first week without T, and it was as if the place was jinxed. All kinds of things kept going wrong, and today was no better.

Monday started with login problems at our intranet site. I inherited the responsibility of supporting the intranet from T. The site is based on Drupal + phpBB, and we use an LDAP integration module for user authentication. The LDAP module needs the credentials of one user in order to log in and get the details for all other users. We’d used T’s credentials in the past but now that he wasn’t an employee any longer, his login didn’t work. Easy-peasy, we’ll switch his credentials for mine and off we go. Except that when we did that, everything stopped working. We spent several hours on it on Monday and got nowhere. It didn’t help that we had only basic knowledge of PHP, knew nothing about Drupal development, and even less about LDAP. By noon we’d gotten rid of one detailed error message, only to see it replaced with the not-so-useful “invalid credentials”. It was release week, which meant that the intranet was not high priority. But of course it couldn’t stay down for too long, so on Thursday I spent another half-day digging. It turned out that another Drupal module was interfering with the LDAP module, by transparently inserting <p> tags around the settings we had entered. What a stupid error to lose time for!

On Friday, a few minutes past midnight, our production site went down for 15 minutes, for no known reason. The web host has so far ignored our requests for log files.

Our monthly release was due on Friday afternoon. Ingrid woke up with a fever and I had to stay at home, and Eric couldn’t get home before 5. T came in for part of the release process, and I had to phone in when Eric got home, to support my junior colleague during the remaining testing tasks. Luckily everything went well, even though it was a semi-complicated release. Less fortunately our testing showed that the release included several avoidable bugs, but nothing too severe.

Saturday morning I got a call telling me that it was impossible to log in to our site, even though the site was available, and had worked perfectly well on Friday. Luckily it was easy to diagnose with the help of Google, and almost as easy to fix. It turned out that we’d missed a quirk about web.config files, which for some still uknown reason hadn’t caused any problems in our test environment. Every time the ASP.NET worker process was restarted (i.e. every morning, because of the overnight idle period) the application effectively got corrupted. My first task on both Sunday and Monday morning, before any user had time to log on, was to restart the application in just the right way to avoid that corruption, and when I got in the office today we put in a proper fix.

Then, yesterday evening, our office network collapsed because of the server (or firewall, or some other piece of hardware in that stack) overheating. Turns out there is no AC in the server room, and the server cabinet is of the wrong type, and someone (probably the cleaners) had closed the door during the weekend. Network access was restored quickly, but we still spent half the day without access to incoming email. This was one problem I didn’t have to fix, or even feel any responsibility for, but it meant we were flying blind as far as production support goes – much of our monitoring is, unfortunately, based on email notifications. This was doubly unfortunate since today was the first weekday after release, and it’s not uncommon for a few bugs to arise. Luckily we had no urgent issues today.

It’s all been a flood of unfortunate events, which were all resolved in the end before causing any major issues. But it was a precarious balance, and now I feel all exhausted after a week of firefighting. Stress doesn’t arise from having lots of work, but from feeling of having no control over the situation.

I found a blog post about pair programming. The post itself wasn’t anything special (talking about how the names Pair Programming and especially Extreme Programming might scare away conservative managers). But I found the comments interesting, and I could really sympathise with several of the commenters who do not like pair programming.

I have tried pair programming a few times. It works (from my point of view) when both of us are roughly on the same level, and only when there is a problem that clearly needs more than one pair of eyes, because it’s risky or complicated. It’s worked well for some tricky SQL queries, as well as for a complex web page (a mixture of UpdatePanels, Repeaters, and javascript with embedded C# code blocks).

If the other developer is clearly more junior than me, pair programming kind of works as a method for knowledge sharing. I could get the job done noticeably faster on my own, but then we’d need additional time for handing over or explaining what was done, so the two might as well get done together. In those cases pair programming should be considered as a teaching/learning method rather than as a programming method.

But I do not like to do it for general run-of-the-mill coding – there has to be a specific reason for it.

Saying you should pair program “just because” is an inflexible approach, sort of like saying “hammer works for nearly any purpose”.

I do not need another person to help me focus (which is one of the advantages often mentioned). On the contrary, if someone is looking over my shoulder while I code, it really distracts me. Whereas if I am looking over someone else’s shoulder, I get incredibly frustrated by how inefficiently they work – because almost always they will be inefficient compared to my standards. They don’t know their tools, they don’t use keyboard shortcuts, they type slowly and carelessly. And I sit there and wait and sigh quietly.

I imagine I would enjoy pairing with an experienced and efficient programmer, but there aren’t any where I work – there’s no one more experienced than me. This is actually the greatest drawback of this job. I have no one to learn from; I can only learn by doing and by reading, and that’s only going to take me that far. I am a big fish in a small pond, whereas I would much rather be a tadpole in a big pond.

I’ve been at my new job almost two months now, and by now I feel like I’ve been doing it for a long time. I think much of that is due to how small and informal the team is, and how tightly involved I am. I am half the development team. My previous job (at a big bank) was framed and structured by all sorts of procedures, automated processes, approvals, systems, and schedules. Here I just sit down and do whatever I decide needs to be done.

On the one hand this leads to a lot of freedom and independence and responsibility. Our speed of response is stunning: if an urgent bug is found, the fix can be in production minutes after we’ve tested the fix.

But there are downsides, too. There can be confusion and lack of direction, because there was (until recently) no clear process in place for prioritising requirements or for scheduling and planning releases. There is tedious manual work which is easy to get wrong, because the deployment process is not automated. And so on.

The good thing is that it’s all changing. The other half of the development team is almost as new to the firm as I am (although he has worked there a few summers, he only started full-time a couple of months before me). Since we’re both new, we have no emotional investment in the current processes and systems. And we’re planning to change just about everything.

A new source control system is coming soon (SVN instead of VSS). A new development process is already being tried out (Scrum-inspired). Development tools to improve code quality (Resharper) have been introduced. Automated unit tests are slowly being put in place, and automated acceptance tests are being discussed. Automated build and deployment will be coming next.

My last job was, in a way, the perfect preparation for this. Had I come straight from school, or from another unstructured chaos-inspired place, I might not even know that things could be done differently, and we would have muddled on, just like the developers before us seem to have done. The gears would grind slower and slower, but we would probably be able to keep moving for several more years.

But I have seen the other end of the scale, and I know – not theoretically but from my own experience – the benefits of an automated build process, deployment scripts, code reviews etc. I know how much easier life could be. I know what we should be aiming for, and even though the ideal setup here will be very different from what we had there, I know how to figure out the way to get there.

If any of my previous colleagues are reading this, I’d like to send them a big thank-you for preparing me for this! You all thought I was working for the bank, and in reality you were all working on training me.

Setting up a flexible working arrangement at previous Big American Employer:

• Discuss needs with manager and team leader.
• Submit a Flexible Working Agreement proposal via special web form, specifying working hours and place for every day, providing a business justification, listing potential difficulties and how they will be resolved.
• Wait for proposal to be approved by manager and HR.
• Receive written confirmation of FWA.
• Follow FWA.

To be honest, calling that procedure “flexible working” was misleading, because after the agreement had been negotiated, there wasn’t much flexibility in it. If the FWA stipulated working 80%, with Mondays off and Fridays worked from home, then the employee was expected to follow that. “Nonstandard working agreement” would be a more correct name. Still, it worked well in practice and I was quite happy with the arrangement.

Setting up a flexible working arrangement at current Small Swedish Employer required exactly two five-minute conversations.

HT – Can I work part-time?
CEO – Yes, you can.
HT – Do you prefer a full week but shorter days, or a shorter week?
CEO – Whichever… talk to your team leader.

HT – I’d like to work part-time. Do you prefer a full week but shorter days, or a shorter week?
TL – Whichever you like.
HT – OK, I’ll try a shorter week, then. Which day off would work best?
TL – Whichever you like.
HT – Umm… Wednesday?
TL – Sure. If you want to change it later, let me know.