Wow. Next month it’ll be 16 years since the original publication of the Joel Test. In case you’re not aware of the Joel Test, it’s a simple 12 question check for evaluating how good a software team is. It’s not meant to be exhaustive, and scoring is simple - 1 point for each question you can answer yes to. If you’re scoring 10 or lower, you’ve got serious problems. In the last 16 years, software engineering has changed a lot, and I think it’s time to update Joel Spolsky‘s “highly irresponsible, sloppy test” (Joel’s words, not mine).

Yesterday was a momentous day in British history. It was the day after the EU Referendum, and the day we all found out that the people of Britain had voted in favour of leaving the European Union. I’ve never been affected by the result of an election as much as I was yesterday. Britain felt different, and I didn’t feel part of it. I voted Remain, but it’s not the way I voted which I feel compelled to write about.

How do you know when something is “Done”? What do you use to measure “completeness” of the thing you are doing? In agile development, User Stories are often used to define the thing to be done. The user story outlines the goal that a user wants to achieve, and the reason why a user wants to achieve this goal. It provides the who, what and why for the thing to be done.

Recently, an article about the changes to the development process at Yahoo caught my eye. In a move to improve quality, speed and efficiency, Yahoo removed the “QA Team” from their development process. According to the article, the change resulted in an increased focus on automation. Checks previously completed by “error-prone” humans were now done by code. If the checks passed, the code went live. The article goes on to report that this “paradigm shift” caused the number of errors to go down.

I’ve become a bit of a fan of pair programming over the years. I enjoy working through problems with another developer, as I find it usually leads to a deeper understanding of the problem, the domain and the improves the quality of the code that is produced. I also almost always learn something. Pair programming is the name of a development practice where two developers work together to solve a problem in code, usually using a single computer, with shared input devices.

Such is my life at the moment, I started writing this article on my smartphone whilst commuting home from work. The reason for this? I’m busy at the moment because my team is hiring. I spend most of my time in the office reviewing CV, speaking to recruiters, headhunting candidates, and, of course, conducting interviews. I’ve written about what I look for in a good CV, so I thought it was only logical to write about the next stage - the technical telephone screen.

I’m lucky enough, at least in my opinion, to work in a team that values extreme programming practices. It’s not true of every team at eBay, but it’s a growing trend. Extreme Programming (XP) is something I’m comfortable with, and I hope to help other teams see the benefits, and start to put some of the practices into play. As part of helping other teams, I thought it’d be prudent to refresh my knowledge of Extreme Programming.

Recently I’ve been spending a great deal of time screening technical CVs. What struck me during this process is generally how bad engineering CVs are. There are some great candidates with fantastic, concise and to the point CVs, yet these are few and far between. In the main, I’ve found that I’m faced with a multi-page document, which, despite it’s size, tells me little about the candidate. Perhaps most importantly, it doesn’t make me want to pick up the phone.

Unit testing can be hard. And it gets harder when you have to test code with with external dependencies. The way you deal with this will depend on whether you are a classical or mockist programmer. Most people don’t exist at the extremes, but instead are somewhere along the line. This isn’t a bad thing. Being pragmatic in your decisions shows that you’re a mature engineer. Dealing with legacy code is also a thorny problem that most of us will encounter.

Is being a manual tester a dead-end career as @jsonmez says in his video response for Simple Programmer? I’m a developer and I’ll admit that I’ve looked down on testers in the past. It’s not something I’m proud of. I was wrong. The argument that you need to be a developer to progress with a career in technology is harming our industry. Videos and comments like the ones from John are not helping to get rid of the stigma associated with testing.