Books I read in 2015

One thing I miss about being a grad student – I spent a lot of time reading! Since I got married and got a job, my reading time has gone way down, especially for fiction. That said, I’m making the effort to find time to read. This past year I also picked up an induction loop (which lets me stream sound from my phone to my cochlear implant), letting me listen to audiobooks during my commute.

So here are the books that I enjoyed in 2015, roughly organized by type. Most aren’t new, and some aren’t even new to me; they’re just books I read in 2015 and liked enough to mention.

Computer books

Soft Skills: The Software Developer’s Life Manual by John Sonmez

I wasn’t familiar with John Sonmez until I ran across this audiobook last year, but decided to give it a shot, and was glad I did. John has a good reading voice, and the book was interesting all the way through, even when I didn’t agree with him.

This book isn’t about technical skills; it assumes you already have those. Instead, it’s about using those skills to get what you want. John discusses topics like how to start freelancing, specializing as a developer, creating and selling products, and becoming more productive.

The book covers a lot of ground – over 70 short chapters – so it obviously doesn’t get too in-depth into any one topic, but it has a lot of good general advice, and the writing/speaking is good enough that I enjoyed even the topics I was already familiar with.

One problem I had with the book is there are a lot of url references, but no easy way to find them again at the end of my commute. I wrote to the author about this a few months ago and was told he intends to eventually make them available on his website.

Code Complete 2 by Steve McConnellCode Complete 2

I somehow managed to avoid picking up a copy of this classic book on software development until last month, when I get it for Christmas. I haven’t finished reading it yet, but I can tell it’ll get a 5-star review from me; unlike many technical books, it’s actually fun to read.

Simply put, this book teaches you to write good code. Good code, in this case, being defined as code that’s easy to understand and without bugs. Over the course of some 850 pages, Steve covers best practices in many areas of software construction that lead to code which is easier to read and maintain. For the most part, this is stuff that I learned in school, but it’s a great refresher and has taught me a thing or two.

I would have liked it if there was a third edition of the book – surely software development must have improved somewhat in the last decade? – but I can still tell that this will be one of my most highly recommended books.

Parenting books

Scientific Secrets for Raising Kids Who Thrive by Professor Peter M. Vishton and The Great Courses

Scientific Secrets for Raising Kids Who Thrive It’s not difficult to find parenting advice; a search for parenting on Amazon returns nearly a quarter million results. But what does science have to say about child development? In these lectures, Prof. Vishton covers the research on everything from bedtime to homework, number chains to video games.

When so much parenting advice boils down to “this is what worked for my child”, it’s nice to see evidence-based recommendations. I found the book both entertaining and educational and expect to listen to it again. The audiobook also comes with a 226-page course guidebook that covers the contents of the lectures and gives suggested readings and resources.

The Five Love Languages of Children by Gary Chapman and Ross Campbell

How do you express love in a way that the other person will understand? Dr. Chapman has a number of books about the way people express and receive appreciation through what he calls the five love languages: Words of Affirmation, Quality Time, Receiving Gifts, Acts of Service, and Physical Touch. I haven’t read any of the others, but decided to give this one a listen; it’s a mix of stories about how speaking a child’s love language helped to reach them and tips on how to speak each language yourself. What I liked was the part about how we sometimes talk past each other because we’re trying to express love in the way that we want to receive it, or the way that we’ve seen it expressed in the past, rather than the way that our partners or children need.


Phule’s Company by Robert Asprin

Phule's CompanyI used to have a number of books by Robert Asprin and this is one of my favorites; it’s unfortunately out of print but used copies can be found very cheaply. This is the first book in the very funny Phule’s Company series, about a group of military misfits, shipped off to easy duty in the backwoods of the galaxy to keep them out of the way. When Captain Willard Phule needs to be discretely punished – he is, after all, the megamillionaire sun of the man who supplies the Space Corps with most of their weapons – he’s assigned to command them. Of course, Phule takes his job seriously, and isn’t above dipping into his fortune as he molds his men, women, and aliens into an effective fighting force.

If you can’t stand puns and want your science fiction to stay serious, avoid this book. Otherwise, dive in!


