Tag Archives: developers

Dump of a few interesting Coding Horror posts

I could spend hours delving through the archives of Jeff Atwood’s Coding Horror blog, but there are only so many hours in the day. Here are a few bookmarked posts I wanted to post links to for posterity.


Programmer comfort


Steve Yegge blog posts

I’ve recently been browsing some of Steve Yegge’s (lengthy) blog posts, something I’ve been meaning to do since I found out about him after his platforms rant. Here are a few that I found interesting.

Singleton Considered Stupid – when you use singletons, what you’re often actually doing is forgetting all about OO programming, and simply use classes as namespaces.

Google’s Secret Weapon – how Google was winning the smart people recruiting game back in 2004 (and probably still is).

Being the Averageist – why programmers don’t know how competent they are (we can’t measure it), why most don’t bother trying to improve (lack of incentive, or a company culture), and many other things.

Practicing Programming – how your day job isn’t real practice that’ll improve your skills, why you need to learn/practice, and what sort of practice you should do.

Nine Things Developers Want More Than Money

Came across this good post from a while ago by Rob Walling about Nine Things Developers Want More Than Money.

A few points I noted, or reminded me of things I’ve seen:

  • Developers want to build software that they can take pride in. Management often only want them to build the minimal thing that’ll work.
  • “Being forced to build crap is one of the worst things you can do to a craftsman”, and it feels like a failure even if you do it on time
  • Developers want to learn new things and be challenged, in order to be happy.
  • We want to work on the right kind of challenges. Not, for example (my own one here), spending months trying to sort out crappy software someone else wrote.
  • We need to be listened to, and where needed actions need to be taken based on what we say. The build is slow, we need faster machines.
  • We want to build things that matter. My own example, not some obscure counter-intuitive feature that we know will never get used.
  • We don’t like being tied down by poor legacy systems we have to accommodate and work with.