Doin’ the Blog

Doin’ the Blog

1 January 1970

Coding my own blog seemed to be an interesting challenge. I took it on to be able to post one simple message to my website. I have a (very irregular) journal on last.fm but my last real (non-music-related) blog entry dates back a few years (and was posted on my plain-HTML-based blog I had on my old non-server-side-scripting-driven website for which I even hand-coded an RSS-“Feed”) so it was also a matter of pride to be “in the scene” again (of course, being most likely the only one to have an HTML-only blog was also my pride… back when).

Creating the first working version took some discipline but less time than I’d anticipated; I had it working in half a day. Adding a Captcha to the comment posting form took two hours and coding the RSS feed took a measly half hour.

This really showed me how much the tools I have at hand matter. When it comes down to estimating the time spent coding, the only tasks I regularly over-estimate are the ones where I’m working on Mini-CMS. As it happens, my website also runs on Mini-CMS and so now my blog does too. I don’t want to make the case that coding in Mini-CMS is far more efficient than doing stuff in Rails or that PHP is a better language than Ruby; far from it, actually. But for me, it is. And that’s because I know Mini-CMS inside and out unlike any other framework I could possibly be working with. I’m sure if I were a regular Rails coder, I’d say the same thing about Rails.

I’m thinking of days at work where I could hardly work on anything. Not because I wasn’t skilled but because the Framework I had to use was unknown to me or just a pain in the ass to use. I hate working under such conditions: coding becomes guesswork, interrupted only by numerous tedious look-ups of manuals and help files. Sometimes, however, that isn’t even the worst part: being held back by frameworks that require me to use a certain (slow) tool (which most of the time only works on Windows) instead of the one I choose to work with; unreasonably high caching values which leave you in the cold whether it’s still the old cached behaviour I’m seeing or if my modifications were wrong; test environments that require you to go through a lengthy rollout process by which all the session data gets lost instead of being able to instantly see changes like I can do with PHP and some well-set-up J2EE environments — all these things slow down my coding considerably. But what is far worse: they make me mad, nervous and – as a consequence – demotivate me. The demotivation itself is the single gravest factor in my slowdown.

I always thought I was atypical in this regard: that I’m the only one who is so demotivated by bad working conditions that I slowed down additionally and artificially as a result of the environmentally-imposed slowdown. But what if I ain’t? What if the single most significant boost in productiveness you can get coders to ever achieve will be when you start using frameworks which allow them to use the tools they like to use, code the way they like to code and work at the pace they like to work?


Comments are moderated.

Add a comment