How to Fail at Almost Everything and Still Win Big by Scott Adams

Somewhat of a cross between an autobiography, a book of career advice, and a humorous self-help book, this one was actually way more interesting than I thought it would be, and the audiobook was narrated well. You’re unlikely to agree with everything Scott has to say, but it will at least be entertaining, and those people looking to start a business may find his advice quite helpful.

Economics, 3rd Edition and Unexpected Economics by Timothy Taylor

I’ve always been interested in economics, but scheduling kept me from studying the subject in college. In Economics, Prof. Taylor covers the fundamentals, including both microeconomics and macroeconomics, while in Unexpected Economics he applies economics to questions you might not have considered to be part of this area. I found Prof. Taylor to be an engaging lecturer and am in the process of listening to his audiobooks for the second time.

Blocks magazine and The Ultimate Guide to Collectible LEGO Sets: Identification and Price Guide

Blocks magazineWhen I was a kid, I always wished I could afford to buy some of the big Lego sets; I particularly loved the Space Police / Blacktron / M-Tron Legos. Unfortunately I never had the money; then, once I started working and had the money, I never had the time! In the last few years, I’ve made the time to do a little building; I recently completed the new Doctor Who set (which is awesome), and my wife and I have almost finished building the Tower Bridge. For the last decade, I’ve also make a few bucks buying Lego sets on sale and then reselling them after they’re discontinued.

Blocks magazine covers all aspects of collecting, building, and investing in Legos; as a British import it’s not cheap, but it’s worth the cost. I only learned about it a few months back, and have been picking it up whenever the latest issue shows up at Barnes & Noble; subscribers also get a free zombie postman minifig after the first year. The book, on the other hand, is all about Lego sets as investments. I have my own investment strategy, but I picked up the book for fun; it talks about a lot of sets from the past few decades and how they’ve appreciated over the years, which is interesting even when it’s not useful.

The Book with No Pictures by B. J. Novak

This is, of course, a children’s book, but one that is meant to be read – aloud – by an adult. The theme is that the adult is tricked into reading the book full of silly words, and all words in the book must be read, no matter what. It’s absolutely hilarious, and demonstrates to kids that books don’t need to have pictures to be a lot of fun.

The value of a computer science education for programmers

It’s not uncommon to see people decrying a computer science degree as not effectively preparing students to be programmers. Of course, this misses the point that it’s not intended to do so; computer science is the study of computation, not the study of how to program. Indeed, the 2015 Stack Overflow Developer Survey found that only 75% of programmers responding said they studied computer science at a university, and many of those still described themselves self-taught.

And yet, every year another 40,000 students graduate with a bachelor’s degree in computer science, and many of them go on to work as programmers. If programming is so remote from computer science, why do so many people who want to program start with a computer science degree?

Before I try to answer that question, I should mention my background. I have bachelor’s, master’s, and PhD degrees in computer science and have worked as a software developer for the last five years. At the same time, I would also describe myself as self-taught, because while I had a couple of programming classes in college, for the most part we were just expected to pick up languages as we needed them. The focus was on what we could do with computers, rather than the mechanics of any particular language.

Why people get a computer science degree when they want to program

I think there are three main reasons why people study computer science.

Photo of the name "Department of Computer Science"
CU Computer Science” by AberlenOwn work. Licensed under CC BY 3.0 via Commons.

The first group is people who just like computers and want to learn more about them; I fall into this group. Since we’re into computers, computer science is the natural degree path to take. Once we graduate, programming is one of the most obvious computer-related career paths to follow.

The second group is people who enjoy programming, figure they need a college degree, and settle on computer science as the most relevant degree. This doesn’t make it the wrong option; most people benefit from getting a well-rounded liberal arts education offered by a bachelor’s degree. However, there are also a number of people who really only want to learn about programming, and would most likely be happier in a certification program from a technical college that is entirely programming focused. Lately we, as a society, have started to think that everyone needs a four-year college degree, and that’s really not true; for people who know that they want to pursue a trade, going to trade school for two years can be a much more financially sensible decision.

The third group is people who decided to get a degree in computers because they heard that it guarantees them a lot of money. Hint: it doesn’t. People in that group are most likely not reading this blog.

