The Passionate Programmer: Creating a Remarkable Career in Software Development
Chad Fowler

The Gist

This book tells the story of Chad Fowler (no relation to Martin Fowler). Fowler got himself into a software development slump and was able to turn it around and rejuvinate his passion for his career. Much of the book revolves around how to keep oneself engaged with one’s work and how to determine when it’s time to shake things up.

My Feelings

I read this book in Summer 2012 and did a mediocre write-up on my old blog, so I’ve decided to quickly redo the write-up from scratch using my new format.

What Fowler talks about in his book is exactly what I was afraid of when looking for a job last fall: getting stuck. It’s easy to do: many employers are looking for employees who are willing to work on projects throughout their entire lifespan, which may be 12 months, 5 years or in some cases the lifespan of the company.

Personal story time. I was offered a job at an Indianapolis company with many long-term projects. One of my interviewers had been working on his current project for 5 years, and was trying desparately to get out of it. However, based on his seniority and domain knowledge of the project, he was told it would be at least another 6 months before he could move on. The developer was miserable working his current job and had no exit routes available to him, which scared me quite a bit.

Fowler’s methods don’t describe how to avoid this situation. They describe how to keep yourself happy by learning new technology and branching away from your “domain knowledge” while still remaining the go-to guy on your current project. Showing an interest in doing things outside of your current project should show an employer that you’re capable of more, and that you’re more than willing to do something new.

Fowler also talks about moving jobs if you’re unhappy, noting that the new world of software development doesn’t offer all the bells and whistles that it used to. Although I agree that you should try to find a new job if you’re unhappy, it’s not always as easy to pack up your things and move as the author makes it seem.

The coolest parts of the book were the personal stories of several high-tech big-wigs. The silliest parts were the ‘Act On It’ sections. The ‘Act On It’ sections described how to implement some of the methods detailed in the book, but they often seemed obvious and unnecessary to me.

Who Would Like This

This book can offer a lot to someone who wants to revitalize their career after getting in a rut. It may also be able to serve as a guide to preventing yourself from getting in a rut. As a recent college grad with many of my dreams still alive, I only found a moderate amount of honey in this beehive. An interesting read, but maybe not entirely relevant to fresh faces.

How Linux Works: Things Every Superuser Should Know
Brian Ward

The Gist

Linux is a complicated operating system which gives its users the freedom to do anything. This book details things that any Linux superuser should be aware of, including printing, networking, scripting, compiling source code, setting up users, and buying hardware.

My Feelings

I’ve been running Ubuntu as the only operating system on my home computer since the 11.04 Natty Narwhal release in 2011, and I’ve been using Ubuntu in varying degrees since 9.04 Lucid Lynx. I’ve also recently ported my wife’s computer over to Ubuntu after she finally got fed up with Linux. There is a course at Purdue called ECE364 that taught us lots of cool Linux commands which I had forgotten, so I’ve been looking for a good refresher. This book helped jog my memory of things like grep, sed, and awk. The book also provided lots of information on things that I’d been using for years without really realizing what I was doing.

This book was written in 2004, which was a long time ago in the computing world. In 2004, Ubuntu Linux (the most popular personal desktop Linux distribution) was released. Ward makes mentions of setting up network interfaces, firewalls, and printers through the terminal, which are all things that now are either done automatically by most operating systems or at a minimum have a GUI to support setup. Ward also mentions that CRT monitors are on the cheap, but if you want the best resolution an LCD monitor is the new cool thang. He talks about Pentium processors, half gigabytes of DDR, and slow, heavy laptops. Be warned that you won’t find anything in this book about 64-bit processors, SSDs, or cloud computing.

Most of the book is still very relevant. As mentioned previously, I got a lot of benefit from reading the section on common commands. The section on setting up dot-files was also extremely useful for me. There was also a lot of interesting information about the Linux filesystem being databases that I had never really thought about before.

Who Would Like This

Those new to Linux or those needing a refresher would benefit from scanning this book, at least the interesting sections. This book is not for people looking for bleeding-edge information on their new hardware or software. The reader can get a large amount of information that has aged well and will continue to be relevant for Linux users for years to come.

Meet Anne. Anne’s a programmer in a thriving tech company. Anne goes into work every day to work on a shiny new product for her company.

Anne’s customer knows exactly what they want. Anne writes all of her tests using pure TDD. Anne updates her tasks on the company’s ALM software, which was defined with programmers in mind and not just managers. She knows everything about her domain, and every UI element she touches is the epitome of good user experience. She works with 100 other programmers, each of which is equally as skilled as she is. Every time she pushes her most recent file changes, there are no merge conflicts and the build server works without a hitch. The deadline for the project is defined as whenever the last feature is finished. The best part: Anne spends fewer than an hour a week in meetings, none of which is a complete waste of time.

You’ve got to be kidding me.

If I experienced a day like I just described for Anne, I would have to assume I had been killed in a tragic car accident on my way into work.

