If we consider software creation a craft, Is it time to”bring our own tools”?

If you look at really productive programmers – like the top 10-20% – there are usually a couple of characteristics that they share. Aptitude and in-depth understanding of both the system they are working on and the technologies involved is obviously one very important factor. Another factor that tends to be overlooked is that these programmers are also masters of their tools in the same way that a master craftsman – say, a carpenter – is also a master of their tools. That includes potentially obscure tools, and the ones handed down from grandps or found at a yard sale.

I think that mastery of your tools plays an important role in your ability to be a productive software engineer. If your tool interrupts your workflow because you need to figure out how to accomplish a task at hand, you immediately waste precious brain cycles on this disruption rather than being able to use them in the flow of software creation. That sort of disruption can easily drops you out of “the zone”, and those brilliant thoughts might never make it into your software as a result.

There’s also a trend that I’ve seen over quite a few years in a lot of companies (usually large, with IT departments that most developers would find overbearing, but it’s not limited to these companies) limiting the tools that are available to developers. The usual attitude seems to be that if a certain tool is not included in <insert development environment of choice>, it is not needed for serious software development and thus developers are only requesting these tools because of their magpie like tendencies or worse, because it allows them to polish their resumes and then wander off and get a better job.

Leaving aside the latter “justification” – if you work for a company like that, my suggestion is that you find yourself some career opportunities elsewhere anyway – you’ll end up running into the issue that the one tool you need hasn’t been requested by anybody else and thus is not on the very short “approved” list. Your manager will have a hard time justifying the expense because nobody else “needs” that tool and thus requested it. Plus, IT departments tend to have an ingrained dislike of exceptions of any kind, because it usually tends to make their job a lot harder. A short list of approved software with everything else banned does make it possible for them to support thousands of machines, but at the expense of inhibiting the creation of a work environment that is designed to give people all the right tools they need for maximum productivity.

Most craftsman own their own tools. A carpenter will show up at a job site with their own tools, a car mechanic uses tools he’s acquired over his career. If you subscribe to the view point that software development is a craft and not an assembly line operation, then maybe it is time for us software engineers to step up and tell our employers or clients that we don’t expect them to pay for certain tools, but we will bring them with us and expect to be able to use them. Of course, the latter is going to be the issue – there will be clients and workplaces with the IT policies designed by Mordac The Preventer’s cousin that will under no circumstances allow a tool on the premises that has not gone through an 18 month vetting process by the secret IT ninjas – but to me this is the sign of an environment that is conducive to good software development if it is being recognised that a craftsman’s tools play an important role in both their ability to produce quality work and enjoy producing said quality work.

If your development team doesn’t enjoy what they’re doing, they’re not going to be at their best and create the absolute best software they can. And we already have virtual shelves of “good enough” software available, we don’t need more of that.

While there is a need for some standardized tools like the compilers and the basic build environment – I really do not want to work in an environment where everybody gets to bring their own compiler, I’ve seen how that movie plays out, thankyouverymuch – there is absolutely no reason to hire someone who is a SublimeText/VIM/MultiEdit/BBEdit wizard and force him or her to use Notepad or edlin. Let them bring their own editor, IDE plugins, customizations and let them use it. Let them use the shell they can drive in their sleep.

The same goes for certain types of specialised tools or plugins, heck, even keyboards. For example I expect to use a certain type of keyboard at my workplace due to an old injury and I’m happy to bring one in so I don’t have to use the “but it came standard with the Dulls we buy and it is the only keyboard you are allowed to use” $5 RSI-waiting-to-happen piece that gets inflicted on seemingly everybody.

That said, I am in no way advocating anarchy in the workplace here. There are certain limits that need to be set in a case like this – for example, one of my rules is that no matter what editor you use to write your code, it has to apply the same formatting in all editors across the team. Yes, as a result everybody in the team will have to tweak their editors to ensure they don’t litter the code with tabs instead of spaces and result in formatting that make the source code unreadable in six out of ten editors used by other members of the team. The code will however look the same in everybody’s editor and its readability (or lack thereof) will be the same. Large bodies of code are already hard enough to read as is, we don’t need to introduce additional hurdles.