What a computer science degree does for you

So, given that computer science classes don’t teach you to program (at least, not past a very basic level) and getting a four-year computer science degree is so much more expensive than attending a technical college or code camp, why do people – at least, those who want to be programmers and know about the other alternatives – do it?

One reason, of course, is that it expands your options. Having the degree both means that you’re qualified to do more different types of work, and makes it easier to get in the door with employers who will only consider people with degrees. It’s been said that the bachelor’s degree is the new high school diploma: it shows employers that you have a basic level of education.

But suppose you know you’re only interested in programming, and further, you’re confident you can get a programming job with or without a degree. Is it still worth it?

How a computer science degree makes you a better programmer

Again, let’s start with the basic assumption that you are, for the most part, going to teach yourself how to code. Getting the degree can still help you in two areas: getting a job and being better at it.

Getting the job

Being enrolled in a computer science program opens up more opportunities. It’s easier to get an internship (which, for programmers, can actually pay pretty well), which can essentially be an extended job interview; it lets you see if you’re interested in a job, while letting the company determine whether they’d like to keep you around without the overhead of hiring you as a full-time employee. I never did an internship while I was in college, because I was a math tutor at the time, and ended up regretting it as it’s the easiest way to get experience.

Many companies also recruit for their full-time positions as selected universities – they have a relationship with schools that tend to send them good programmers and so make a habit of looking for new employees there. I’d never even heard of the company I now work for until they took my resume at the job fair for computer science students at my school.

Doing the job

Ok, so now you have the job. What next?

We’ll assume that you have decent programming skills, and you’re keeping them up to date. Many programmers like it so much, they write code in their free time as well. That still leaves the question: what kind of programmer are you doing to be?

Drawing of a monkey coding.
Code Monkey by Len Peralta. Licensed under Creative Commons.

Are you going to be the type of programmer who’s only interested in writing code? Someone else determines what code needs to be written, and you implement it. Let’s be honest here – if you’re this type of programmer, who just totally loves to code, you’re probably going to do a better job in this kind of position than anyone else. For you, the degree may be redundant.

On the other hand, what if you’re interested in taking on a larger role? For lack of better terms, I use the word ‘programmer’ to mean someone who primarily writes code, and the phrase ‘software developer’ for someone involved in all aspects of, well, software development, including programming.

Being a software developer

As a software developer, my job involves writing code. It also involves testing other people’s code, creating designs for the code I’m going to write, critiquing other developers’ designs, and writing documentation explaining what the code does, how it should be tested, and how it should be explained to the end users. Programming is a large part of my job – maybe the most important part – but it’s not the only part, nor does it even occupy the majority of my time.

So how does having a well-rounded education help here? You need to be able to:

  • Analyze requirements to determine what actually needs to be built
  • Write clear documents that effectively communicate the intent of your code
  • When the efficiency of the code matters, determine what algorithms will work best given your unique conditions
  • Ensure that the resulting product is usable by people who are not experts on (or familiar with) your code

Some of these things – particularly algorithms – are taught in computer science classes. Others are general education requirements that you’ll have to satisfy to get the degree, even though they’re not computer-related; things like English Composition. I’ve seen more than one person complain about their college forcing them to take classes on subjects like English that they’re not interested in, but they actually are important to being a software developer. English classes teach you to communicate. Math classes, well, let’s just say I probably wouldn’t be too trusting of any program written by someone who can’t handle college math; computer science is essentially an extension of mathematics.

Always be learning

Face it, though: in ten years, you’re not going to remember most of what you learned in college. What you will remember, hopefully, is how to learn. As a full-time college student you get a lot of information thrown at you, and you have to be able to pick up the basics of multiple different subjects quickly in order to succeed. Which actually sounds a lot like a job working with computers, where you have to be constantly learning about many different technologies.

Now, about those student loans…

Overcoming Impostor Syndrome

About six months after I started my job, I mentioned to my mentor that what worried me was knowing that I was the worst developer on the team. She told me that I was definitely not.

