Comments on: Survival Skills for Developers

By: Survival Skills for Developers | drorhelper

Survival Skills for Developers | drorhelper — Mon, 06 Dec 2010 07:33:02 +0000

[...] I’ve talked about this post during the recording of the latest This Week In Testing episode (soon to be available). It is well written post by the blog owner – Derek Hatchar that explains his take of the skill a developer need to have in order to survive in this highly competitive work – read it here. [...]

By: George

George — Sat, 26 Jun 2010 08:01:29 +0000

The point you raised is very relevant, but I’ve found that most good developers have implemented all your suggestion as a matter of course, without any song and dance. I always drum into whoever will listen that “You should never write the same code twice”. If that means keeping a library of methods/functions/subroutines call them what you will, then so be it. However, as I’ve found, a lot of developers do keep such a library, but only the really good ones actually use it.

By: Yuck, I Got Data on my Hands--Ardent Dev

Yuck, I Got Data on my Hands--Ardent Dev — Wed, 24 Feb 2010 12:46:48 +0000

[...] And then we complain about how much data access code we have to write and maintain. In Survival Skills for Developers, the first item for your basic survival pack is a data access toolkit (homegrown or open source or [...]

By: Survival Skills for Developers - Helper Code

Survival Skills for Developers - Helper Code — Sat, 20 Feb 2010 20:11:34 +0000

By: Sean

Sean — Mon, 15 Feb 2010 15:47:40 +0000

I agree with all of these.

I would classify regular expressions as a tool along the lines of a flare gun (to keep with the camping analogy). Not needed often, a lifesaver when it is, and dangerous in the hands of someone who doesn’t know what they are doing.

Also missing from the list is documentation. (the map in this camping analogy). This ties in with communication mentioned by JB King. Writing good user or developer documentation for systems you work on can be the difference between something being indispensable and something causing confusion and requiring more support (especially for applications that will be used by less technically inclined users).

Even for systems designed to be used by IT staff, documentation makes the difference between spending an hour wading through code or just 5 minutes looking up a documented process to figure out what an old system is and what it is supposed to do (and thus freeing up the other 55 minutes to figuring out what is broken and how to fix it).

By: JB King

JB King — Wed, 10 Feb 2010 16:28:07 +0000

Bug tracking and learning a methodology got left out. The latter is important to note for those that want wherever they work to move on up the Joel Test. Whether a place uses Agile or Waterfall, it is important to know what kind of alphabet soup can be applied to where one works.

Bug tracking is kind of an off-shoot of unit testing in a sense, but the point here is to know what are some of the basics when looking at a bug and knowing how to spot a well-written bug compared to a “It just doesn’t work” issue.

I’m surprised that problem solving and communication don’t make it into this list somewhere. Being able to talk about how something is designed or explaining a bug are common issues that can come up. Having a solid template for how to troubleshoot problems is probably amongst the most common abilities developers have. Abstract thinking probably also merits a spot but not quite on the same level I think as for some things getting abstract can get one in trouble.