Blogifesto

I feel like I arrived in the field of software engineering at the twilight of an era.

Let me explain: I arrived on the job market not too many years ago, with an electrical engineering degree and only haziest notion of what I wanted to do with it. Through college, I had hedged my bets. I loved programming and made sure to take computer science classes, but I thought that it might keep more doors open for me to have a degree with the word "engineer" in it. I could just as easily have imagined myself going into a career designing Printed Circuit Boards. I also got a minor in Technical Japanese. If anything, I had a vague notion that I might end up as an embedded systems programmer with ties to Japan, or something like that. I'm not sure exactly when the change happened, but within the course of a few years and a few jobs, I discovered that not only was the demand for software engineers huge, but I loved the work and wanted to make my career in it.

So I had some catching up to do.

Compared to my college peers who majored in Computer Science or Computer Engineering, I was tragically under-educated and under-experienced. I never really had a "mentor" in the ways of programming; All this was during the deepest depths of the recession, and I think the kind of organization which was concerned about mentorship instead of just surviving until next year had their pick of candidates with better qualifications. Instead, I owe most of my knowledge, indeed, the means with which I was able to segue into a new career, to two sets of resources: Online classes and Blogs.

Online classes deserve a whole post of their own. I want to talk about blogs for today.

The typical software blog follows a sort of tutorial format, with articles names like "Intro to Databinding in ASP.net MVC" or "New Features in C++ 11". Blogs like that are awesome too, particularly if I'm having trouble with databinding in ASP.net MVC. But they have limits. As valuable as a tutorial on configuring Git is, what was infinitely more valuable to me was an article discussing the philosophical differences between Centralized (SVN, TFS) and Distributed (Git, Mercurial) Version Control. Most of those fundamental questions don't have cut-and-dried "answers", so the only way to become literate in them is to follow the whole conversation around them. I think this applies to almost any difficult-to-understand concept: by the time I can boil my issue down to a coherent, answerable question, I'm already 90% of the way to finding an answer. Thus, where I get stuck is rarely "How do I do databinding in ASP.net MVC". It is usually "I've got a bunch of info in a database, and I need to display it and allow it to be modified through this fairly complicated web page..... somehow. What are some potential approaches for doing that? Best practices? I'm heard of ASP.net MVC databinding and I bet it might be useful here, but what are the pluses and minuses compared to other potential solutions?"

I'm going to name some names here: Steve Yegge. Joel Spolsky. Jeff Atwood. Scott Hanselman. Martin Fowler. Rob Conery. I doubt any of you guys will ever read this, but if you do, I want to send you a big thank you right now. The second-hand experience from reading through the archives of your blogs helped launch my career. Through your opinionated, articulate rants, you gave me the first notion of an understanding to a set of questions I wouldn't even have known how ask:

  • What is this "Function Programming" stuff, and why is it important? How about Lisp?
  • How much should I comment my code?
  • What are some good general practices? SOLID? DRY? Unit Testing? Composition over Inheritence? What do those even mean?
  • Where can I go to learn more?
  • There's a lot of Crappy books on software out there (1,200 page Sam's teach yourself XML in 21 days for Dummies). Which ones are the classics of our field, which are really worth reading?
  • Which topics are really important, so that its worth investing months or years in figuring them out?
  • What are some of the long-running conversations which have shaped our collective communal attitudes on how we do our jobs?
  • What are the problems facing our industry?
    • Which problems are new?
    • Which ones have been with us since the 60's, and may always be with us?
    • Which problems from the 60's have been effectively solved with better tooling or methods?
    • What are these all of these methodologies anyway (Scrum, Agile, TDD, BDD, DDD)? Are they a big deal? What sort of benefits do they produce? Are they all basically the same?
  • Tools!
    • There are so many programming languages out there! Which ones should I learn?
    • People are always getting excited about "The Next Big Thing", be it Java, Ruby, NoSQL, Node. Do they justify the hype? Are they worth learning even if they don't?
    • How about Data? We've got Stored Procedures, all sorts of different ORMs, NoSQL.... What's the difference? Do you even need a database, or is it enough to use something like ViewState?
    • What's this whole vi/emacs thing
    • Is Microsoft really evil? What are the advantages and disadvantages of working in a Microsoft ecosystem?
  • How can I manage a career in software?
    • What frustrations am I going to find virtually anywhere I work, and which ones really shouldn't be tolerated?
    • Looking forward, what are some topics I should be learning to keep my skills cutting edge?
    • What does a healthy software project look like? An unhealthy one?

But, we seem to live in an era when many of the great blogs have gone quiet. The authors either formally shut their blogs down, or scaled them back to a post every few months, and it doesn't seem like new blogs have risen to take their place (Except Erik Dietrich is really good). I can't say why this happened. Maybe these luminaries were part of the heady days when the blogosphere was young, and now the world of blogging has reached a cooler steady state. Maybe all the great voices have moved on to Twitter. Maybe everything has been said already.

Do I expect to equal these visionaries of the past? Pffffff. Not a chance. But I suppose I'm trying to pay forward in small way the benefit that these folks gave to my career. That, and maybe provide a little insight or entertainment while you check your email in the morning. There's something in it for me too. I like writing, and I think being able to write well is a superbly valuable skill for an engineer. And writing is one of those things which can only be learned through practice.

So, here's what to expect: I'm going to try to write an interesting article at least once per month, and hopefully more. A majority of the posts will probably be about technology, but there will also be random musings, commentary, and pontificating about whatever is interesting to me.

Enjoy! And look for a few more posts in the coming weeks!