Occasionally updated personal site and blog

Some lessons from 10 years in the business of IT consulting

These points are unsorted, random and subjective. Quite a few are negative – not because I want to focus on the negative, but because we learn from our mistakes (or the mistakes of others). 

If your sales are slow, it might be that you are bad at sales, or there is a downturn in the industry. Though most likely nobody needs what you are offering.

The more pushback you get on price, the more it is a sign that you are in the wrong business. A great business is one where conversations go like this:

Client: “How much will it cost?”

Us: “Here’s a number that’s pretty high, because you’ll probably want to negotiate a rebate—”

Client: “Cool, when do we start?”

If they ask you to fill out hundreds of questions, submit a detailed calculation, and submit solutions before starting, they either don’t know what they are doing, or do not really value it. Either way, you don’t want their business, and you wont get it. 

Firing someone can be great for morale. If it is someone where everybody they have worked with is annoyed with their incompetence. 

Any truly major decision or change takes about 3 years to have its full effect. Your most important partner got bought, and is now a completely different company? Projects are managed badly, and the employees need to compensate with unpaid overtime? Management targets are set unreachably high, and bonuses never paid out? A new line of business, with a brand-new team? A new CEO? Anything that happens in the first year after that change is not yet a good indicator of how that will work out. 

Profits are a lagging indicator. Nothing ruins a company as surely as incentivising management only on this year’s profit. It is easy to increase profits, all you have to do is cut investments. 

You need a healthy ratio between junior and senior people. Too many seniors, and junior people never get to stretch their wings. Not enough seniors means there is nobody to teach the juniors. 

If you tightly control your people so they only spend time on things that have a measurable impact on the bottom line, you avoid a lot of waste and slacking off. You also get rid of serendipity, research, improvements to internal tooling, cross-pollination between departments, experiments and all the other things smart, driven people will do when nobody is watching.

If you invest in a new line of business when it’s uncertain, it might not pan out, and be a waste of money. If you invest in a new line of business only when it has become a sure thing, it will already be crowded with competitors who invested before you. Also: an uncertain partner who needs you will be willing to support you, and remember you for taking a chance on them. An established partner has their pick of companies, and you have to be the one to beg them to take you on. Also: when a market is new, nobody has experience or references, so that’s OK. When a market is established, you face the chicken-and-egg problem of gaining experience when you have none. 

For the really important tasks, you want to send your best and most experienced people. But if you only ever hand big important tasks to the most experienced people, the junior ones will have no chance to become experienced. Sometimes you have to ask people to step into footsteps that are a size too large for them, for them to grow into those. But only one size, not two. And you have to accept that sometimes they will fail. But if you don’t, you will have no experienced people, and be forced to have people step into tasks that are two sizes too large for them. 

When there is a conflict between what an employee wants, and what the company needs, do a cost-benefit analysis. For example, paying for a  training that is not directly relevant to the company may cost 2000 bucks, but that’s a cheap way to buy motivation. 

You know how external rewards can kill intrinsic motivation? That goes the other way round, too. The more you force people to go the extra mile (without extra reward), the less willing they will be to go the extra mile when nobody is watching. 

If you have to fire people during their trial period frequently, you either suck at recruiting, or you suck at onboarding. If you never have to fire people during their trial period, you are too conservative and too picky when hiring – give some uncertain, wildcard candidates a chance. 

There is no such thing as a perfect candidate – some lack experience, some come from a different domain or tech stack, some seem a little weird, some are demanding,… Figure out what flaws you can accept. And judge on whether you see potential for improvement. 

The most loyal employees are the ones to whom you showed loyalty first – the highschool dropout who you took on as first an intern, and then as an apprentice. The trainee who had almost no programming experience, but a burning desire to learn. The star performer who burnt out, and needed months to get back to being productive. Those will stick with you through tough times. 

It is very easy to increase profitability quickly – all you have to do is reduce investments, cut training, and mandate unpaid overtime. A bad manager will commend you for it. A good manager will realize that in the long run this is disastrous. 

When a project is well and truly fucked, and a hopeless disaster, the most important thing to get back on track is to give the impression that you know what the problems are, you have steps to tackle them, and you have a timeline and priorities. It can be an incomplete plan with imperfect solutions and an uncomfortably long timeframe – but knowing how bad it is is much, much better than fearing the worst. 

Fast, cheap, good. Time/Money, Quality or Scope. One of them has to give if the other two don’t work out. If a client has unrealistic expectations and is at the same time insisting on being inflexible on all three dimensions, no amount of project management can make him happy. 

It is much easier to edit a mediocre solution, than to sit in front of a blank slate. The same goes for a client. Never ask “what do you want us to do here?”. Always ask “what result do you want to achieve with this”, and then “I would suggest the following – does that work for you?”

You are judged on results, not effort. Unfortunately that also goes for projects: If you take on an easy project that basically runs by itself, and even a clueless intern could not mess up, and barely make it work, you will be praised for your success. If you take on an impossible doomed project, and by heroic effort almost pull it off, you will be chastised for your failure. A good manager will reward heroes. 

