For the first time ever, I was laid off, and had to find a new software developer job. I managed to find a new one, but it took longer than I thought, and it was a lot of work. I was in contact with 30 companies, got a no from 8 companies, no reply from 6 companies, and offers from 3 companies. Here is what I learnt from the process.
Posted in Programming, Work
Tagged career, interview, interviewing, job, job hunt, job-search, new job, work
For the past few months, I have been interviewing with several companies. In all cases, one or more coding tests were included. I have also been on the interviewing side, evaluating a coding test. Here are my thoughts on the process.
Because of the Corona pandemic, our whole company has now been working from home for 12 weeks. Before, we mostly worked in the office, although occasionally people would work from home, for example when waiting for a delivery. This abrupt switch has made for a great natural experiment on the differences between these two ways of working.
Many developers on both Twitter and Hacker News argue that remote work is the future, and that they want to keep working remotely even after the need for it because of Corona is gone. For me, it has worked quite well so far. However, I miss some things. Others were not quite what I expected.
In the fall of 1999 I got the biggest productivity boost of my entire career as a software developer. In the October issue of IEEE Computer magazine, there was an article by Kent Beck called “Embracing change with extreme programming”. In it, he outlined Extreme Programming (XP), which includes much of what we now refer to as agile development.
By then, I had been working as a software developer for seven years. The standard development methodology at that time was waterfall: document-heavy year-long projects, frozen requirements, change control boards, manual testing at the end of the project, and so on. Software development succeeded despite the methodology, not because of it. Reading the article was a real eye-opener. I felt it was describing how I naturally worked – in short cycles, with fast feedback, and frequent redesigns.
(And yes, I meant to write this last fall for the 20th anniversary, but I didn’t get around to it then. But hey, better late than never, even if the title has 20.5 in it now)
I often get contacted by recruiters asking if I am interested in changing company. Even if I am happy where I am, I briefly check out companies I have not heard of before. One reason is that you never know, maybe the new company is a fantastic opportunity that really is interesting to me. Another reason is that I don’t know how things will change – maybe I will want to change in a year’s time or so. These are the things I check when I am trying to evaluate a company I haven’t come across before.
The book Accelerate details the findings of four years of research on how DevOps affects various outcomes, such as software delivery tempo and stability, as well as the organizations’ profitability and market share. DevOps in this context means things like continuous delivery, automated tests, trunk-based development, and proactive monitoring of system health. It is quite clear that DevOps practices bring lots of benefits to organizations adopting them. The research findings are also in line with my own experience of DevOps.
For the system at work, I am on call one week every seven weeks. For most of the past ten years, I have been on organized on call rotations for the systems I have been developing. I think being on call is a logical way of taking responsibility for your work. You also learn a lot from it. However, it is stressful and an inconvenience, so you should get paid for it.
Continue reading
I use a shell every day. Almost always, I want to repeat a previous command, or repeat it after a slight modification. A very convenient way is to use arrow-up to get the most recent command back. Another common trick is to type ctrl-r and incrementally search for a previously used command. However, there are two other tricks for repeating previous commands that I use all the time, which are not as well known. Continue reading
During my career as a software developer, I have seen the release frequency increasing steadily. When I started, it would take 12 to 18 months for new features to reach the customer. Years later the frequency increased, so deployment to production happened every three weeks. For the past two years, we have been using continuous delivery at work. This means that as soon as a feature is ready (implemented, code-reviewed and tested), it is deployed to production. Continuous delivery is by far the best way in my opinion, and here is why:
Continue reading
Here are my thoughts on programmer career planning. You should always stay employable, mostly by changing jobs regularly (every five years or so). When changing, don’t wait until you have to. Your negotiating position is much better when you can turn down a potential new job.
Henrik Warne's blog 