You also don’t get to pick your own build tool and thus be the only person on the team using CMake while everybody else is using MSBuild. Or use the latest nightly build of GCC when the production code is built using Visual C++.

At the end of the day it’s a balancing act, but as a manager you want to ensure that the tools your developers use are the ones that provide the least distraction to them. You absolutely do not want to inflict tools on a team that get in the way (ClearCase, anybody) when there are tools out there that are designed to complement the workflow rather than inhibit it.

A(nother) tool post

I generally don’t post that much about the tools I use as they’re pretty standard fare and most of the time, your success as a programmer depends more on your skills than on your tools. Mastery of your tools will make you a better software engineer, but if you put the tools first, you end up with the cart before the horse.

I guess people have noticed that I use Emacs a lot :). My use of it is mainly for writing and editing code (and some newsgroup reading at home using Gnus) and I generally use it only for longer coding sessions. As a lot of my work is on Windows, one of the main tools I use is Visual Studio – almost exclusively 2010 right now, although I’ve taken a few peeks at 2012 and have used pretty much every version since VC++ 4. While I tend to use Emacs as soon as I’m editing more than two lines I tend to make the small changes that you get to make while debugging in Visual Studio.

I did actually try SublimeText 2 a little while back as people were raving about it in various podcasts and on blogs. I did like its speed and uncluttered appearance but quickly fell into the “old dog refusing to learn new tricks” routine. OK, this is a slight exaggeration but after a few days I didn’t get the feeling that using it over Emacs did anything to my enjoyment of programming or my productivity. I think part of the problem is that using any editor out of the box versus an editor that one has used over several years and customized   to reflect new things learned about both one’s own tool use and ideas borrowed from co-workers is simply not a fair comparison, but it is similar to a musician trying out a new instrument after getting comfortable with his current instrument over a few years. If you do care about your craft an editor is a central piece of your workflow and once you can use it without having to think about how you accomplish a certain task, it gets harder to change.

Nevertheless, I would recommend that if you are a programmer in search for a better editor than the one your IDE offers and don’t want to invest the substantial amount of time to get comfortable and productive with the editing dinosaurs like Vi/Vim and Emacs, go check out SublimeTex t2. I promise it is worth your while.

Oddly enough my main takeaway from trying out SublimeText 2 was that I – who has been proponent of high-contrast colour schemes for editors like the one used by the old Norton Editor (yellow on blue) – really got into the low-contrast default theme. So much in fact that with Emacs 24’s theme support, I’m now using this version of zenburn for Emacs. The other takeaway was that I really appreciated the fast startup time and having a slightly better editor around than Notepad when it came to all the quick editing tasks one has to accomplish that would either mess up my carefully set up Emacs or require a second instance of Emacs for “scratch editing”. I ended up with Notepad++ for that and it seems to do the job admireably so far.

Another of the tools I discovered on Scott’s Hanselman’s blog is Console2. I much prefer it over the standard Windows command prompt so give it a whirl! I also tried ConEmu as Scott recommended that in a separate post – I’m a little undecided as of yet which one I prefer, both seem to work just fine and are a massive improvement over the original MS command window – if you’re a command line junkie like I am, having one or two tabbed command windows hanging around rather than a plethora of command windows is a massive boon. Try both, see which one you prefer – so far I do like the feel of ConEmu actually being developed (there are frequent new releases available) but Console2 simply seems to work, too. I think it’s just a matter of personal preference.

Speaking of command line tools, I recently had one of these “wow, these guys are still around” moments when I discovered that JPSoft is still offering a replacement command line processor for windows. I used to be a pretty heavy user of both 4Dos and 4NT back in the early nineties when they were distributed as shareware and you had to buy the documentation as a proper dead tree version to acquire a license. Actually I think I still have both manuals in a storage unit somewhere…

Anyway, I have been playing with the latest incarnation of their free command line tool (TCC/LE) and I really like it. Enough so that I’ll probably end up buying the full version. Basically if you are looking for a “DOS prompt on steriods” rather than using Bash via Cygwin or Powershell – which aren’t always that useful, especially if you need compatibility with existing batch files – I would strongly recommend you check it out.