Lately I've been discussing blogs a bit more than usual, and a few coworkers have asked me what programming-related blogs I typically read. I can export all my feeds from Google Reader, but I'm finding that there are really just four blogs that have withstood the test of time and become my all-time favorites. Since these are blogs that I think any programmer should check out at least once, I thought I'd share them with you all, in the hopes that you'll find something new and enjoyable. Consider it the first installment of my "recommended reading" list for developers. Along the way, I'll try to give a good starter post for each one to give you a feel for each writer's style.
Joel on Software was the first programming blog I ever read regularly, and it's a testament to its consistent quality that it's still in my top four. I can't remember how I initially found it, but it was sometime in the middle of college, and after that, it became a large factor in my education. While we were learning algoritms, data structures, and other more code-focused topics in class, Joel wrote about almost everything else in software development: the roles of developers and managers on a team, the tools every development team needs in their environment, how to process bugs, interviewing developers, and much more. And not only is it informative, it's entertaining, too. Joel usually has some sort of personal anecdote or fictional story to help illustrate his point, and they're usually pretty funny.
Throughout the remainder of my college career, I scoured the Joel on Software archives, reading many of his best articles and learning a ton about the world of software development. When I went into a couple of internships and then started at Clarity, I could tell Joel had definitely prepared me. That's why I say that only half of my software development education came from my classes: the other half was Joel on Software.
As far as a representative post goes, Joel's made it easy on me. After a recent redesign of his site, many of his best works are listed right on the front page, separated into categories. If you still want a single post to start off with, though, I recommend The Development Abstraction Layer. I think it covers all the important points: an entertaining story, an explanation of the problem, and a point about software development that perhaps you hadn't heard before.
Coding Horror is a blog that I kept seeing pop up over and over again among the top articles on the programming reddit, and eventually I decided I'd just go ahead and subscribe to the feed. Jeff tends to focus a bit more on developer-centered topics: code organization, some hardware tips, etc. His posts are short, but he usually has a few each week, so there's still a lot to read - probably more than any of my other three favorites. To me, very few of his posts stand out as a great "Aha!" moment, but each one makes you view the topic in a slightly different light than you did before. You could almost think of it like a programmer's thought-of-the-day calendar. Chances are, no one post is going to change your career, but over time they build up and have a significant impact on the way you think about software development.
I don't know that there's any one great starter post for Coding Horror, but try
Spartan Programming, then just cruise around the archives a bit. Put it in your RSS feeds for a week or two, and see how it goes.
Rands also writes about software development, but focuses more on the managerial aspects, as well as how he generally keeps himself and his work organized. If anything, I'd say his distinguishing trait is that he loves Naming Things. He'll talk about the roles people have in meetings, such as Sally Synthesizer or The Anchor, describe his Morning Scrub and Parking Lot as parts of how he manages his day, and tell you about his affliction with Nerd Attention Deficit Disorder. It's silly, but it puts a name on a concept that was only vaguely-defined before, making it easier to discuss and reason about. In general, I think Rands helps you recognize patterns in your day and in your own thinking that you weren't quite aware of before, and helps you encourage or discourage them as appropriate. That really doesn't do his blog justice, and it's only a part of what he writes about, but primarily, that's how I think of Rands.
My favorite Rands post is easily
Free Electron, and I think it makes a good intro to his writing, as well. To someone who's been reading about software development for any significant amount of time, it covers some familiar territory along the lines of "some programmers are orders of magnitude better than others", but it's fleshed out in a great example, and is taken to more of an extreme than I've seen elsewhere. It's even inspiring in a "that's the kind of programmer I want to be" kind of way. Check it out.
Unlike the other three, I remember exactly when I found Steve Yegge: I was actually referred to him by
one of Joel Spolsky's posts. I started reading some of his "best of" posts, and I was hooked. His posts are typically more far-reaching and philosophical (much more so than the other three bloggers mentioned here), and put into words a lot of the problems I had thought about but was never quite able to express. He focuses a lot on programming languages, and being a bit of a language geek myself, it was a great fit for me. He's very blunt and in-your-face about a lot of his opinions, but he does it in a comical way, and he has some great insight. Also, his
Effective Emacs post, along with one or two others, was the reason I started using emacs. So if you're ever one of those people that comes over to my desk and asks "You use emacs? Really?", or the bewildered "Why the heck would you swap the Control and the Caps Lock keys?", that's why. Oh, and that's also why I'm writing this post in emacs right now.
There are actually two separate blogs: The one he started while at Amazon, which I linked to above, and
the new one since he started at Google. I think his best writing is on the old Amazon one, but you be the judge; there's good material on both. For a starter, read
The Five Essential Phone-Screen Questions. It's one of his more well-known posts, and it came up in a debate at lunch the other day, so I think it's a good read whether you agree with the idea or not. And one last note: some (or most) of his entries are
really long, so caveat emptor.
Some Thoughts
Having never thought in depth about these four blogs much before, I realize that they have more in common than I first thought. They're all practical to some degree, but each one has at least a bit of philosophy in it as well. Plus each of them is just a fun, enjoyable read, especially on their best days. Maybe that's just my taste, or maybe that's just what makes for great writing about programming.
So now that I've shared my favorites with you, what did you think? Did you enjoy these? Any important ones that I missed and should be reading? Let me know in the comments, and I hope I've given you at least a little bit of new enjoyable reading that you didn't have before.
I was reading an article recently that linked back to one of my favorite online essays: Peter Norvig's Teach Yourself Programming in Ten Years. In it, he talks about how in many fields (including programming), it normally takes about ten years of practice to reach the level of "expert". As I was reading through it once again, I realized that I started programming almost exactly ten years ago. That sounded like as good an excuse as any to reflect back on where I've been in my programming career, and where I'm going. Not to mention it seemed like a good way to introduce myself to the rest of the Internet, this being my first blog post and all.
The Early Years
Back in 8th grade, I started taking algebra, and the school recommended that each student buy a TI-83+ graphing calculator. In class, we used it for things like seeing how y = x is different from y = 2x; really exciting stuff. We all knew that the real excitement was in the programs (a.k.a. games) you could get just by downloading them from someone else over the link cable included with the calculator (sort of an in-school version of P2P, I guess).
I played the games for a little while, but then I started wondering about that "EDIT" option at the top of the programs menu. I cursored over to it, opened up one of the programs, and was suddenly presented with a screen of words, numbers, letters, and punctuation marks like I had never seen before. I knew that it somehow all made the game "go", but how? I scrolled down a bit, and suddenly recognized a bit of text: the title screen of the game! I created a new program, and after a bit of trial and error, figured out how to get that line of code into my new program. I ran it, and there it was: my first ever "Hello, world".
After that, I was hooked. I started messing around with the games I had, trying to get them to behave differently, and learning what these strange constructs like "If/Then" and "Goto" did. I loved figuring out this big puzzle piece by piece, and being able to make the programs do just about whatever I wanted. I even created my own game at one point: a tiny RPG called "COMBAT". It may not have done much, but gosh darn it, I was proud of it.
Later on, in high school, I borrowd a book on C++ from the library, since I had heard most video games were written in C++ (seriously, does anyone get into computer programming for any reason EXCEPT wanting to make video games?). I started to learn a few more complicated constructs than were available on my TI-83+, and made a halfway-decent command-line-based Minesweeper clone in the process. I was starting to learn what real programming was like: compiling, syntax errors, looking up functions, testing, debugging, and eventually, the sweet success of having it all work.
Formal Education, and Getting Paid to Write Code
I started college at Notre Dame in the engineering department, intending to major in computer science. In the spring of my freshman year, we were assigned to progam a simple animation of a few balls bouncing around in 2-D, with bonus points and a chance to demo your work to the rest of the class for those who added the best extras on top. Of course, still being in the video game mindset, I made what ended up being something like an Asteroids clone. As it turned out, that earned me the privilege to show off my work to everyone. I wasn't the first to do a demo, but I was the first to demo a game (or at least a proof of concept of one). Standing up in front of our 200+ person class, I started playing the game. After a few near misses, the on-screen bullet hit the target, the target disappeared, and suddenly there was a roar of cheers and applause from my classmates. I think that was the moment I knew I had found my profession.
As college went on, I did major in computer science, and I started learning much more about the formal knowledge and theory behind computer programming. We covered all the usual CS topics: data structures, algorithms, computer architecture (all the way down to logic gates and flip-flops), operating systems, compilers, etc. While I may have been frustrated by the teaching quality much of the time (sometimes warranted, sometimes not), looking back I realize that my knowledge grew by leaps and bounds during those years.
However, classes and homework made up only about half of my education during that time. The other half came when I discovered blogs, specifically Joel on Software. I'll cover this more in a later post, but suffice it to say that Joel's posts and his recommendation to read Code Complete comprised the vast majority of what I knew about coding and software engineering until I started programming in a full-time job, and even then it still took up a significant chunk.
During the summers while I was in college, I had two internships: the first one at a large telecommunications company, the second at a small consulting firm in the Chicago Loop. I got exposed to a lot of new technologies during those 16 weeks or so, but more importantly, I got exposed to what a full-time programming job is really like: working on large systems, programming on a team larger than the typical 3-person teams we had in school, fitting the new requirements into the current application, and much more.
In school, professors usually designed the projects so that you wouldn't run into anything too tricky in the code, and even if they didn't, the requirements were usually pretty loose so that you could implement a feature in a different way if you ran into problems. In the business world, that doesn't fly - your feature needs to be written as the requirements state, or it's not going to be of any use at all. The business doesn't care if it's not quite the perfectly-architected body of code you always envisioned; it just needs to work. To this day, I still struggle to just grit my teeth and deal with it when there's no other choice than to use some ugly hack to implement some feature or another (but I'm working on it).
The Working World
After graduation, I started here at Clarity. There are a lot of great programmers here, so I've had some really good mentors and peers to work with and learn from. So far it's been somewhat similar to my internships, in the sense of learning more about business and soft skills than specific technologies, but increased tenfold. For most of last year I was at a single client, primarily working on a large (~1 million lines of code) distributed application for a retail company. I think that the overall experience of working on that project really helped me grow from a programmer who just implemented a list of features to a person who sees the big picture of a project, understands what its purpose is in the larger context of the company, and does his best to fulfill that pupose as part of the team. Not to say that I was a selfish jerk or anything like that before that project, but I adapted my work and made suggestions more often to better fit the overall goal.
I think it was around last May or so that things really started to click for me, business-wise. For a while before that point, I had struggled with figuring out what my next step was supposed to be, or exactly how to phrase some e-mail or another. But suddenly it all started coming together, and each day just went smoothly, or at least as smoothly as a day in your typical software project gets. I even ran a few small meetings, and helped run a relatively large meeting with several higher-ups to figure out how to solve an issue that we had struggled with for a few weeks. It may not be much in the grand scheme of things, but considering all the planning and preparation I put in ahead of time, and the fact that the meeting went surprisingly well, I considered it a large step in my personal growth.
Looking back
So, ten years after those early days with the TI-83+ and COMBAT, do I consider myself an expert? Well, not quite. For one thing, the ten years that Peter Norvig talks about are ten years of constantly practicing your craft, not just ten years since you first encountered the field. In that sense, I'm at best about 5 years in, and realistically more like 3.
But more importantly, I don't know that I'll ever consider myself an expert. I'm always on a constant journey to improve myself, and I know that I'm not where I want to be yet. I do have a vision for my future, vague though it may be. I want to be able to solve any problem that comes my way, no matter how complex; to act as the go-to guy on all of my projects, and to generally have a significant impact on the world of computer technology. That's the dream, but even if I reach that point, I imagine that I still wouldn't think of myself as an expert - I'd just find a new problem to work on and consider myself an amateur at that, instead of an expert at what I'd already done. For better or worse, that's how I get better: set a goal, work hard and meet the goal, give myself a quick pat on the back, and repeat.
I think it's important now and then to look back on what you've done, and see what kind of progress you're making towards your long term, or even lifelong, goals. I suppose that's another reason I decided to write this post. So now that I've taken a long look back at my personal history, where do I stand today? Let's take a look:
- I'm familiar with many different technologies: programming languages (C, Scheme, C#, Ruby to name a few), databases, web programming, XML, networks, parts of compilers, a bit of distributed systems, and probably more that I'm forgetting.
- I understand the concepts and theories behind these technologies, largely from my CS education, and partially from just using them and reading about them to find out what they're good for.
- I've come a long way in the so-called "soft skills": dealing with people instead of bits, and being able to better serve the bigger-picture needs of a project.
- I've worked on 5 different projects used in the real world, and the 6th is soon to be deployed.
Not too shabby for just being a couple years into a full-time job (plus a couple of internships). So now that I know where I've been, the next logical question is, where am I going?
- There are always new technologies to learn, and of course more coming out every year. Specifically right now, I'd like to learn about/experiment with automated unit testing, MVC, different data access models, and more on distributed systems.
- My soft skills could use some work in various areas as well. In particular, there are times I'd like to be more assertive, and eventually I'd like to be able to give public presentations more confidently.
- I really want to establish a more public presence on the web and build a reputation outside of just Clarity and our clients. They're great to work with day to day, don't get me wrong. But if I really want to have some sort of influence and make a significant positive impact on the world of computer programing, this seems like a prerequisite. Obviously this blog is a step in that direction, and I'm eventually going to get more involved in open source, as well.
My ambitions may be a bit fuzzy right now, but at the end of it all, there is one thing I know for sure: I absolutely want to be involved in computer programming, in some form or another, for as long as I live.
Now, if you'll excuse me, I believe my TI-83+ and I have some catching up to do.