How many people leave is less important than why they leave. If they want to move to another city, or change industry, or tech, or role, fine. If they leave, and in their next job they do the same work with the same tools and for the same clients, just at a different company – they were not attracted somewhere else, you drove them away. If they pull other people with them, it means they really like it a lot better elsewhere. 

Organizational design matters. Somebody whose work is measured in the same P&L sheet will be more helpful to you than the same person if they are not. 

You do not need the highest pay, the fanciest office or the most comfortable job, if you can offer interesting work, great teams, growth and appreciation. How do you convince a candidate to come work for you, after he has told you that he has another offer that pays 20% more? THAT is your employer brand. 

Never save on equipment. Never save on training. 

Nothing makes your boss happier than putting in extra effort without him having to ask for it. Nothing makes employees happier than treating them well without them having to ask for it. 

Do not try to make your team happy. Tell them what you need them to do. Tell them why it matters. Give them what they need to do it. Reward Successes. Happiness follows. 

If you say no to additional work because your plate is full, you make people unhappy now, but they will respect you, and you get to make the decision of what to drop. If you say yes to additional work when your plate is full, you will make people unhappy later when you either drop the ball or half-ass it, they will resent you for being unreliable, and your stress level makes the decision of what to drop for you. 

Experiments that fail are OK. Experiments that fizzle out are a failure. Have a good balance between cash cows and experiments. 

Hiring developers? How to do code reviews in technical interviews

A significant part of our technical interviews is having the candidate do a code review on a piece of example code. I’ve written before about why we do that. Today I’ll share a few tips on how to make it work well.

The code

The code you give the candidate to review needs to be long enough to include enough things to talk about, but short enough to understand quickly, and keep in your head. The code we are currently using is a little under two pages when printed out. We could probably strip some of the boilerplate and go to one page – but anything less than a page is probably not enough.

It should NOT be a complicated problem domain – the review will be about the code, not the specific problem the code solves. But ideally it belongs to an industry your company typically works in. If you get a candidate that has worked in your industry before, you also get to see how familiar they are with topics and problems typical for that industry. If they have not, I of course expect no knowledge about that domain – but a senior candidate should realize where they need to ask for domain knowledge.

Do not use code that implements a complicated algorithm – you don’t want candidates to spend their time trying to understand it. But for most candidates it is easier if what the code does actually makes sense. At first I used something where the business logic was intentionally nonsense in order to make clear that it was not about the logic, but a lot of candidates actually got stuck trying to make sense of it. So now I’ve streamlined the logic to the point where it is still dependent on unknown requirements, but seems consistent.

It works best to pick a class that you wrote for a real project, strip it down to a suitable length, and then intentionally mangle it to include lots of questionable code that should get flagged in the review.

The issues

The most important thing is not to prepare a quiz (“Find the 10 mistakes hidden in the code”), but use the code as an invitation to start a discussion.

Include lots of different things that might draw the candidate’s attention – from commenting to formatting to syntax to logging to exception handling to null safety to naming to nested method calls to method length to duplicate code to performance. This makes it easier for candidates to find something to start the discussion with. And you also get to see not only what they notice, but what KIND of things they notice – a candidate that talks about ways to optimize performance by inlining a method call or using a different list implementation is probably a completely different kind of programmer than someone who focuses on method length and variable names.

Include issues that are suitable for different levels of experience. For people straight out of university, I include a few language constructs that are fairly basic and taught in any university course, but rarely used in real life. For experts in the particular language, I include some obscure syntax constructs that most people won’t recognize – but I’m delighted whenever somebody does. And for experienced programmers coming from other languages, there are a few deeper issues that are language-agnostic but should be red flags for candidates that are experienced enough that they have probably been bitten by that before.

Most of the review works regardless of what language a candidate is used to. It makes no sense for a Lisp programmer to review a piece of code written in Java – but for somebody coming from a background similar enough that the code is recognizable, we just ignore anything language-specific and focus on design and general coding principles.

The most fun topics are those where the code is not necessarily right or wrong, but subject to either personal taste or project requirements. With a senior candidate, I frequently even get new ideas or learn something new. 

If you are working in a specific industry, you might also include some issues where somebody with experience in that industry could be expected to recognize some typical problems or questions. For example, when your review code deals with testing, it could have some areas that are likely to cause false positives. Or if you are dealing with payments, an experienced candidate should probably bring up issues like fraud or interrupted requests.

Doing the review on paper, with everybody having their own copy, actually works great, and is much easier than dealing with projectors or screen sharing. Just be sure to print in color, with good syntax highlighting, and to include line numbers so everybody can follow along. If your co-interviewers are not yet familiar with this interview style, or the particular piece of code being used, it’s also helpful to maintain a separate interviewers’ version of the code that includes comments about the things that are intended to be found in the interview. 

Of course, before letting the code to be reviewed loose on candidates, try it out a few times with co-workers at different levels of seniority, both to get a feel for the amount and level of issues you can expect candidates to find, and also to make sure that it is possible to quickly grasp the code and find some issues with it. 

