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.

I received a comment on one of my older posts about interviewing for an Excel VBA job, asking about possible interview questions. I’ve been on both sides of the interview table, and I enjoy interviewing, and I’ve thought about this quite a lot. So I thought I’d write a more thorough reply, and make it a full post instead of hiding it in a comment. Maybe others can find this useful, too.

If I was conducting an interviewing for an Excel VBA, I would probe you from the following directions.

One: your general attitude towards and approach to programming. I’d ask you to write code to solve some simple generic problem that shouldn’t take you much more than 15 minutes. It could be sorting an array, or printing a checkerboard pattern of 0s and 1s, etc. I’d check that you have meaningful variable names, that you declare your variables (which in VBA you don’t necessarily need to do), that your code is reasonably well-organised etc.

Two: your knowledge of Excel. I’d want to see that you can use array formulas and pivot tables, lookup functions, named ranges, etc. You can’t be a good Excel VBA developer if you’re not a good Excel developer. I would give you a laptop and a few actual problems to solve, and leave you to it.

Three: your knowledge of the Excel object model. I’d ask you to write code that manipulates a worksheet – for example, sort and filter a range, or clean out duplicate data from a list, or consolidate data from multiple files. I’d look for knowledge of and ability to work with fundamental Excel objects such as Workbook, Worksheet, Range etc; also I’d definitely want to see that you don’t write “macro recorder”-style code with Select and Activate everywhere.

Four: your knowledge of how Excel VBA works. I’d check what you know about events (“Can you write code that runs every time the worksheet changes?”), about user-defined functions (“What is and isn’t allowed in UDFs?”), volatile functions (“How can you ensure that your UDF is volatile?”, “Which built-in Excel functions are volatile?”).

Five: questions specific to whatever the job is about. If it’s at a bank, I’d want to see you do some basic financial calculations. If it’s a database reporting job, see if you can work with ADO and basic SQL, or interop with Word, or creating charts in VBA, or whatever else is relevant.

This is quite a lot and might not all get covered in the first interview, but I would ideally want to go through all of this before deciding whether to hire you.

Personally I’d prioritise the parts just as I’ve listed them here, most important first. But I’ve been to interviews where they do almost the opposite – I once got a 10-question multiple-choice test about some nitty-gritty stuff in Excel but they didn’t care about what my code looked like. So you never know.

The reason I’ve put “knowledge of Excel” above “knowledge of Excel VBA” is that in my opinion, the latter is more straightforward and easier to learn. It’s just code, and it is reasonably well documented. It’s harder to find people who are good at writing efficient Excel formulas. But often formulas can yield a far more efficient solution – faster by several orders of magnitude. If I have a choice between formula and code, I’d almost always choose the formula.

John, I hope you find this helpful, and good luck with your interview!

It’s been a while since I said anything about work. It’s not for lack of activity, or of interest – work is as busy as ever, and I am really enjoying it. I guess there just haven’t been any individual events that stand out or prompt a post.

It really is the best job I’ve ever had. Not that the previous ones were bad… With one exception, I’ve felt the same about all my previous jobs at this company: each one was better than the previous one, either more interesting, or more suited to my skills. (The exception was the job that made me leave the firm after 4 months.)

So what is so good about it? The best thing is that I work with other developers. While I spent at least 50% of my time writing code in my last job, I was the only member of the team whose main focus was code. And I was by far the most experienced “developer” in that team – even though I had no comp sci background, I had been coding for several years, whereas the others had done little or none. Also, I was the only one really interested in software development. This meant that I had no one to discuss my projects with. No one to ask, How should I design this? Does this look like a good solution? How could I improve my code? Now, on the other hand, I sit right next to people who are interested in software development, know a lot about it, and are willing to discuss it. Design decisions, small and large, are discussed before, during and after coding. As a result, I am learning more, doing a better job, and enjoying the process a lot more.

Working in a team imposes its restrictions on me, and most of the time, that is a good thing. Too much freedom can easily become lack of direction – a certain amount of discipline and control actually make life easier. When I was the only developer – either in my previous job, or in my hobby projects – I could more or less do anything. Now I need technical specifications and documentation and class diagrams, and maybe time estimates and prototypes. I need to make design decisions upfront and can no longer change my mind whenever I feel like it, because other people’s work depends on what I do, and what I have said I will do, and what I have said I will need from them. I’ve sometimes found this hard and unnatural: my preference is generally leave my choices open, to start working and let the details emerge as needed. But on the whole I think this has led to better-quality work.

