So, You Dropped Out of College

I was recently chatting to some friends about all the apprenticeship experiments going on and (name withheld to protect the innocent) lamented:

So, what happens when they quit that first job (or worse, get laid-off) and their only skill is writing a Rails app?

I know what happens. It happened to me.

Okay, I didn't actually participate in an apprenticeship program that taught me Rails. However, I did drop out of college after gaining some experience programming, get a job building web applications, and I was laid off about a year later. Getting another job wasn't so hard, but it was hard to find a job that paid as well. It turns out, there's not a huge demand for people who don't have formal education or much experience, go figure.

While I was looking for a new job I noticed that there were significantly more jobs for people with certain skills. I'm sure it differs by location and time - in Jacksonville FL, around 2000, 75% of the jobs openings were looking for people with Microsoft .net skills. Sadly, I did not have .net skills. That was when I learned that I needed to have not just the skills necessary to do my job today, but also the skills necessary to land a new job tomorrow. Since I wasn't already in that situation, I had to settle for a job making .5 of my previous salary; however, my new job did allow me to learn .net.

I firmly believe: if you have less than 4 years of experience, you should always know what technology is in the highest demand for your area, and you should be proficient enough that you can do well in an interview. Perhaps your day to day job already teaches you the most highly sought after skills, fantastic, you should probably learn the 2nd most sought after skill. Don't wait until you're already looking for a job to try to learn a new technology. The truth is, learning something new will almost certainly help you with your current job as well, so everyone wins.

note: searching hipster-programming-jobs.com to find out what's in demand is a selection bias failure. Use monster.com & dice.com. The goal is to appeal to as many companies as possible, not just the cool ones. You can focus on your dream job once you've got enough experience to ensure that your career doesn't suffer a failure to launch.

Whatever technology you choose will certainly have specific books that you should read; however, there are other books that will also help make up for the experience you (sadly, we) missed by not getting a Computer Science degree.

Refactoring was the first book I ever read that really opened my eyes to better ways to program. It's a pretty easy book to read, even for a beginner, and I can't recommend it enough. It's likely that you find that the most in-demand technology is Java or C#, and Refactoring will complement learning either of those languages. However, if you prefer, there's a Refactoring: Ruby Edition as well.

Once you've read refactoring, it's good to dig into Patterns of Enterprise Application Architecture (PofEAA). PofEAA contains patterns that are found all over the enterprise world (including ActiveRecord). You should read this book not because it is a bible, but because it shows you various solutions to commonly encountered problems. It gives you ideas about how other people are solving problems, and provides reference data that you can refer to if you encounter any of those issues in the future.

Those two books will demonstrate to potential employers that you're interested in building successful business applications; however, you'll also want to read a few books that diversify your experience and open your eyes to what can be done by using less mainstream techniques.

The wizard book and the dragon book sound like interesting fictional books, but are actually building blocks for your programming career. Both books are widely regarded as classics that any serious programmer should read. That said, they are not easy to digest. I'm not going to claim it will be fun, but you should push your way through both of these books - and then do it again a year later. These books can help shape your career in a positive way, especially the wizard book, perhaps more than any other text available.

Once you've pushed through both of those books, there are a few follow up options. If you preferred the wizard book, I would recommend following up with The Joy of Clojure or Learn You a Haskell For Great Good. You're unlikely to get a job using either technology, but both will broaden your horizons and also demonstrate to potential employers that you are deeply interested in increasing your programming capabilities. If you preferred the dragon book, I would move on to Domain Specific Languages. Domain Specific Languages is the definitive guide to DSL programming, and provides you with many examples of how to put DSLs to practical use within your applications.

Once you've made it through all (or most) of those books, you shouldn't have any problem finding a job that is both satisfying and also pays well.

Understanding Why

Why is the most important question a software developer can ask. It is your responsibility as a developer and failing to do so is negligent and unprofessional.

I think Fred George would agree with me. Why is important enough to Fred that he uses it to determine if you are an apprentice or a journeyman.

An apprentice is a developer who is still learning the requisite skills... Techniques are being learned, but the why of the technique is still a bit vague. --Fred George

Unfortunately, I don't think why is asked nearly enough.

A great example is best practices. Best practices are defined by masters to help journeyman and apprentices learn and complete their tasks. But, best practices are rarely silver bullets, in fact the vast majority of best practices are heavily influenced by context. And, this is where the problem lies, the vast majority of software developers don't ask why a practice is considered best. Instead the common behavior is to blindly follow contextual advise without any thought given to the current situation.

Most test suites are also great examples of people failing to ask why. Programmers have gotten quite good at using OO concepts and patterns, but do they truly apply to testing? Largely, no. Of course, that's not surprising since tests are not object oriented.

Tests are often written using an object oriented language, but the tests themselves are not object oriented. In fact, the large majority of tests are purely procedural. Tests have one entry point and (hopefully) one exit point. Tests generally set up some state, then verify a result, that's it. Since tests are not object oriented, concepts such as DRY, inheritance, and polymorphism often lead to less readable code.

The problem is, rarely does anyone ask why a test is written and what purpose does it serve.

I write tests that help me write better applications. Tests must be readable, reliable, and performant. I want tests that focus on one thing, so when the test breaks I can quickly figure out what has gone wrong. I want tests that only break when something went wrong, so I don't waste time investigating side effects. And, I want tests that run quickly, so I can run them hundreds of times a day. When I write a test, I ask those questions, not whether my code follows good OO patterns.

Not asking why leads to poorly designed applications. Conversely, asking why often leads to innovation. Someone asking why led to C, Java, Smalltalk, Ruby, and every other language. Why also led to evolved frameworks and various other productivity boosting tools.

Asking why is almost always a good thing, and doing so is your professional responsibility.