The 3 D's of Software Development
The more I study Computer Science, the more I realize how terrible I am at it. There’s so many avenues of learning and growth, and the field is so deep and wide, no one can ever learn every language, every framework, every application, or every process. It’s hard to know in which direction to go, but one thing is for certain: if you don’t go, you’ll be left behind. I’d like to uncover a few roadblocks I have identified which serve as artificial barriers to the advancement of my development knowledge and career. Conveniently, they all can be mapped to D-words, and as such, my quippy title: The 3 D’s of Software Development.
Dread
The hardest part of most jobs is getting started. I like to think of myself as a self-starter, but a lot of times I’m just a big fat procrastinator head. For one reason or another, I have some reservation, some dread, at staring at a blank screen or blank piece of paper, or whatever the prelude to a development project big or small may be. Starting a project is scary stuff. I find that I’m afraid of taking a misstep, making a mistake, or creating something I’m not proud of. It probably seems silly, but it’s a real problem for me.
Going through my Software Engineering I course gave me a big boost in this area. Also of great help is Steve McConnell’s fantabulous book, Code Complete, which I’m about halfway through reading, but taking small chips out of every night. It’s a real comfort to know I’m learning the proper processes and best practices for developing software. It inspires confidence that I won’t take that misstep or make [as many] mistakes, and I’m more likely to create the application I envision — one I’m sure to be proud of. And really, that’s what it’s all about for me — creating something I can be proud of. I believe software development really is a craft, or an art, as much as it is a science. The best designs and applications are beautiful in their intuitive simplicity.
Perhaps the most important tool for overcoming dread in software engineering is the old standby, iteration_. It’s OK to make mistakes, especially early on, and it’s probably even encouraged. The sooner you foul up, the less effort you’ve put in, and the easier it is to correct. Iteration tells me I should screw up a time or two, or I’m probably not arriving at the best design or solution that I could be. Iteration is a software developer’s bread and butter. Don’t Repeat Yourselfyourself in your final code, but you probably have to repeat yourself by iterating a few times to get to that point.
It’s my new mantra: Iterate, iterate, iterate. And then iterate some more. It applies to every step in developing software, and it quashes the dread by allowing and encouraging mistakes (and what better way to learn?) on the road to the best solution.
Distraction
One of the foremost hindrances to my progress is procrastination. I’m constantly finding things to distract me from working on a project. They’re not necessarily bad things or wastes of time, and quite often and to the contrary, I’m doing something productive (college work, yard work, reading, writing) — it’s just momentum in the wrong direction.
Probably the biggest chunk of my distracted time spent not developing is, ironically, reading about development. The biggest offender of all is Google Reader — an online RSS feed reader application. I spend a large portion of my day keeping up with my favorite blogs and websites and reading about trends in software development (and startup companies, among other things) at Hacker News. I probably pass 300-500 posts a day through Reader, and while I believe it’s a blessing to be able to have so much of my favorite information on tap in one place, it’s my biggest source of distraction. I need to lay off the feeds, stop sweating the urge to process that huge list of unread items, and just check in once in a while — in my downtime when I don’t have something else I should be doing. It’s a tough thing to make myself do, since I feel it’s important to keep one’s thumb on the pulse of the industry, but I simply must cut back. I just won’t get anything done otherwise.
One other distraction I’d like to mention — the one hit after I put Google Reader down — is code. How the heck is the code a distraction? Isn’t it the most important part? To answer the latter, in short: No. To answer both questions in detail, the code is not the most important part — it is perhaps the least important part. Code is a distraction to the design process. I heard a tale not long ago (can’t seem to find the link now) where a group of people with no programming skill won a software design competition just by mocking up an interface design on Powerpoint, iterating on the design a few times, and then polishing up their best solution — all the while, the other teams were mapping program features to elements of code and trying to implement before they had ever really fully understood the problem. I didn’t realize what a problem it can be writing code in your mind, pointing out classes and making mental notes about how you might implement a feature along the way while you are still in the design stages. It clogs up the creative pipes and imposes artificial limitations on your design. Coding is almost an afterthought in the full scope of software development — even though it may be the most work-intensive and time consuming step. While you’re designing, strive to put the code completely out of mind.
Desire
What do you want to do with your career? What do you want to learn? What do you want to accomplish? These are all desire elements of development, and I spend a great deal of time pondering on them.
I’ve been itching to learn a new language, but I can’t decide which one to choose. I try to be forward-thinking without jumping on a bandwagon that’s destined to crash and burn. Node.js is booming right now, but one wonders at its staying power (I’m not experienced enough to make a call like that, and I’m sure the experts would all disagree). Clojure is also becoming prominent. Python and Ruby both seem like good routes to take for the web and each have large, dedicated, and enthusiastic followings.
What about shifting my paradigm? I’ve only really coded much in PHP, JavaScript, and Java. They’re all fairly similar languages, with object-oriented characteristics. Maybe I should learn Clojure or Haskell and look at computer science through functional programming glasses for a time? Would that give me a new perspective, or just fog things up?
Do I want to work for a big consulting firm? Do I want to start my own local development business? Perhaps I could make it as a lone-wolf, with several web or mobile apps trickling in small profits, or as a free-lance web developer. Perhaps all of those things (maybe not at the same time, and/or provided big consulting firm doesn’t own my weekend code, as some do).
There’s a long list of wants in a person’s career, just as their are in everyday life. Filtering out the fluff to get to the truly important things is no easy task. As such, the jury is still out on my development desires, but I’ve got plenty of time to try some things and figure it out. Perhaps I should iterate on a few different paths and see where they take me. *chuckle* (My apologies for that.)
Conclusion
If you haven’t noticed, all 3 of the D’s are pretty closely related. Desire has heavy elements of distraction and a bit of dread woven in. Dread is also a source of distraction, and distraction is often the product of dread or desire. All of these things pretty much center around emotion, and when you think about it, it’s funny how emotion can play any role at all in Computer Science — an area of supreme logic, structured procedures, and rational thinking. The human element knows no bounds, I suppose.
It’s my belief that recognizing these barriers to forward movement empowers me to avoid them. Now I can look where I want to go, instead of focusing on the obstacles — and in my experiences, you pretty much go where you’re looking. And with that, I think it’s time to go — I’ve got some development to do!