People are often bad at judging how good they are at things. At one end of the scale we have the Dunning-Kruger effect, in which people who aren’t particularly good at something mistakenly believe their level of skill to be very high; people who are incompetent rarely recognize this. At the other end, people who are skilled at a given task tend to find it easy, assume that others also find it easy, and thus tend to underestimate their own skills; after all, they’re only good at easy tasks!

Computer programming is such a complex task, with new things constantly needing to be learned, that it’s very easy to feel like you’re falling behind. Then you look at your coworkers, who don’t appear to be having any particular difficulty, and feel like you’re not good enough to deserve the position you’re in.

Graph of actual vs perceived ability. When actual ability is much higher, we have Impostor Syndrome; when perceived ability is much higher, we have the Dunning-Kruger Effect.
Image courtesy of Imgur.

When I confessed to one of the senior developers on the team that I didn’t really feel like I knew what I was doing, he said he also felt that way during his first year, which made me feel better about my situation. After my first year, I still felt a little out of my depth, but the feeling of “I have no idea what’s going on!” had gone away.

The turning point for me was shortly after my second year with the company. The coding metrics we use showed that my performance was in line with the rest of the developers, and I got a sizable raise. This was when I started to relax. I figured, based on the raise, that my employer thought I was doing a good job, so I could probably stop worrying about getting fired because I didn’t know what I was doing.

Being a programmer means constantly failing at things; you never seem to feel fully competent (or at least, after five years, I still don’t). Of course, when you’re just starting, the feelings of inadequacy are natural; without experience, you really aren’t particularly competent yet! But when it comes to programming, those feelings may never go away because you never feel like you’re caught up.

One thing that stuck with me last year, when I heard Bob Martin speak, was he mentioned that the number of programmers doubles every five years. That means that, even though I had very little practical experience when I started my job five years ago, I’m now more experienced than half of the developers out there! Additionally, my job is not static – I have to do new things all the time, which means constant frustration but also constant learning. A few days ago, it occurred to me to think about it mathematically: if I’ve improved my skills by 2% each month, then I’m twice as good as I was three years ago. Of course, if it’s hard to measure how good people are at programming, it’s likely going to be even harder to measure improvement, but if you can find some sign each month that you’re a better programmer than you were the month before, you’re probably on the right track.

And if you were competent three years ago and you’re twice as good now, then you’re probably not terrible at this after all.

Unit Testing: What I learned my first year

In 2014, I decided that one of my goals in 2015 was to start doing unit testing at work. I picked up a copy of The Art of Unit Testing and read a reasonable amount of it. I was excited about the idea of being able to automatically catch bugs, making it less likely that they’d slip through to be found by my code reviewers or testers.

Book cover from The Art of Unit Testing

Unit testing refers to automated tests designed to each test one “unit” – usually a function – in your code. This means checking that for any given input, the function will return the appropriate output. This is used before integration testing, in which the various units are tested together to ensure they work well together.

In 2015, every time I developed a new activity, I wrote C# unit testing code to go with it. When I worked on existing activities, I wrote C# unit testing code for them. Here’s what I learned:

1) Unit tests don’t catch bugs as much as they prevent bugs.

Long, complex functions are difficult to test; you have to ensure that you’re covering every possible path. Short, simple functions that do one thing are relatively straightforward to test. That means that to make testing easier, you end up changing the way you write code.

1a) Unit testing makes your code more modular.

Simpler code, of course, is less likely to contain bugs, which means that just writing code with unit testing in mind can improve your code quality…whether or not you ever actually write the tests!

2) Unit testing promotes the refactoring of existing code.

When you write unit tests, the test class becomes another client of the class under test, and it becomes appropriate to update the class under test to make it more testable. This means that writing tests for your existing code is a good excuse to go back and refactor that code, which means that if your team decides to add tests, you can use that as justification to spend developer time paying down your existing technical debt.

3) Unit tests take time now, but they save time in the future.

I’ve heard more than one person say that doing unit testing doubles the amount of time it takes to write code – after all, you’re writing twice as much code! I don’t write THAT much test code, but I’ve heard from people who do. You get some, but not all, of that time back later in the process, because you’ve made the testing process easier (if your tests accurately describe each unit, then you know it does what it says it does) and your code easier to read.

The real time savings, however, may come in when you need to make changes to the code later on. Having existing unit tests in place reduce the need to do regression testing; if you change a unit, then run the unit tests without errors, you know that you haven’t changed the expected behavior of that unit of code, and you can focus on doing integration testing for your new workflow.

Image of a bug4) During development, unit tests are just as likely to be wrong as the code under test.

Code is code; if you’re writing your unit tests and your code under test together and the unit tests fail, it could equally well be either set of code that’s buggy. That’s not even completely true; I find it’s usually the test that’s wrong, because I’ve missed that the code under test will only ever be called after some preconditions are met and I haven’t set up those conditions properly in the test code. Still, assuming you’ll find the problem whenever a test fails, if you’ve defined your conditions correctly, the only way to get a false negative (meaning the code is wrong, but the test didn’t catch it) is if both the test and the code under test are buggy, which is clearly less likely than only the code under test having a bug.

5) It’s good to make tests fail: the benefit of test-driven development.

When I started doing unit testing, I would write the code under test, then write unit tests to verify that code. Since I’d be calling the functions being tested from other functions I was developing, I’d generally catch bugs well  before I actually added the unit tests that would capture those bugs.

I’m currently trying to move more towards test-driven development, where you write the tests first and then develop the code. In other words, first define the function signature and behavior (but don’t actually make it do anything), and then write the unit tests for that function. The tests will fail (because the function doesn’t do anything) and you can then add the actual functionality. If the tests pass, then you might have discovered a false negative and can fix the logic in your test before it trips you up running against the actual code.

6) Unit tests help you understand your code better.

This may be the largest benefit of unit testing for me. When I’m writing assertions against my code and the name of the function I’m testing doesn’t quite line up with the functionality I’m expecting, the assertions don’t quite make sense, and I know I need to rename the function (or a parameter). Additionally, unit tests are a way to document your code which is always correct; if your unit tests are all green (passing), then they should be accurately describing the functionality of the code. Unlike a comment, unit tests have to be updated when the code changes…at least, assuming you don’t allow code to be checked in with broken unit tests!

Is it worth it?

When I started writing unit tests, it was essentially because I was interested in trying them out. The company offered some training on how to write unit tests, but there was no mandate to actually use them. What I’ve found is that, while I’m not really finding bugs with my tests, they’re helping me to write cleaner code that will be easier to maintain in the future. For this reason, I’m now strongly encouraging the rest of the developers on my team to do unit testing as well.

In the past, we’ve had issues with functions and classes that get overly long and complicated. Now that we’re migrating our client code to .NET, I see unit tests as one way to encourage writing code that will be much easier to update in the future.

Usability: Multi-page articles

Ok, we get it. Banner ads are how you pay the bills for hosting your site, and the rate you can charge for them has been dropping year after year, which means you need to show more ads for the same amount of money. Which brings us to the latest trend: articles that could be all on one page, split up over 20 or 30 pages so that the user has to click next every couple of sentences (or even after one picture with a one-sentence caption).

The Page One extension for Chrome and Safari replaces the broken up pages for some popular sites with the single page version.
The Page One extension for Chrome and Safari replaces the broken up pages for some popular sites with the single page version.

Stop doing this.

First off, it doesn’t work. Sure, some people are going to click through the entire article and you’ll get to show all 30 of your ads (otherwise you wouldn’t be doing this). Other people are going to click in, see the “page 1/30”, and click back. You got your one ad impression, just as if you’d put the entire article on one page, but you’ve also ticked off the user, who isn’t going to even think about linking to your content. Do it enough times, and users are likely to start actively blocking content from your site.

Second, it doesn’t work. If you’re irritating a large portion of your users this way, your click-through rates are going to drop, which means the amount you can charge for call to action banners will drop, which defeats the purpose of splitting up the article in the first place.

Third, it doesn’t work. Writing this post, I’m trying to recall what the last banner ad I saw was advertising…and I can’t. I don’t have an ad blocker installed (popups are another story); like most users, I just barely notice them. Even when I do, they’re generally either irrelevant or for something I already purchased – after I bought a cat tree a few years ago, I got advertisements for the model I’d picked (on the site I bought it from!) for the next month. Advertising can be useful to the user (and thus profitable for you) but random Google ads on a page with almost no relevant text probably aren’t.

If you have a 20,000 word article, fine, split it up into pages – that’s actually helpful in case I need to bookmark the page and come back later. But 20 words on a page? Throwing a big picture next to the words doesn’t excuse you for creating a poor usability experience.

Usability: On creating password rules

These days, everyone wants to make it clear that they’re taking security seriously. So they make each user create a password which contains at least eight characters including a lowercase letter, an uppercase letter, a number, a symbol, and some other rule that’s completely different from every other website. Then when you can’t remember your password (I know, I know, we should be using password managers and just remembering a master password) they show you the rules and make you set a new password, which can’t be the same as a previous password. Which means that next time you actually do remember your old password…

Panel from an xkcd comic about password strength.
xkcd is awesome. You should read it.

Minimum password lengths are a good idea. Expanding the character set is probably a good idea. But there’s actually a really easy way to improve usability and not tick off your customers. If I hit the “forgot password” link? Show me the password rules! I know my own thought processes; if I know what the rules are for choosing a password on your website, there’s a pretty good chance that I’ll immediately figure out what my password is rather than having to reset it with something that’s more difficult to remember. You’re not making things any easier for hackers, but you’re making it a lot easier for users.

Project management and consistency in coding

Whenever a team leader position has opened up at work, I’ve been very clear that I’m not interested. While I have no problem with managing people – many of my jobs have involved this – I’m currently focused on improving my development skills.

However, running a project I have no issues with, and for the last few months I’ve been in charge of my team’s web migration project. This has largely consisted of planning out our timelines and helping our newer developers get up to speed on our team’s standards for web development.

"Editing a Paper" by Nic McPhee. Used under Creative Commons license.
“Editing a Paper” by Nic McPhee. Used under Creative Commons license.

I ended up sending one development log back to the developer several times with instructions to put things in the correct order. I don’t mean that the code didn’t work; I mean that I wanted the overridden methods, helper functions, and properties to be in the same order, and functions to be named the same way, as they are in the other classes.  Given that the compiler doesn’t care, why do I bother?

While we’ve been transitioning our legacy code to web, I’ve been taking advantage of the rewrite to ensure that the code is easier to read and update in the future – best practices have come a long way since it was originally written! One thing that makes no difference to the computer, but makes a lot of difference to the programmer, is consistently doing things the same way from file to file. Once you’re familiar with the conventions, it’s very easy both to locate the code for a given piece of functionality and to understand how the logic works.

This is the same reason that we have naming conventions for variables and functions. In C#, if I see a variable name in camel case I know it’s a local variable, while Pascal case means it’s a property. In JavaScript, a function call in came case is for a JavaScript function, while a call in Pascal case is for a C# DataMethod. The event handlers for the save and restore buttons might have different code in different activities, but they’re still named and called the same way. Consistency means that developers aren’t using brainpower to process trivial differences in the code, which makes it easier to focus on the functionality. At a functional level, solving the same problem the same way each time makes it easier to avoid bugs in the code, as we only need to make a particular mistake once.

Paying for Quality

Back in September, I listened to the Soft Skills: The Software Developer’s Life Manual audiobook, from John Sonmez of, and really enjoyed it. Except for one part, which ticked me off.Soft Skills book cover

In chapter 17, Resumes are BORING, John recommends hiring a professional resume writer to do your resume, under the assumption that this is a skill that you probably have never developed and it’s worth paying a few hundred dollars to get someone who really knows what they’re doing. So far, so good.

Then a few minutes later, when he’s talking about branding, he recommends going to Fiverr and having someone do your logo – the image that’s going to represent you for the foreseeable future – for $5. See the disconnect here?

Now, I have to admit to a bias – my wife is a multimedia designer, and the challenge she faces in finding new clients is exactly this: people who don’t appreciate the difference in quality between a professional designer and the type of person you can hire for $5 off fiverr or craigslist. It’s even worse for websites: too many business owners would rather buy a crappy template site for $100 from someone off craigslist than spend $1000+ for a professional site, even if the cheap site will end up turning away customers in the long run.

I wouldn’t describe myself as cheap, but I don’t like paying more for things than I have to either. When I’m shopping for non-food items for myself, I aim to get them for a least a quarter off. Yet, when I’m deciding what to purchase, quality is (within reason) a larger determinant than price. Why? Quality might cost more up front, but it saves you money (and will make you happier) in the long run. To take a geeky example, I’d rather have one copy of Food Chain Magnate (a VERY good $100 board game) than ten cheap games like Uno, Monopoly, etc; the high-quality game will provide more enjoyment over time.

Photo of the Epicurean garlic press
A $25 garlic press. Well-made tools pay for themselves in lack of hassle.

The same thing applies to services: you can’t (or at least, shouldn’t be able to) get services from an expert artist (or designer, or coder, or any other professional) for the cost of a cheap meal.

As software developers, we expect to be well paid for our expertise; shouldn’t we expect that other people who are also experts in their fields should want and deserve the same?

As professionals, we know that it’s more efficient for a company to hire us at a high rate to create a software package than to hire a college student with enthusiasm and a low hourly rate but without the experience or education to create the product that best meets the customer’s needs. Shouldn’t we express the same judgement when choosing services for ourselves?

Settings Goals in the New Year

I don’t believe in New Year’s resolutions.

It’s almost a cliché that these resolutions never work. We start off with good intentions, and maybe even keep them going for the entire month of January. Then something happens and we miss a day. We get frustrated. Having missed one day, it’s easier to miss another. And soon, the whole resolution is out the window and we’re mad at ourselves for again failing to meet our self-imposed obligations.

New Year's Resolutions

What I do believe in is small goals with deadlines, and systems. The goal “I’m going to finish writing my next book by the end of March” doesn’t work; the result is procrastination until the end of February, and then not doing anything in March due to guilt over wasting the first two months of the year and the impending sense of doom from knowing there’s not enough time remaining to actually finish.

Specific and Achievable Goals

The goal “I’m going to write at least 50 words for my book every day” is much more achievable. It’s not very much work, but more importantly, it doesn’t feel like very much work – how long does it take to write 50 words? It’s also specific – you know exactly what you have to accomplish (write at least 50 words) and when (before you go to bed each day). If you happen to write more than that, great, but as long as you write at least 50 words, you can go to bed feeding satisfied that you have met your goal. Eventually, this becomes a habit, so it doesn’t even use up your limited supply of willpower – writing 50 words is simply part of your daily routine, like brushing your teeth and (unfortunately) checking Facebook.

For the last few years, my goal has been to finish my PhD, which meant that I needed to finish writing and defend my dissertation. This is essentially the same problem as the writing a book goal above, with the added strain of being mentally challenging and requiring a lot of concentration. I often found myself looking at the desired end result – completing the dissertation – rather than setting small, specific goals, such as proving one lemma, and the result was that I never wanted to work on the dissertation; it simply seemed too overwhelming. Fortunately, I had an external deadline – the pending expiration of my earliest credits – which finally forced me to sit down, finish the dissertation, and complete the degree. So that was my big accomplishment in 2015 – after much procrastination, I finally completed one of my lifelong goals.

My Goal as a Developer

This year, I’m formalizing something I’ve been working on for a while – developing my skills as a programmer. I’ve been writing code professionally for the last five years, and lately I’ve moved into more of a leadership role on my team. This year or next, I expect to be promoted to Senior Software Developer, but I don’t yet feel like a senior developer; while I no longer feel like I don’t know what I’m doing, neither do I feel like an expert programmer.

The things I’ve been doing to develop as a programmer are not wrong – actually, I’ll be continuing to do them. Obviously, I’m getting more experience by going to work and coding every day. I read a lot – I’m currently working on Code Complete 2, which I somehow managed to avoid until now – and I recently signed up for a Pluralsight subscription. In other words, I’m getting the two things I feel like I need more of – knowledge and practice.


Code Complete 2 book cover

The problem here is that while these are good practices, they’re not specific. About three years ago, I picked up a copy of CLR via C#, and really enjoyed it. I picked up a better understanding of a few things that I was able to apply at work. One thing I never did, unfortunately, is finish the book; one day I just stopped picking it up, so I never got to some of the fun topics towards the end. Similarly, I had a free trial at Lynda, which I never really got around to using. I’m finding that I need deadlines to keep myself working on the things that I want to do, but that are less fun than, for example, watching Doctor Who or playing Tichu, or less urgent than feeding the dogs and doing the dishes.

