Just Say No

Another heated and high pressure meeting and this time it is to “discuss” how best to “bring back on track” the head line project, the deadline which has already long since past. Sounds all too familiar? I would like to say that late projects can happen in any line of work. While this is true, it appears software development seems all too prone to it. How did we end up here?

Mountains of Abstraction

As part of my journey to distance myself from Microsoft et al and to the free pastures of open source development. During an uninstall I couldn’t help notice the gigantic size of Visual Studio 2008. I do not recall the exact number, but suffice to say it was possibly a Gigabyte or more; slight feeling of unease came over me. Does an IDE really need to be this big? To conclude that an IDE is nothing more than a glorified text editor would be both harsh and a slight exaggeration.

Breaking The Webs Golden Rule

The web is an amazing platform, its “design” if you can call it that is ever changing. The web works because it is “field tested” every day by millions of people. That which does not work is simply not used and that which works well spreads like wildfire. The end user devices are diverse and with web platform growth it is no surprise that it has become one massive hack balanced on top of another hack.

Magic Numbers and Being Naughty

Another week in development at a finance company, the cyclic experience of which many developers will probably recognise. An endless list of requirements along with project hopping and finally a side sprinkle of meetings to top it all off. Sometimes in this manic loop the condition is broken with something that makes you smile a little. Last week a funny little thing happened and I wanted to share.  Curious metrics

How the tables have turned

I’m in the middle of migrating most of my home PC’s and laptops over to Ubuntu. Which is why reading a blog post by David Drake’s entitled “25 Years to Mac – How Ubuntu Pushed Me Away from the PC” got me raising my hand to respond. The first thing I have to admit is that David certainly has some valid points, however I think he is an edge case thus perhaps not a fair representation of the experiences of most users.

Job Titles In IT

Footnote: I’ve been meaning to post some new articles for a long while now. My last post was a few months ago. Although I have a few incomplete articles in the works, being demotivated does not help. We was discussing job titles in IT, and seemed quite apt so I thought I would share it. Hopefully with this post I can kick start my own motivation! Extra note: Clearly this is does not apply to all Job Titles :)

Logout before you burnout

Burnout amongst software engineers is a real danger. Years ago when I had first heard about burnout I brushed it off as a myth. After seeing it first hand and experiencing a little burnout myself, I can attest it is indeed real. Software engineering demands a high level of concentration. Debugging software and troubleshooting complex problems are mentally taxing. It is in the nature of most developers that we tend to fixate on a particular problem until it is resolved.

I don’t just refuse, I don’t tolerate a-holes fullstop

The post by Jacob Kaplin, entitled I refuse to tolerate **holes (19th may 2012). Caught my attention. After reading Jacob’s post, it struck a chord with me. Without a doubt the type of behaviour described does indeed exist. The strange thing is that, this type of behaviour is not acceptable in any other profession. So why is it that this kind of egotistical attitude be accepted in software engineering?

Why do we communicate better with computers than with people?

Ask us programmers our skill set and we can confidently iterate them. When required to document our skill set such as in a Curriculum Vitae (resume). We can objectively list them along with meta data about language competence. That’s great! nothing wrong with this, that is if communication with computers are the focus. Software development does not occur in isolation, it occurs between other people. Some of those people happen to be programmers like us.

please don’t learn to code but give it a try

This post is a response to Jeff Attwoods post Please don’t learn to code (15th may 2012). I agree with 90% of this post, but I wanted to present a slight twist: I whole heartledly agree with Jeff when he say’s that its nonsensical that “every-one should learn to program”. Jeff offers an analogy about plumbing and he is correct in this regard. However I will need to re-visit this analogy later.