View Sidebar
Survival Skills for Developers

Survival Skills for Developers

February 10, 2010 9:15 am3 comments

3822866409_c113336eb3_m Let’s suspend reality for a moment and pretend you’re heading out into the woods this weekend. Set aside the fact that you are a software developer and have no business tromping around out in the wilderness.  You’re going to want to take along a few basics:  maybe some matches, a tent or shelter of some sort, a bit of food, and some dry clothes.  To survive you need the right tools / supplies and the skills to use them.

(I bet you see where I’m going with this.)

Back at the office, where your mouse and keyboard fret over your safe return, there awaits an entirely different survival scenario:

Survivor: Cubicle.  Outcode.  Outbuild.  Outlast.

Surviving as a software developer is more than stringing together some lines of code that read and write from a database.  Sure, those are basic skills.  To survive in the woods you obviously need to walk and breathe, but you also need to start a fire and build a shelter.

The following 8 items form a basic survival pack that can get you through most modern software development forests:

1. Data access toolkit (homegrown or open source or commercial)

If reading and writing from a database is a basic skill like walking, then a good data access framework is your walking stick.  I’m a .NET guy so I’ve worked with NHibernate, SubSonic, Entity Framework, and a couple homegrown solutions.  An ORM tool is not necessary.  Use the core ADO.NET classes directly if that works for you.  What you absolutely should avoid is writing all your data access code from scratch every time you need to work with data.

Personally I recommend you learn the basics of several modern data access toolkits and learn about some of the code generation solutions available on the market so you can make informed choices in your projects.

2. Regex

OK, let’s crank the controversy meter up one notch.  Regular expressions are like waterproof matches.  Sure you don’t need them, but they can make things a heck of a lot easier in some circumstances.  When it comes to text processing, there are lots of approaches that can work, but a regular expression can turn an arduous coding exercise into a single line of code.

If you use Visual Studio, I highly recommend you explore the regular expression syntax available for the Find dialog box.  It is amazingly useful once you learn the wonky syntax.

3. Unit testing

Let’s try one more notch higher on the controversy meter.  You must be able to write and execute unit tests for the language and platform you are developing on.  Unit testing is like a compass.  You don’t always need it and you won’t need it constantly, but it can be priceless in many situations.

Unit testing has its fair share of zealous proponents and vehement haters.  I like to think I have a nice moderate middle-of-the-road perspective.  Unit testing is incredibly important in some circumstances.  I am not an adherent to the Church of Test Driven Development.  I do not usually attempt to achieve complete code coverage in unit tests.  But without the ability to write and execute unit tests, you risk wasting precious time walking in circles as you test the same things over and over again manually.

4. Basic printing, reporting, and charting

Not every system has to print or produce charts and reports, but lots do.  Even web site developers have to consider how their pages will look when printed and perhaps generate PDF documents for printing.  Regardless of whether you write desktop apps, web apps, or middleware, you should be able to print and generate some basic reports.

If you are a .NET developer like me, check out some of the vendor solutions like Telerik Reporting, ActiveReports, LogiReport, and XtraReports.

Printing, reporting, and charting are about user needs.  Users need to print invoices and put charts of projected vs. actuals into the shareholder report.  Sometimes you need paper to get your business done.

5. Internet: sending email and downloading HTTP content

Back in the last century, we invented this thing called the Internet.  It’s nice.  It lets software programs on different systems communicate with each other.  And the Internet has this way of creating new opportunities so you never know when your software will have to become Internet-aware.

Sending email and accessing HTTP content are pretty easy tasks to accomplish in most languages given the plethora of libraries available (e.g., classes built into the .NET framework).  And even if your current coding project does not require Internet access, you might see new opportunities once you’ve learned how easy it is.  For example, you might decide to automatically email crash reports to your help desk.

If you pass other hikers in the woods, you might not need to talk to them, but then again, maybe you will.  Better to be prepared.

6. HTML and basic CSS

Regardless of the type of software you build, I firmly believe you should know a little bit about HTML, XHTML, and CSS (and some XML would be good, too).  If you don’t build web applications, you don’t need to master these technologies, but a grasp on the basics will come in handy.  Examples:

  • creating HTML formatted emails to send to users
  • updating a development team web site
  • customizing a product wiki
  • writing end user documentation
  • updating the company web site (happens in small companies)
  • setting up a blog for the marketing department

(X)HTML + CSS is the lingua franca of the web so just learn it already – no fancy survival metaphor required.

7. Scripting or command line development

Many software components need to work with standard input / output streams or simply do not require a graphical user interface.  If you only know how to build Windows or web applications, you are severely limiting your ability to efficiently handle the many small tasks that often accompanying development work like parsing a file or deploying software updates.

If you work in Windows, learn to use the command line along with some basic VBScript and batch (.bat) file "programming."

If you work in a Linux / UNIX environment, you probably already know the things you need to learn.  In case you don’t, I suggest digging into some shell scripting, sed, awk, and grep after you’ve mastered the command line fundamentals.

If you work in an OS X environment, you just need Photoshop.  No, I’m kidding.  Learn the UNIX utilities.

Decent command line and scripting skills are your ferrocerium – more hardcore than a match and much more durable.

8. Services, daemons, and cron

Sometimes software just needs to run on its own.  If you’re a Windows developer, learn how to build a Windows Service and how to run programs with the Task Scheduler.  If you’re in a Linux or UNIX environment, learn how to write a daemon and schedule cron jobs.  Even if you don’t specifically need a Windows Service or a daemon process in the foreseeable future, understanding the concepts will make you a better programmer.  Unlike desktop apps that can be easily restarted or web apps in which code executes in short bursts, daemons and services are long-running processes that require careful creation.

Thinking about responsible resource management in a long-running process will make you a better programmer, just like building a campfire in the wilderness from collected wood will make you that much better at building your next campground sing-along-and-make-some-s’mores campfire.

Mmmm…  s’mores…

Let the Comments Flow

Agree?  Disagree?  Think I missed something?  Leave a comment and let’s discuss.

 

(photo credits: Alaskan Dude)

3 Comments

  • JB King

    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.

  • 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).

  • 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.