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.

As of today, I am an employee of Konsultbolag1 (“the consulting company”) which, despite the name, is not an IT consultancy. Instead they provide training, consulting services and software tools for requirements management and testing of IT systems. The software tools part is the one I’ll be working with.

Before we got to Sweden, I was fully prepared for several months of job hunting. There might be no relevant openings, or I might not like them, or they might not like me. In the end it took no more than two weeks. We appear to have arrived right at the top of the business cycle for the IT industry: every firm is clamoring for more staff, and employees can afford to pick and choose.

Monday two weeks ago I searched through Monster and picked out 8 ads that seemed relevant and/or interesting. I also sent my CV to the IT departments of a few large banks. On Tuesday, the day after, I got replies to a few of my letters, and more followed the day after. 10 days later I had already met 5 companies, some of them more than once.

My initial plan was to aim for the finance/IT intersection: banks, other financial institutions, firms writing financial software, perhaps even IT consultancies focusing on the finance industry. And yet I chose the one firm I met that has no links to the financial industry. They seemed like more fun than any of the others, frankly. I also feel that I don’t necessarily want to narrow my career to “IT within finance”. I would rather broaden my experience than focus it. For that same reason I am also not continuing with Winforms or Office integration, but sailing off into unknown waters: web development (with ASP.NET).

So I will be developing software that will help other people develop even more software. That feels strange in a way: kind of circular. But at the same time I am keenly aware of the importance of good dev tools (as my previous colleagues can attest!) and good tools give me warm fuzzy feelings. The world needs more good tools, there can never be enough.

After almost seven years with the same employer, today I’m saying good-bye. I’ve been with the firm through recessions, market crises (remember Enron?) and legal upheaval. I’ve quit and come back; been a permanent employee, then contractor, and then an employee again. I’ve been in 3 divisions and 6 different teams. This was my first employer after graduation, and the reason we moved to London. And very soon this long relationship is going to become history.

I’ve already emptied my desk and my drawers, packed my books, and found a new home for my plants. I’ve almost gotten used to saying “here’s how you could fix this bug” instead of saying “here’s how we could fix this bug”. In a few hours we’ll go for farewell drinks, and then I’ll cycle home with a rucksack full of books, and that’s it. It’s almost enough to make me teary-eyed!

It will feel very strange to get up on Tuesday and not have a job to go to.

Meanwhile, this is the first time I blog during office hours!

I have finally made some active effort to find a job in Stockholm. Started today by updating my CV. Then I tried to translate it into Swedish and realised that I am unable to talk about any of my jobs (either the finance-oriented or the technology-oriented) in Swedish. I just don’t have the vocabulary. I don’t even know how to translate “desktop applications” or “automated data feeds” or “structured commodity derivatives”!

It could be worse… I could be looking for a job in Estonia.