How to perform the code review

Before the review, I ask candidates which language they are strongest in. If the code to be reviewed is in Java, but their best language is python, I’ll skip the parts about syntax or language-specific details. If they claim to be an expert in Java with 10 years of experience, we might end of going deep into the details of e.g. various implementations of List. 

It is important to point out the basic premises of the review, so they do not get lost:

This is not a checklist test, but a pretty open-ended basis for a conversation about code quality.

Feel free to cover any aspect of “Code Quality” you can think of  (for junior candidates, I also mention a few examples like readability, structure, error-safetz etc to help them get started – whereas senior candidates should be able to define code quailty themselves)

It is not about syntax, the logic or algorithm, but about quality

The code is definitely sub-optimal, and you are expected to be critical (especially important to mention when interviewing junior developers, who might be shy about criticizing other peoples’ code)

The best way to introduce the basic premise is a story like this:

“Imagine that you have been working with us for a while, and are now an experienced engineer. This piece of code was written by an intern – he was very motivated, but is also inexperienced, so there are probably many things he missed. You are all that stands between this code and production. 

Your job is to do a quality check, for any aspect of quality you can think of. There is no checklist of “10 things to find” – there are many different things one could talk about, and often also aspects that are open to discussion, or a matter of taste, or depend on context and requirements. This is not about syntax – you can assume the code compiles without errors. You do not know the requirements – this is not about the business logic, you can assume that I ran the code in the most obvious good case, and it worked. 

Feel free to think out loud, and start by just mentioning things that seem less than ideal, or strange, to you, and we’ll use that to start the conversation”

The last point is important – many, especially junior candidates, get hung up on trying to read and understand the whole code before saying anything. It helps then to subtly prompt them with “Which line are you at right now, and what do you think about it?” or even point to something specific like “Anything strange about that switch statement on line 17?”. After a minute or two it then becomes clear what is expected, and most candidates will walk you through the code by themselves. And the most interesting topics often start with an off-hand comment like “hmm, that seems weird…”

Try to turn the review into a conversation, by not just noting issues they found, but talking about how they would improve it, what alternative solutions exist, or even talking about which requirements would lead one to choose that kind of solution. 

15 minutes, including the introduction, is usually enough to get a good signal on the candidate’s aptitude. If you have to stop because you’re running out of time, that’s usually a good sign, that you’re both having fun and interesting discussions. 

Things to check for in the code review

What kind of things do they notice? Are most of their comments along the lines of “this method is way too long, and javadoc is missing”, or more like  “we could optimize performance by saving some method calls here”?

What size of things do they notice? Small details like a missing import statements, or major bugs in the control flow?

How proactive are they? Do they just comment “this code is really bad”, or provide a well-reasoned argument why,  and suggest improvements?

Do they find solutions? I do not want to ask trivia questions about e.g. the syntax of regular expressions, but if a complicated piece of code could be replaced with a trivial reges, it’s good to see that someone has regexes in their mental toolbox, and suggests to use them. 

How deep is their knowledge? You can alway dig deeper on any concept they find. For example, a piece of code where you should really, really have used a Hashmap could be just noted, or the better the candidate is the more likely you can use it as a jumping-off point to go deeper into e.g. data structures, or performance characteristics of sorting algorithms, or the benefits of multi-threading, or the possibility of a bloom filter as a heuristic alternative, or whatever else the candidates has deep knowledge in. 

Do they have good taste? Do they care to make code that is clean, well-structured and easy to understand, or “if it runs, it’s good”?

Are they current? While I do not want to make syntax trivia too much of a focus, it’s always good to include either a bit of syntax that is obviously outdated to see if they suggest replacing it with something newer, or include something brand new to see if they recognize it. 

The range of results between candidates is huge – I have had everything from “can barely even read the code, does not know anything to say about it” to “races through everything I ever thought someone could mention, including the most obscure tidbits I don’t really expect anybody to find, in 10 minutes”. And the best candidates have pointed out flaws I did not even include intentionally, or suggested possible improvements I never thought about before. But even weak candidates can, with some prompting, find at least a few things to talk about, so nobody has to walk out of the interview feeling like a total failure. 

Ideally, the code review is both fun and a learning opportunity for both sides. For me, a job interview should feel as little as possible like an exam, and instead be a conversation among experts to judge each other’s level. Pretty much what I imagine university graduation exams would be like in a perfect world – not “answer these 100 questions”, but “let’s have a conversation, and see if you can hold your own among professionals.” Doing a code review is the best way I have found to get there. 

And if you are doing code reviews in job interviews, I’d love to hear your tips at askanengineeringmanager@gmail.com

Hiring developers? Why you should do code reviews in job interviews

I’ve been involved in recruiting software engineers for a long time, to the point of job interviews taking up a significant part of my time. So I’ve done enough interviews to notice patterns about what works and what does not. The single best thing I changed about how we interview is to iinclude a code review as a standard part of the technical interview.

