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.

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.

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.

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.

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 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.

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.

• 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.

]]> http://www.toomik.net/helen/blog/2008/04/17/flexible_working/feed/ 2 http://www.toomik.net/helen/blog/2008/04/14/i_have_a_job/ http://www.toomik.net/helen/blog/2008/04/14/i_have_a_job/#comments Mon, 14 Apr 2008 20:34:08 +0000 Helen http://www.toomik.net/helen/blog/?p=627 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.

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!

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

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 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.

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.

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?”.

It was either a long-term wise decision, or just plain foolish… and I won’t really know which it was until several years from now.

I accepted a job with the Technology department of the company I’m currently with. I’m going in as a lateral hire, but will nevertheless join their graduate training programme, together with new graduates. That’s eight weeks of full-time training this summer and frequent continuing training throughout the first year.

And I’ve turned down a perfectly good job from another firm, which also offered lots of training, and exciting products, and the people seemed nice as well. Plus the pay would have been about 50% higher.

The other job was one I would immediately be quite good at, because to a large extent it uses technologies I already know, and advancement from there. The one I chose doesn’t expect me to be particularly productive at all during the first year or so, but spend the time learning instead – and it will certainly be needed, because all the technologies used here will be new to me (Java above all).

In the end, I think both jobs would have turned out well and be broadly comparable. Apart from the fact that one offered 50% more money, but the other is with a firm that I know and trust, with people I know and like.

So I guess this is how much I value my relationship with the firm.

So their approach to recruiting was more professional and thorough than the others’, which is a good sign. But I don’t know if I would want that job, now that I’ve heard more about it – and more importantly, heard more about how they work, and how the place works. In particular I doubt I would learn very much there apart from nitty-gritty details about Excel. First of all the team is ring-fenced from the rest of the technology department and only works for one group of traders, so there are few contacts with other teams, i.e. no chance to learn from others, and few (if any) opportunities to move forward to new areas. Secondly they are, according to their own descriptions, so busy that they don’t have much time to show the ropes to any new hires, and rarely have time to discuss their projects with each other, much less have any training. Any learning is to be done in your spare time. Which to me indicates that training and learning is not a priority for them. And it is the top priority for me. They also mentioned that they spend 90% of their time improving and extending existing spreadsheets, which again means that it’s all about tinkering with details rather than broadening your horizons or learning to think about bigger projects and processes. On the whole it appears like a narrow role with no real room for growth.

Far more promising was a discussion I had today with my current company. I met the head of our department’s technology team, who also happens to be in charge of career development for the Technology division in Europe. Our team has worked quite a lot with him on various projects, so my manager had mentioned to him that I was considering a career change. After hearing my story, his firm opinion was that instead of trying to slowly shift from the business side towards technology, the best way forward would be to join the Tech division’s graduate programme, effectively starting from the very beginning, together with people who’ve joined straight from university.

After the initial shock of the idea wore off (“Go back 5 years and start over? Throw away almost 5 years’ worth of advancement?”) I have to agree that the idea might be a good one. It would, almost per definition, be the fastest way to learn things, because that’s what graduate programmes are about. It would also be more efficient than trying to share my time between doing my current job and at the same time trying to work my way into Technology. And it has a lot clearer and broader long-term potential than the two other jobs I’ve seen thus far, which both seemed quite focused on one relatively narrow area both in terms of technology and in terms of the business area it’s applied to.

To be continued.

Part 1 was a multiple-choice test about Excel VBA, C#, derivatives in general, and interest rate derivatives. The VBA questions were easy, things like “Which one of the following is the string concatenation operator in VBA?” and “By default, parameters are passed a) ByRef b) ByVal c) ByUse d) ByDefault”. Anybody who cannot answer these should not engage in further discussions about a VBA job.

The C# questions took more work, but I got most of them right as well – some because it’s so similar to VB.Net, and some because I’ve been reading C# code on various .NET blogs. I’ve occasionally wondered whether I might be wasting my time reading them – I guess the answer is no.

