Tooling Not Craft

For a while, I’ve had the nagging feeling that there’s something missing with the way that many junior developers learn to write software these days. In a way that I suppose makes me a bit of a curmudgeon, I somewhat long for the days before the prevalence of the IDE and the automated unit test framework.   But rationally I know that IDE’s and other specialized tooling have done a lot to both cut grunt work and to eliminate accidental complexity so it’s hard to deny they’re a big step forward from what came before.

And then it occurred to me.  Some of my issue with the modern tendency toward doing everything in the IDE is the tendency that weaker developers have to conflate tooling with craft.  Because Eclipse has the ability to automatically generate getters and setters for each data member of a Java class they simply stop questioning the wisdom of having getters and setters for all the members and merrily march forward–exposing far more data than they should.  The benefit of data hiding, which, after all, was the original benefit of private class members is largely lost because they can’t be bothered to actually think through the wisdom of effectively turning a class into a pseudo-struct.

A long time ago when I first began coding I had a senior developer who mentored me.  I had a bit of a tendency to charge in and start changing code (I am still guilty of that I suppose) without really thinking through the problem.  He wisely counseled me to take a few minutes to think about the problem before I started hacking.  Now I think I understand how he felt.

Don’t get me wrong–better tooling is definitely a good thing.  But don’t let your tooling dictate your craft. And if you want to be a truly better developer focus on learning the craft of building strong code.  The tooling is important, of course, but the underlying craft is much more important.

3 responses

  1. Pingback: Professional Development 8/28/2017 – 9/03/2017 – The Software Mentor

  2. I don’t think this is the case. I actually think most new devs, being in the JS ecosystem, are very cmd-line friendly and actually go though great pains to *not* use IDEs, especially if they are not free, etc. I’ve been programming for 35 years and I certainly appreciate a good IDE to save me time, and I would certainly rather have things “just work” so I can concentrate on the issues at hand rather than wasting time for every project configuring some brittle contraption made of npm, yarn, webpack, transpilers, test-runners, 26 different config files, 1000 packages, etc. So one could argue the opposite — that new devs spend so much time on this minutiae (and trying to find the perfect package to do what they want rather than writing it) that working within the confines of an IDE would actually be beneficial.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: