I started my new job at Amazon three weeks ago, working on Elastic Compute Cloud.
In order to help learn the product I’ve just moved my blog (and a few other things) over to an EC2 instance. The instance is in the new US West region and is using the new Boot from EBS feature. I’ve also created a large EBS image for backing up files from my Macbook. Both of these EBS images can easily be backed up to S3 via the snapshot feature and, most importantly, it is very easy to restore from a snapshots to a new running instance (so many backup mechanisms handle restore poorly).
Long story short: the stuff I’m going to be working on is pretty neat.
I had a couple job interviews last week and it started me thinking about two different types of programming:
1. day to day stuff
2. puzzles
Day to day stuff includes writing a simple function within an existing program, refactoring code, figuring out why your program spews a nasty error every third time it starts up, writing simple tests to make sure that annoying bug that you promised QA was fixed 3 times doesn’t come back, etc.
Puzzles are the difficult problems that everyone associates with programming. They require intense focus, tons of brain power, scribbling notes on a pad of paper, etc. They’ll generally require long periods of “sleeping on it” – that is, taking lots of time while your brain sorts through solutions in the background. Puzzle problems are very popular during interviews.
I’ve gotten very good at the day to day stuff over the past 10 years. It is what you spend most of your time doing as a professional programmer. It is very linear – a bunch of small improvements that slowly make the program better. It isn’t terribly exciting but it should be satisfying if you truly believe your goal is to ship working software. Surprisingly, not all developers have that goal, but that is a story for a different post.
Puzzle questions don’t consume much of a programmers time. My guess would be that we spend less than 5% of our time actually working on the kinds of problems that people ask during interviews. It’s for this reason that I’ve become bitter about them over the years. To summarize my oft-repeated rant, who cares if a programmer needs a bit more time to write that complex algorithm if the difference is a matter of days over the course of a 6 month release cycle? Shouldn’t we care more about how likely they are to get out of their chair and ask a tester how to reproduce a bug, or one of the other countless things that programmers spend most of their time doing… or not doing as much as they should.
(if only there was a way to figure that out during the interview process)
However, this round of interviews has changed my tune a bit. I’ve grown a bit complacent due to my success with the day to day stuff and my bitterness about the puzzle mindset. There are people out there trying to solve interesting problems that require more complex algorithms. They do spend more than 5% of their time on these difficult problems. It certainly wouldn’t hurt me to keep my puzzle skills sharpened. So I’m thinking of trying my hand at some programming puzzles once in a while. Perhaps instead of wasting time playing Sudoku or Desktop Tower Defense.
I’m having a difficult time getting through the middle of my first novel. It is very short on character development, setting, and plot. The only thing it has too much of is dry technical descriptions. Not good.
I’ll probably do LoNoWriMo next month.
I bought a book on Xcode last night and had fun working through the examples until 2am. It is the first time in a while that programming has seemed really fun. Perhaps that is what I’ll be doing next.