The general derivatives questions were not as basic as the VBA questions, but not particularly hard either. They were all about fundamental concepts and analytics, so even though I haven’t done much with derivatives in the last year and a half, I could dig up those memories and manage them well.

The last part was hard, because I’ve never worked with interest rate derivatives. With common sense and some lucky guessing I got just over half of them right. From his comments it sounded like the wrong ones were at least close and not too badly wrong.

Part 2, the interview itself, was relaxed. I would have been a tougher interviewer myself, definitely. The only hard part was when he started asking more technical questions about .NET, things like garbage collection and COM interop. I sort of know how these things work, but not well enough, and that was probably pretty obvious. But even there I obviously did OK, because he said he wanted me to come back for more interviews. He also asked me what bugs I had discovered in Excel, and at that moment I couldn’t think of a single one…

My own first impressions were somewhat mixed. He was obviously knowledgeable and experienced, but I didn’t sense much enthusiasm at all. Maybe he is just that kind of guy. Or maybe it was because this was late in his working day. But I’m used to working with people who are excited about what they do, and I quite like that. I’ll have to see what the other guys are like.

Now, off to read about memory management and garbage collection in .NET!

I’m looking forward to the interviews – I quite like interviewing. It’s pleasant to talk to someone when both of us are entirely focused on the conversation and there are no disruptions. And the people you meet via interviews are usually intelligent, interesting and likeable.

I’ve been with my current firm for four and a half years now, but I haven’t been entirely without interview practice all this time. I’ve volunteered to interview a number of potential new hires for the firm, and an even larger number of summer intern candidates. Sitting on the other side of the table put things in a different perspective and helped me understand how things work, and what interviewers are really looking for with all their questions.

Besides, I’ve moved around within the firm. Internal movers are examined almost as thoroughly as external hires, so when I moved from one department to another (back in April 2004) I went through about 10 interviews, I believe. Not that that helped, really… After several months I realised that I was not at all the right person for the job, and the job was not at all right for me, so I quit. Sometimes I’m too persuasive for my own good and manage to convince others of my own views even though I’m completely wrong.

I quit in September 2004 and had time to apply (and interview) for one other job before I was offered a temporary and experimental job in another role in my old company, in a neighbouring team. They knew me and I knew them, so there was no interviewing as such, only a brief chat. I took the offer and have been there for the last 16 months now.

I’m also looking forward to hearing more about the jobs. Job listings will never be more than dead pieces of paper (or dead bytes) with formal facts – it’s difficult to get a feel for what the job is really about. How do the listed qualifications and requirements correlate to the real job? What do they actually develop? (These two listings weren’t too bad, but others just mention developing “tactical solutions for the trading desk” – what exactly is that?) How does the team work? What does their development process look like?

It’s becoming difficult to focus my attention on my current job.

My manager has now seen that I am actively looking for a new job, and is not at all happy about the prospect of me leaving, although he understands and accepts that I want to move after 16 months in temp contract limbo. But the team has more to do than we have resources for, and he wouldn’t like 1/5 of the team to disappear, so he is now trying to find out what he could do that would make me stay.

I have been here before… Things went the same way when I last tried to quit, in September 2004: the managers managed to entice me to stay (which is how I ended up on a temp contract). I’m not entirely happy with how this turned out – it feels like I haven’t achieved much at work since then – but not too dissatisfied either.

This time around I have a much clearer idea of what I want and what I don’t want. I’m also in less of a hurry to leave, which will hopefully lead to a more durable solution. Last time I just felt an urgent need to get out of where I was. This time it’s a longer-term desire to start moving in a good direction.

I’m also more relaxed about the idea of quitting my job. The second time is much easier. I’ve been on a temp contract with zero days’ notice for such a long time that I’ve gotten used to not having any job security, apart from being indispensable to the team. I’ve had to think from day one that this is not forever, and thought about what I could or would do when this finishes.

All this means that I’m in an excellent position to negotiate for a job. Over the next few days I’ll write down what I would want from my next job, and think about if and how this might be achieved within my current team (or perhaps by being loosely associated with the team).