Why deal with code in an interview?

The most important factor for a developer is, unsurprisingly, that they are able to effectively work with code. What’s less obvious is that there are a lot of people who nominally have the right sort of experience and background by e.g. having completed a degree in computer science, but are hopelessly lost doing actual software development. Others have a different tech background than what you are using,so it might go either way – they might have to relearn their whole way of developing, or just transfer their skills to a new syntax. And the single most important thing in an interview is to not just talk about projects and tech, but get down to actually using it.

What’s the alternatives?

Asking questions about technology often comes down to a quiz about random trivia. But whether a candidate knows a particular library or function by heart is irrelevant, since in a real work situation you could always just look it up. Besides, it’s too easy to mistake “candidate happens to have worked with the same tools as I have, so knows the same details I do” with real, generalized skills.

A lot of companies do whiteboard coding, i.e giving candidates a programming challenge in the interview, and having them write the code to solve it on a whiteboard during the interview. Which is a nice test of stress resistance, but nothing else. Nobody does any real programming without an IDE (or at least a decent text editor) and access to language or library docs. You can improve by providing a laptop having all that preinstalled – but the most fundamental problem with coding tests is that the 30 minutes or so allotted to them is way too little to understand a non-trivial problem, find a solution to it, code it, test it, and bring it into production-ready shape. At best, you are testing how quickly they can whip up a first prototype. At worst, you are only testing if they can come up with the right algorithm under time pressure.

So you might instead give candidates a more significant programming exercise as a take-home exam, to complete on their own time. Which is a reasonable test for programming aptitude – except you don’t know whose, since they might have had someone else solve it for them. Or brute-forced something that’s really too hard for them by spending a whole weekend on something that you’d expect a competent candidate to finish in two or three hours. And those competent candidates will either not bother to do several hours of free work for you, or by the time they get around to it have several competing offers on the table.

A variant on this that seems to work is to take a small but real development task from a real project, have prospective candidates do it in their own time, and pay them for the time spent. This way you get a real work sample, the candidate does not have to work without pay, and both sides experience what it would be like to work with each other. I’d be a little concerned about not being able to compare candidates, since each candidate gets a different task. But if you are like any other software company, you’d probably like to hire as many good developers as you can get your hands on, not just fill a single position. So “How easy is it to work with him? Can he do the job?” are much more interesting questions to answer than “Is candidate x better than candidate y?”. The problem, and the reason we do not do this, is that you need to come up with enough development tasks that are suitable. They need to be small, not time-critical, relatively isolated from other tasks, and require neither significant setup time nor product- or project-specific knowledge – to find all those criteria in a single task basically never happens if you’re doing custom development.

Code reviews to the rescue

So for us doing a code review, by presenting candidates with a medium-sized piece of pre-written code, and asking them to review it, has turned out to be the best way to evaluate technical skills. It does not rely on google-able memorization, and is flexible in how much time you spend on it. And since it is a task that most developers have probably done in their job before, it actually measures real-world job performance rather than training for something interview-specific.

It took a few tries to get it right – so next time I’ll share some of what we’ve learnt about how to do a good code review in a job interview.

How to run a trainee program for software engineers

Why you should have a trainee program

There are 3 main ways to aquire the skills for a junior software engineering role:

  • Getting a university degree in computer science, complemented by internships or work placements for practical experience.
  • Doing an apprenticeship, i.e. joining a company straight out of highschool to be taught on the job for several years, while earning only a stipend. Often formalized and combined with additional schooling.
  • Being self-taught. Some people teach themselves programming, and have a track record to prove it, to the level needed to get a full-time job as a software engineer.

Which means there a many people that fall through the cracks because they do not fit any of those categories:

  • people who do not have the means or opportunity to go to college
  • people who are looking to switch careers into tech, but are in a stage of life where they have dependents, so they cannot afford to do a low-paid internship
  • people who are self-taught, but do not have peers, mentors or a support network to give them enough guidance to reach the level required for a ful-time position all by themselves. 
  • people who studied computer science with good success, but neglected to get practical experience. They have the foundation and the talent to be software engineers, but currently could barey write FizzBuzz. 

So there are many candidates out there that would make good programmers, but are lacking an on-ramp. 

Incidentally, a lot of those people come from non-traditional or underprivileged background, so helping them start a career in tech is not just the right thing to do, but also your chance to find talent that others might not even notice. 

What is a trainee program?

We defined our trainee program as an intense, time-limited training program to get people with a little coding experience ready for a full-time software developer position.

