Realigning the Azimuth

Do tools maketh the man?

One of the things I find highly important to being a good developer is mastery of your tools and how they related to the technologies you’re working with. Whether that’s the venerable command-line, your preferred text-editor or IDE, and perhaps, even the operating system you’re running them all on, it’s incredibly important to be know your environment from back-to-front, and may even lead to you developing your own preferred shortcuts, command-line aliases, or even the discovery of custom tools and utilities (as any of my co-worker’s who regularly pair on my Windows machine would attend to).

Whilst this is all fair in practice, one of the cases where it happens to have some limitations is in organisations, which happen to take paired-programming seriously, which typically results in developers being unaware, or simply uninterested in wanting to evolve their tool knowledge beyond these stock standard defaults.

For me, being able to actually set up your preferred environment is something I happen to find important. From being able to pick an appropriate colour theming, or even the fonts your editors use, to even being able to add those aliases to your command shell (or, if you’re living in Windows land – being able to ditch cmd.exe and replace it with something like Powershell) is one of those things I couldn’t live without.

So when I do find myself working with something who doesn’t feel the need to do any of this stuff, I can’t help but wonder about their dedication to their own productivity – is it worth that much to being able to keep a stock standard environment, even if you lose productivity as a result? What about being able to refine your techniques as you happen to get more experience in the field, much like the development process, shouldn’t we aim to be able to improve how we build software as well?

Seeing people who work in this way just makes me feel like we’re losing something by environments where this conformity has been pushed, or, even worse, organically grown, as this artificial levelling in skill-sets may result in more developers who can work anywhere in their environment, but it doesn’t make things easy when they move outside it – what happens if a developer moves to a different organisation? Should they be expected to have to relearn a total environment just because it’s the standard. I think not – instead, developers should be able to pick the tools that they prefer to do the job, and get the experience they need with them.

  1. abhi says:

    If you think the LCD effect of pairing can be bad you should try to work like these folks did :) - http://www.coudal.com/closeenough.php

    Seriously though, I've also been frustrated when constrained by a less productive tool for the sake of its familiarity to the group, and I've a
    simultaneously learnt so much and gained countless new tools through pairing.

    IMHO, a healthy pairing environment is one that also encourages diversity; after all why bother pairing if both people have the same preferences, perspective, skills and ideas? I think it's their differences that allow them to create things that neither could on their own.

  2. Xian says:

    I totally agree with you Rob, a developer should be free to customise their environment with tools that increase their productivity. After all it only serves to increase their value to a company.

    Too many times i find it harder to find the real gems of developers, those who are empassioned. It is these people who have a constant hunger for better tools, and more short-cuts to further increase their productivity. They drive innovation and adoption of new technologies. These are really people i can admire and have many a heated argument about the elgeance of design, especially the minutae.

    However we still have to work with those who are just here because "it pays the bills" and not because they enjoy it. Therefore it is important we have environments that enduce productivity and have a pleothora of tools that they can be educated to use. And it is upon us to teach these people, because they are the type that will not RTFM! :P

  3. Rob Caporetto says:

    @Abhi
    One of the things I've found is that I've really only felt comfortable pairing with certain people, and it's at least only after a bit of time when I've gotten comfortable around them, which makes it a bit easier for me to speak my thoughts when actually pairing.

    What I've also found is that in some cases, the fact that I've not been automagically fluent in certain other tools when having to lead on a pairing session has kinda made it a bit of a hassle or those people, when really, a bit more patience would have been preferred.

    Those types of cases have made me a bit skeptical to pairing for the majority of cases as a result.

    @Xian
    I generally find that the same - some of the developers I've worked with previously, whilst are great people, sort of have felt like they're in that being there to pay the bills thing as well. Consequentially, those are the cases wherein people are you've pointed out aren't as into the whole tweaking their workflow to make it more efficient thing. And when I've been one of the lower-ranked people on a team (in terms of experience), it's made it that bit harder to feel comfortable in terms of actually getting work done.

Post a comment


(lesstile enabled - surround code blocks with ---)