The Joel Test for Programmers

The Joel Test is an established test for developers to test if a company is worth working for, or for a company to evaluate where they need to improve. It was recently adapted to focus on a programmer's abilities, so I thought I'd see how I stack up.

1. Can you use source control effectively?

I hope so. I think 'effectively' is the important word here. The only source control system I've ever used is Git, but think that's OK in today's climate. I branch and merge though I'm probably not as strict about development branches, feature branches and bug-fix branches as I could be. Sometimes I'm a bit lost as to what to put as a commit message, and I could probably do with committing more frequently than I currently do.

2. Can you solve algorithm-type problems?

I'm going to say 'it depends' for this one. An example given for this is:

Write a function to determine if two words are anagrams of each other

This seems simple to me. Sort the strings to alphabetical order, strip all non-alpha characters and compare. If no function exists to sort a string, convert it to an array. I know that seems glib and simplistic, but you get the idea. Though I'm aware as problems become more complex so the solution would be less obvious.

3. Can you program in more than one language or technology?

Yes. Off the top of my head:

There are a lot of technologies I have experience with, though it's more a case of configuring them and using the languages above to work with them. For example, I wouldn't call Redis a 'language' though I know how to work with it.

4. Do you do something to increase your education or skills every day?

Most days. Whether it's favouriting links on Twitter to read later, checking RSS feeds, looking up technologies I come across, studying other peoples' code, or just keeping up with leading figures in this industry.

5. Do you name things appropriately?

Yes, though I didn't always do this. I started programming as a kid using BASIC on 8-bit home computers in the late 1980s and early 1990s. Memory was at a premium so variables such as 'a' weren't uncommon.

6. Can you communicate your ideas effectively?

As far as I know. After ten years as a freelance/contract programmer I've worked with a lot of different people, of differing ability, on many different projects. There have been times when wires were crossed but on the whole I think I'm able to explain myself well.

7. Do you understand basic design patterns?

This was something I didn't bother with for a long time. The way I solved problems worked for me and got the job done. Now I understand that established design patterns are established for a reason and make learning new languages and syntax a lot easier. Not to mention working with other developers' code.

8. Do you know how to debug effectively?

This is a place I need to improve. Assertions and logging are my go-to for this as well as isolating problem code. I definitely need to learn to use breakpoints effectively.

9. Do you test your own code?

Another area where I need to improve. I get why it's important, I get why it's helpful, but I'm still a bit hazy on how to achieve full test coverage. Test-driven-development seems like a great idea though I'm yet to employ it.

10. Do you share your knowledge?

When I can. That's partly what this site is for. I've also contributed a little on StackOverflow and filed some bug reports on GitHub.

11. Do you use the best tools for your job?

I hope so, and I'm always willing to jump ship when I find something better. I'm not precious about tooling at all. For example, I recently moved from Grunt to Gulp. Though I was very familiar with Grunt the 'piping' approach in Gulp made a lot more sense to me.

12. Can you build an actual application?

Yes, and have done many time. Some of which have been running without issue for years.