How can a programmer possibly be optimistic? Let me say: The client never knows what they want. The programmer couldn’t possibly write all of their tests TDD style unless they’re a saint. ALM software has a tendency to suck. Programmers don’t have the inherent ability to know precisely how a user will try to use the product. Oftentimes your teammates may not be on the same level as you are, or you may not be on as high a level as they are. There are always merge conflicts and build server anomalies. ‘Random’ is generally an apt description of project deadlines. Lastly, we spend lots of times in meetings which often don’t appear to provide much face value. Those are the facts of life.

If we’re optimists, why would we bother writing tests for anything beyond happy-path? How could we ever justify refactoring if we’re optimistic that we did it right the first time? Why bother putting in security if no one will ever try to use their 1337 hax to get to the client’s data? It’s important that we stay planted firmly in reality to ensure we think of most everything that can go wrong when a customer uses a product.

I’m not saying there aren’t optimistic moments in a programmer’s life. Phrases like “I’m optimistic the project will end some day” and “I’m pretty sure the customer will like this” and “I highly doubt we’ll get sued for that” are phrases that I’d feel inclined to throw around most any time to raise the morale of my companions.

There is a general, unnamed rule when coming up with ideas:

A person is required to have one or more bad ideas before having a single good idea.

Since this rule is unnamed, it shall henceforth be referred to as Larry’s Law.

Note that the thinker in question is not limited to just one bad idea under Larry’s Law, but as many as he so desires. Also note that Larry’s Law does not imply that the thinker will necessarily ever have any good ideas.

Having bad ideas is necessary. Bad ideas let the brain see what it shouldn’t be thinking about, which has the potential to lead to good ideas. Then again, many bad ideas may just spawn more bad ideas. That’s just Larry’s Law.

Examples

You sit down at your desk and pick up a bug. Your first idea doesn’t fix the code. Your second idea doesn’t compile. Your third idea breaks all 3400 unit tests in the test suite. Your fourth idea is a complete hack. Your fifth idea breaks some other component of the application. Your sixth idea seems genius to you but doesn’t survive the code review. Your seventh idea is a winner.

Before Edison could invent the Universal Stock Ticker, he had to invent a crummy vote recorder.

Do you have any idea the number of albums Pink Floyd released before The Dark Side of the Moon? Seven. Don’t kid yourself: these seven albums were not gems. But don’t fret! Larry’s Law states that these albums had to be low quality to allow The Dark Side of the Moon to be a monumental album.

Someone invented New Coke. This is an instance of someone making a bad decision without any corresponding good decisions.

Domino’s pizza was terrible until very recently. Now it’s delicious, at least according to this man on Yahoo! Answers.

A group of people wants to go out to eat. Jon Doe will suggest Jimmy John’s, then Penn Station, McDonald’s, Five Guys, Taco Bell, and Denny’s. Finally Jon Doe offers a reasonable idea, like YATS. This process will now be repeated by every person in the group, and the best decision will never become visible. And Larry’s Law specifies that the group may never come to a good decision, and will probably end up eating at Five Guys.

Conclusion

The next time you have a bad idea, embrace it. Realize that having that bad idea might clear space in your head for a good idea. Or possibly an infinite number of bad ideas. Either way, that’s just Larry’s Law.

“Wanna go for a walk?” my wife asks over my shoulder.

“I don’t have time for your walks, woman! I’ve got a city to run!” I exclaim as I frantically move the mouse around the screen to raise taxes on the rich so I can afford to build another statue of myself in the blossoming city of Velcro. I’d been absolutely engulfed in the popular city simulator SimCity 4 for about five hours already that day. Needless to say, my wife “convinced” me to hit the pause button on the game and join her back in reality, where I’m a software developer who has to go on walks to counter his poor eating habits.

We take time too seriously.

When we feel like we don’t have enough time, we complain. When we feel like we have too much time, we think we’re bored, and so we complain about that.

Maybe if we spent less time complaining, we’d have time to see how ridiculous we are.

Time is time. What’s there is there, and we’re not getting any more or less of it based on what we get accomplished in a given day.

…Unless of course what you accomplish is manipulating time in some manner. Or you create a serum to slow/expediate/stop the aging process. But those are side projects to talk about in another blog post on another day.

Back to SimCity 4. After I rediscovered the dusty game disc at my parents' house, the game completely absorbed me, even 10 years after it was originally released (my computer is finally powerful enough to play it). I didn’t mind that it was taking up so much of my time. I had a myriad of more conventional things I wanted to do that weekend: side projects to work on, books to read, TV shows to watch, internets to check, housework to do, groceries to buy, and meals to cook; but none of that mattered.

I repeat: none of that important-sounding stuff mattered. I had stumbled upon this completely arbitrary childhood memory to relive, so everything else took a back seat. I don’t regret all the hours I ended up spending on that game, as a kid or as an adult. A compulsive opportunity arose to have some fun and I snatched it up. I stopped worrying about time and decided to just enjoy myself. You should try it sometime. We spend way too much of our time trying to abide by our schedules and to-do lists. The best parts of life are when you stumble upon something that makes you completely forget what you were doing before you found it, and then continues to obliterate any plans you might have had for the rest of the day.

Now if you’ll excuse me, I have a city to run.