The time limit is important – it sets a deadline (typically 1 year), leading to a sense of urgency. And it means the company can terminate the contract after that one year if it should not work out, allowing them to take a chance on marginal candidates (remember, the whole point here is to get people into tech who otherwise would not have gotten in. 

Salary for a trainee is set at around 70% of a junior developer’s salary – high enough to make a living, and be better than most alternatives, but low enough that the company can affort to have the trainee spend the whole year with a focus not on bringing in revenues, but on learning and building skills. 

There are no formal prerequisites for our training program – requiring credentials would go against the point of the trainee program. The only requirement is that you have written enough code to be sure that this is something you want to do, and you have some aptitude for it. 

How to organize a trainee program

Tech Roadmap

You need to draw up a roadmap of topics that every trainee will learn. We do not care about academics here, but practical skills, so our roadmap covers mostly the universal basics of software engineering: version control, unit testing, linux, web frontend, SQL and so on. After that, trainees progress to the more company-specific topics, in which newly hired junior developers would often also require training before starting to work, e.g. less than universal frameworks, tools or products that our company uses. 

Practice Projects

We also have them do 2 larger projects: the first project brings everything they learnt together, by creating a small application end-to-end, from concept, architecture and technology selection to implementing the backend and the frontend, to QA and documentation. The second project does the same, but this time they create a larger application by working in a team of 3-5 people. This group project is a critical step, since working in a team exposes them to a lot of things that simply did not appear when working alone, from the need to coordinate to avoid stepping on each others’ toes, to the possibility to draw on the expertise of others, to the experience of integrating components written by different people. 


Next, create a timeline for the year of the traineeship. In our case this means roughly 6 months of bootcamp, going through the topics listed in the previous paragraph.Then 3 months onboarding to an existing project, similar to an internship, where trainees join the team off the critical path by getting involved with testing, documentation, small bugfixes etc. 

And finally the last 3 months they join a real project in a normal junior developer role, doing the same work they will do after their trainee program when hiring on as a permanent employee. The goal of this last phase is to get a good signal if they have reached the goal of the trainee program – ideally, nobody on the team will notice when they end their trainee year and switch to being a permanent, junior developer. 


Now you need to be able to teach all the topics on your tech roadmap. Which means you have to find mentors for every topic. Those mentors are normal developers that are willing and able to coach a trainee in e.g. Linux commandline basics. You should have a list of at least 3-4 mentors for each topic, because mentors need to be available full-time, and to take some time away from their main project, so not everybody who is willing will always be able to mentor. Work with the mentors to create a curriculum for the topic – that could be a wiki page listing books, articles or tutorials, references, a collection of exercises, or small training projects. 

When a new trainee starts

Once you have your roadmap, timeline and mentors in place (and yes, that does take quite a bit of time), starting a new trainee is easy. You simply check with them what they already know, adjust the times per topic on the timeline, and name specific mentors per topic. 

During the bootcamp phase, learning is mostly self-directed. The exact organization is up to the specific mentor and trainee. Most settle on something like a standup-like daily call or meeting to check on the progress, and maybe an end of day review of the exercises done during the day. Most important though is that the mentor is available during the day to answer questions and clear roadblocks. 

As a manager, you use periodic 1:1s with the trainee to check on the progress vs. the defined timeline, help out with impediments, or take action if a mentor should not be available or otherwise not work out.


What we learnt  from running the trainee program over several years

Some previous coding experience is needed. 

Not to save time on the necessary training, but to see if they get over the hump of going from a few simple lines to larger, more complex projects, and to see if they still see themselves doing development all day after the initial excitement of trying something new has worn off. People switching from a different field without previous coding experience sometimes become great developers, and sometimes try it for a few weeks, and then decide that it’s not for them. We actually got some good recruiters and salespeople out of the trainee program, by taking on e.g. a salesperson who wanted to switch to develpment, and then decided not to go through with it – but that’s not the point of the development trainee program. So now we only hire trainees who have roughly one Udemy course worth of previous coding experience (no matter how they got it). 

Motivation and ownership is the key.

 In the beginning, we thought that it would matter how much previous experience a trainee had, or how close their previous career was to software development. That turned out to not matter at all. Much more important is for a trainee to be driven and self-organized enough to get something out of their training. When our first trainee joined, our preparation and organization of the trainee program was still pretty rough, so we had to improvise available mentors, collect training resources from scratch etc – but she made it, and relished the freedom to pick her own projects and sources. 

Have a cohort of trainees. 

Instead of one trainee at at time, have 1 trainee starting every 6 months, and get them together with 1-2 apprentices per year. This way, you not only get to leverage the effort you made in preparing the program over more people, but you will also have 5-6 people in various stages of learning at any time, ideally together in one office. Fresh trainees like having someone around who was just like them not so long ago, and has since made progress. Older apprentices learn best by teaching fresh starters (and also save you and the mentors time this way!). On a social level, being a trainee, with no real project, and therefor no project team, can be lonely – having other trainees around helps. 

Have trainees interview trainees. 

The best way to convince someone to start as a trainee with you is to have them interviewed by someone who was themselves a trainee not so long ago. Plus, former trainees are the best to answer questions and talk about their experiences in the trainee program. 

Big investment up-front, amortized over time

Do not underestimate the effort needed to get started, set up the roadmaps and training resources etc. But once you have them in place, taking on one more trainee becomes ever easier. 

Get Management buy-in

The fastest way to ruin a trainee program is the expectation that the trainees will do productive work as soon as possible. That only ensures that their training will be half-baked, and they will have trouble switching projects and building skills afterwards. It has to be clear to everyone involved that the trainee program is an initial investment. Likewise, the mentors need to take time away from their projects to effectively help their mentees – that needs to be communicated and agreed with their managers.  

Unexpected benefits of our trainee program


We could pretty much always find more great trainees than we could take on. That is very different to any other position in software engineering. Since few companies are offering that kind of trainee program, it’s one of the few ways left in software to easily find great people. 


Developers who joined initially via the trainee program turned out to be the most loyal employees. People remember that you gave them a chance at a time when they did not have many opportunities, and reward you by sticking around even when the going gets tough. Theoretically somebody could sign on for the one year of the trainee program, and then take a job somewhere else, meaning the time we invested in training them is lost – in practice, that never happened. 


The trainee program turned out to be a great way to hire people from non-conventional backgrounds. People who do not know any software developers, or who do not have a role model in tech, often do not initially think that being a developer is something they could do, and only come to tech later in life, or obliquely, after going into a different field first. The trainee program gives them an on-ramp into tech, and gives your company a connection to good developers who you would have otherwise missed. 


In the beginning, it was hard to convince people to become mentors. After all, it’s an additional responsibility besides their main project and team. But it soon became popular to be a mentor – experts love nothing more than to spread their expertise, and good people enjoy helping others grow. Soon being a mentor for a topic became seen as a badge of honor, as a recognition that someone is an expert in that topic. And it is a great way to grow people – becoming a mentor was often a first step to somebody becoming a team lead or staff engineer. 

Team cohesion

In a matrix organizaton, the members of one team might be spread across different projects. Which means they spend most of their time with their project team (even though they might change projects frequently), and feel little kinship with the other members of their organizational team. Mentoring relationships are a great way to create weak ties between the members of a team, turning a teammate from “some guy who reports to the same manager” into “this is the guy who taugh me SQL when I started”.

People will surprise you

It is amazing how quickly a smart, motivated person can learn when they have a good plan, good resources, access to mentors and can dedicate themselves full-time to learning and practicing. Most of our trainees would, after having finished their one year of training, code circles around fresh university graduates who spent 3-5 years in academia. 

Round the world in 40 days: conclusion


Copenhagen was just a quick stopover on the way home – arrived in the morning, spent the day in the city, and left on a late flight to Munich. Had to change planes anyway, and rather than wait around the airport, decided to expand the stop in Copenhagen by a few hours, and use the opportunity to visit yet another country (had never been to Denmark before).

So I did not actually plan anything for Copenhagen, or know anyting about it beforehand. At first glance, it seemed very similar to other nordic cities – I could easily have thought to be in Bremen or Stockholm.

New country, capital city – that means going to the national museum.

Impressively, and appropriately, viking-looking artifacts.

Stockholm seemed nice, but not very spectacular – alright, I was probably way, way overloaded with exotic locations at that point, and also tired and not a little homesick. But I’m glad I did the stopover, it’s a very nice place to wander around for an afternoon.

Decided to take it easy, and finish the day, and the whole trip, with a nice meal on the terrace of a restaurant on the waterfront.

Bye, Copenhagen, bye, round-the-world trip – after 40 days, 4 continents, 11 countries, it’s time to go home.

Iceland: Hiking Mount Esja

Exploring Reykjavik: check. See the most famous sights: check. So for the last full day in iceland, I wanted to get out into nature, and do a day hike. It would probably be worth it to rent a car if I had more time, since lots of tempting hikes are further out in the countryside. But luckily there is a mountain close enough to Reykjavik to be reachable by a local bus: Mount Esja, a popular destination for a day trip.

The so-called “mount esja hiking center” turned out to be just a bus stop next to a parking lot in the wilderness.

A lovely start to the hike, across meadows and flowers.

The trail is getting a little less marked here, but still visible.

Came across this lovely creek, with no obvious way to cross, so waded through.

This is where I regretted that proper hiking boots did not fit in my luggage, given that my sneakers are now outfitted with a mud-based liquid cooling system.

I must have gotten off the regular path somewhere, since it’s supposed to be a really popular hike, but I did not see anybody any more, and the path became less and less marked, just barely visible as a trail through the moonscape.

But was rewareded with some nice views across the bay.

I did not go up THAT far, but the clouds are hanging low, and it’s getting cool, so decided to turn around. Even after looking at the signs on the bottom, still have no idea which path I took, or if it even was a real path, but I enjoyed the hike and the views.

Back down the hill, across the fields and creeks, and towards the bottom I met the regular parth that I must have missed on the way up.

A good finish to my visit to iceland – one of the places where I wished I would have stayed longer. I definitely plan to come back, rent a car and spend some time deeper in the wild countryside.

But for now, time to pack my bags for the early morning flight to Copenhagen, and almost home, tomorrow.

Iceland – Golden Circle

The “golden circle” is not really a circle, but the name or a popular tour of three of the most famous and beautiful sights of Iceland, all within easy daytripping range from Reykjavik.

First stop: Geysir. Yup, like a periodically exploding hot spring, the concept of which was named after this particular place in iceland, which contains a lot of them.

Warning signs are rare in iceland – it is mostly assumed that you are able to take care of yourself, and know what you are doing if you go into nature. But in geysir they do point out quite visibly that the water running off the hot springs is indeed very hot, helpfully followed by the (quite considerable) distance to the nearest hospital.

The particular geyser in geysir that is named geysir has not erupted in decades, but luckily another one named “Strokur” reliably erupts every 10 minutes or so.

The tour took a long break for lunch here – luckily I had brought sandwiches, so I could instead take a little hike up the hill behind the geothermal area, and enjoy some wonderful views of the area.

Second stop is Thingvellir – the site of the original viking parliament, and today a national park with beautiful scenery.

It’s also a place where the European and American tectonic plate meet, resulting in an impressive rift and canyon in the middle.

Some of the moss growing on the lava comes in quite bright and strange colors.

The whole area is really beautiful – I would have loved to stay a bit longer and wander round the area, but unfortunately the tour included it mostly as a quick sightseeing stop.

If you’re wondering why the sky looks so different in pictures of the same day – that is just the nature of the weather in iceland. There is no such thing as a completely dry day, but also no such thing as a completely rainy day. It changes very rapidly, and I found myself changing from warm sweater and rain jacket to just a T-shirt several time per day (given that it’s summer, the temperatures go up to a balmy 15 degrees or so).

The third and final stop of the day: Gulfoss, or golden fall, one of the largest and most impressive waterfalls.

I’ll just let the pretty pictures speak for themselves – there are paths to view it from different sides and heights, but no matter where the force of nature is impressive.

Iceland: Arrival & Reykjavik

This is pretty much the first impresson when arrving in Iceland:

It’s pretty much a moonscape, with endless, empty lava fields, with nothing growing but moss in all shades of (sometimes pretty psychedlic-looking) greens.

Luckily, it gets better: the landscapes stay heavy on lava fields and moss, and low on houses and people, but get much, much prettier – the long drive from the international airport into Reykjavik features some of the least pretty views iceland has to offer.

Also on the way from the airport: the so-called blue lagoon, a somewhat-not-really natural pool of hot water created by the runoff of a hydrothermal power plant, that appears a milky turquoise blue due to the silica in the water.

And then the people had the genius idea of creating a real pool within the rocks, and making a public pool and spa out of it. The water is pretty hot (even had to take a break for a bit, and ironically got my only sunburn of the trip in the cool iceland weather by falling asleep on the rocks), the surroundings are beautiful, the entrance includes a free facemask and a drink in the bar set right into the pool – what else could you ask for after a long flight?

It’s very touristy, and a little overpriced for what is bascially one large hot pool, but a perfect stopover on the way from the airport.

Hotels in Reyjkavik can be pricey, so I found a nice Airbnb right downtown in a typical old wooden house. Turned out to be a real gem, complete with a cozy living room, good coffee, lots of bookshelves, and even house cats. All you need to add is a piano, and I’d never leave.

Time to explore Reyjkavik. Starting with a free walking city tour offered by a history grad student – those are pretty much alway a good choice in a new city. That brightly painted wooden house is pretty typical for the older neighbourhoods in Reyjkavik.

The seat of the president of iceland. Pretty unpretentious, and with no visible guards or security – apparently it’s not uncommon for tourists to wander in, and ask the president for directions.

The monolith-shaped tower in the background is Hallgrimm’s cathedral, which dominates the “skyline”.

A bit weird, but quite pretty in an Empire state building / Art deco sort of way. I like it.

The interior is quite bare, though, and the view from the tower is not really worth it – Reykjavik is not that large, and has not much in the way of landmarks, it looks more like a smallish town with outlying suburbs from above.

The “harpa” concert hall at the harbour is one of the most modern, and futuristic-looking, buildings in town.

Its facade gives a nice view of downtown from inside.

Yup, icelanders do hunt whales, and they don’t apologize for it. And quite next to it are boats offering whalewatching tours – wonder how those two get along…

A, or rather the, famous hot dog stand at the harbour, where apparently all kinds of celebrities and visiting dignitaries have visited before. Well, the hot dogs are tasty, and cheap – unlike regular restaurants, where a completely normal meal in a completely normal, non-fancy restaurant might run 40 or 60 euros. I’m not sure if it’s the exchange rate, or the fact that most things are imported, or that iceland is a welfare state with high taxes and corresponding high wages – but pretty much everything is about 50% more expensive than expected. Guess I’ll be eating a lot of hot dogs.

No idea what the sign says, but it sounded cool. The icelandic language is quite unique, apparently hard to learn even for people who speak Danish or Norwegian, from which it split centuries ago, and due to the geographic isolation iceland is quite close to the original old Norse.

Speaking of language: While you can pick your last name relatively freely, e.g. whether you’ll be named after your father or mother’s first name, as an icelander you have to pick a first name among a relatively small list of approved, properly icelandic first names.

The picture above is from a govenment building (I think), that had an alphabetic list of such icelandic names on its facade. And guess what? Elmar is a good icelandic name! Since my name is unusual enough in German that it never, ever comes up when you have e.g. cups or souvenirs printed with you name, I was happy to find my name included on the list here.

Another rule of thumb: When in a new country, and in its capital city, go visit the National Museum. Reyjkavik’s is small, and quite good.

An exhibition about scandinavian architects and designers. I enjoyed the sparse, unpretentious looks. Remindes me a lot of Ikea furniture – so it looks like Ikea ripped off was inspired by democratized the styles of some quite famous designers.

In a shopping mall-like food court: The most high-tech public toilet I’ve seen, complete with wireless credit card payments. Credit card payments are extremely common, and accepted everywhere – probably easier to find a place that does not take cash, than one that does not accept credit cards. German shopkeepers, please take note.

Not an art museum, just a statue of Thor inside a souvenir shop.

Dinner was at “icelandic street food”, a real find in downtown Reyjkavik. Simple, but hearty and yummy traditional stews and soups, priced incredibly fairly by icelandic standards, served by the very friendly owner, who will be happy to give you a “refill” of not only the food you ordered, but also anything else on the menu, as long as you have space in your stomach. Highly recommended.

I’ll finish the day with a view across the ocean, with a weird viking boat art sculpture looking across the bay.

Orlando: Universal: Harry Potter

There is one, and exactly one, reason to go to Orlando: to visit theme parks. The city itself is a forgettable conglomerate of suburbs and amenities for themepark visitors.

Good thing I came to visit a theme park – no, not Disney world. I have been to Disneyland in Paris, and am not such a big disney fan that I’d need more. I came to visit the Universal theme parks, and more specifically the new “wizarding world of harry potter”.

Enough reason to make Orlando one of ten stops around the world? Look, I needed to stop somewhere on the east coast of the USA, and have traveled there extensively before, so it’s as good a stop as any. Besides, a harry potter themepark is one of those things that you would not take a whole long trip just for it alone, but you also cannot see anywhere else, so perfect to put it on the around-the-world itinerary.

I loved the fact that, true to form and according to the theme, there are no huge signs, and nothing overtly magical, pointing you to the harry potter themed area. You walk by a replica of King’s cross station, and you would almost pass by if you did not notice all the people streaming into it.

You pass through at platform 9 3/4 (google a video, if you want a spoiler), and find yourself in an extremly well done rendition of diagon alley. That dragon is sitting on top of Gringotts bank, and yes, it does breathe fire.

Which is also the major ride in the hogsmeade portion of the harry potter area. It’s very well done, even if it relies a bit too much on 3D effects and video, rather than a real ride (which one could say for a lot of other rides in the Universal park, too – but hey, it IS themed for a movie studio).

Everything is exactly as seen in the movies, so you really feel like you are inside a movie set. As for me, I have not even watched all the movies, preferring the books, but it’s a very good imagination of what is described in the books.

The girl in the picture is holding and waving her wand – there are lots of spots in the whole are (some clearly marked, some a bit hidden, some “secret”) where you can wave your wand and make “magic” happen (usually a puppet moving, a light going on etc). For which you have to of course buy a wand (in a convicing rendition of Ollivanders wand shop, where else), and of course that piece of plastic is fantastically overpriced, and activating the magic feature costs extra. But if I had come here as a kid, I would have absolutely loved it.

The theming is very thourough and comprehensive, down to the toilet signs.

Unlike at disney world, all the shops are real, working shops – you can really get ice cream at Florian Fortescue’s , buy prank gifts at geh Weasley’s joke shop, and get butterbeer at the leaky cauldron.

Which is, of course, in hogsmeade, the other part of the harry potter area. It is really worth it to get the entrance ticket for both parks (Universal runs two separate partks next to each other – diagon alley is in Universal studios, hogsmeade in Universal islands of adventure), so you can take the hogwarts express in between the two.

It’s not just a prop, but a real train that actually moves you between the two parks – although the “windows” of your carriage are actually screens showing the simulated ride between London and Hogwarts. Very nicely done.

I think Hogsmeade is the older part – it seems just a little less lovingly crafted, with fewer details and less to discover, than diagon alley, but still very nicely done.

And has Hogwarts castle, of course. Which is the major ride of the hogsmeade area (there are some smaller or barely re-themed rides in the harry potter area, but the main draw is the athmosphere, not the rides).

Again, a cool ride, but maybe relying too much on videos. And how much cooler would it have been if you could actually walk through hogwars castle yourself?

Of course, the Universal parks have plenty of areas and rides besides harry potter.

And some of those are rather cool – like the Hulk rollercoaster, one of the more intense coasters I’ve ridden.

All in all, a nice stopover, and well worth it if you’re in the area and love harry potter.

Next up: leaving America to go back to Europe, well, first Iceland.