So for this year, I’m going to give myself some recurring deadlines. They won’t be hard to keep up with – I don’t want to just miss one in January and then give up on the whole thing – but they will meet the following requirements:

  1. They will be specific. I will know exactly what I need to do, and when I need to do it.
  2. They will move me towards my goals. The goals might be nebulously defined (what does it really mean to be a better programmer?) but the deadlines will be for things that will point me in the right general direction. It might be more accurate to say that I’ll have mini-goals that will move me towards my main objectives.
  3. They will be small, to the point that it will be easier to do them than to berate myself for not doing them.

So, let me first start by defining my objectives for 2016. I’ll choose two: one long-term objective that’s work-related, and one short-term objective that’s not.

Objective 1: Finish planning for my trip to Europe. I’m taking sabbatical in a few months, and I haven’t yet figured out where I’m going to stay or exactly what I’m going to do in London. Thus, the first things I need to do to meet this objective are:

  • Select and reserve a hotel.
  • Determine how to get from London to Stonehenge. Make any required reservations.
  • Buy Oyster passes so we can get around.

None of these individually should take much time, but none feel urgent either – the trip was scheduled half a year ago, but they remain undone. So, this coming week, I will have the following deadlines:

Monday: Narrow down my hotel selection to no more than three (I already know the section of London I want to be in) and get my wife’s preference.

Wednesday: Make the hotel reservations. Determine how to get from the hotel to Stonehenge and make reservations for that.

Friday: Determine the rest of our transportation needs (most likely, this will be Oyster passes to get around London and then Chunnel tickets to get to Paris) and make those reservations.

Once these are done, I’ll set new deadlines for other things I need to do, like figuring out how to keep my devices charged and whether I can pack clothes for two weeks in a carry-on. Now for the long-term goal: becoming a better programmer.

Objective 2: Improve my programming skills.

The problem with this objective is that it’s hard to measure; there’s no test that says “you are 85% of the way to being a rockstar programmer!” Instead, I want to implement a system that will have me doing things which will tend to increase my programming abilities.

1) I will attend at least 10 development meetups or conferences in 2016.

Until 2015, I’d never been to a development meetup. This is partially because it’s inconvenient to get anywhere from where I live, partially because I’m very hard of hearing and tend to avoid group activities, and partially out of inertia. In 2015, I attended That Conference and one meetup each from the MADdotNET and Madision Mobile .NET developers groups and enjoyed all three, so this year I’m going to try to make it a monthly thing. At some point in the future I’d like to start speaking, but I don’t know yet what I’d like to talk about.

2) I will start updating my blog again.

I started quite a few years ago, but I’ve never really been all that interested in blogging so I haven’t updated the site consistently. I’m going to start doing it regularly, for two reasons. First, explaining something is a great way to clarify your thoughts about it. Second, I’ll need to find things to write about; since the blog is going to have a software development focus, that means getting in-depth about lots of topics so I can write about them. For this goal, I’m going to say that I’ll spend a half hour working on the blog each week, and if a post is ready to go I’ll publish it. Further, I’ll publish at least two posts each month.

3) I will post at least one book review each month.

I’ve been posting reviews at Vulcan Ears Book Reviews since 2010, but never as much as I’d like, and I also don’t get as much reading time as I’d like; last year, I only posted two reviews. This year, I’m going to read and review at least one book (which may or may not be a technical book) each month; this will force me to stay on track with my reading, particularly since I have an easier time reviewing the type of book I should be reading (programming books) than the type of book I just read for fun (science fiction).

So those are my goals for the new year. They do sound a lot like resolutions, but have two advantages: they’re clear and specific, and they’re focused not on the end results, but on the concrete steps that I need to take to achieve my desired results. Next December, I won’t have a piece of paper that says I’m a 13% better programmer, but if I follow the plan, what I will have is more education and experience that will better equip me to meet whatever goals I might set in the future.