The other great advantage of working in a technical department is the sheer breadth of experience to be gained. I used to work with Excel VBA at work, and VB6 ⁄ VB.NET at home. Then SAS was added to my toolbox at work, and that was a major decision for the group and a major change for me. Now I’m regularly reading and/or writing bits and pieces of Java, C#, VB.Net, and SQL, interleaved with command scripts, VBA, XML schemas, and proprietary languages, plus support tools like source control systems, class diagrams, change management systems etc. While I can’t call myself an expert in any of these, even just having exposure to such a broad array of technologies is both fun and educational.

I’ve been in this job for four months now, but it feels a lot longer than that, because of how much I’ve learned. I am looking back at projects I did a year or two ago and can’t help thinking that I could do them so much better now.

Now that I’ve moved to a new team, the old team needs someone to replace me. I spent most of this morning interviewing candidates for the job.

The main requirements are reasonable knowledge of finance and financial markets, and good knowledge of Excel VBA and SAS. We’re prepared to (and will probably have to) relax this somewhat and just pick the person who’s closest. I had hoped to find someone better than myself, but it looks like the combination of skills we’re after is a rare one.

The applicants (four of them) have been a mixed lot. Interestingly, three out of the four where Australians. Looks like this is the thing for young Aussies to do: get an education, then travel a while, then spend a couple of years in London. (Our newly-hired team assistant is also Australian.)

Most interestingly, several of the CVs were factually correct but in reality misleading. Two out of four listed both SAS and Excel VBA prominently on their CVs, but when questioned about their experience admitted that they haven’t used them for years, and when asked to demonstrate their skills, they could barely manage the basics, if that. A third one hadn’t done any SAS work but Excel VBA was among the first-listed of his technical skills, and he supposedly had a programming background including C++, yet he struggled hard with questions that required him to write pseudocode for a simple problem.

I think it is almost impossible to evaluate someone’s coding skills without letting them actually write code. Almost anyone can make their past projects sound important, and present themselves as being central to the projects’ success. But when I ask them to actually do something, I can see what they’re really able to do.

Sample Excel problem: return the name associated with the highest value in a list. One candidate’s solution: hard-coded link to the cell with relevant name. Hopeless.
Sample coding problem: create a checkerboard pattern, with alternating black and white cells (or alternating 0s and 1s). Those who knew (or claimed to know) VBA got to write VBA code, others could write pseudocode or use any other language they liked. Only two got anywhere near a working solution.

(That last one I actually “stole” from one of my own interviews, when I was looking around for a developer job a month ago. I think it’s an excellent question because all it really requires is logical thinking, and you could write many variations on the basic theme.)

And what can one say about a candidate who, when interviewed about his financial knowledge, says that his real background is in programming so that’s his strong side, and when interviewed about his programming knowledge, points out that his recent jobs have all been finance-oriented, so that’s what he’s better at.

On the positive side, one of the candidates actually had a honest CV that reflected his skills, and was able to demonstrate those skills in practice. He doesn’t know any SAS, but if we could learn it then surely so can he. And he appeared to have a solid foundation – good coding habits, clean code, sensibly commented. (He actually brought printouts of his code to the interview, which definitely worked in his favour.) I’d rather hire someone with good habits and let them learn the language, than someone who knows the language but produces messy code. Unless we suddenly get a last-minute application, looks like he’s got the job.

First day of the new job. First impressions.

The team seems great. Relaxed, knowledgeable and helpful.

The hours are much more sensible than in the previous team. No one was there before 8:30, and by 18:00 most people were leaving. Which is a nice change compared to the 7:30 to 19:00 I’m used to.

The move itself was a shambles… My things, which were supposed to be moved yesterday, weren’t, so I spent the first half of the day with nothing but a desk and a computer. Then the admin team messed up and terminated my account, so I spent the second half of the day with all my stuff but no computer. And no access to any doors – the access pass was also terminated – which was a bit of a bother given that the loos (among other important things) are outside the locked doors. It was like in primary school when you needed to raise your hand and ask the teacher, “May I be excused?”.