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:
- A little Python
- A little Java
- A little C
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.