I say this, in one form or another, to developers I manage. I’ve said it for years, and I’ll continue to say it until I’m proven horribly, horribly wrong. Which, until I leave this industry, is not likely to happen.My belief is simple: when you work in a time and materials-based industry, such as marketing, you’re not being paid to do everything new. You’re being paid to deliver a solid solution as quickly and effectively as possible.
The problem, however, is that programmers like to create. It’s what makes a programmer a programmer — I know, because I used to be one. (Then I turned to the Dark Side, but that’s another story.) Programmers like to do things themselves.
But good programmers — at least in this business — try to as little work as possible.
That statement is going to get me in a lot of trouble with a lot of people, but hear me out. There is method to the madness, and I swear I’m not as insane as I sound. (Okay, maybe only half as insane.)
I say this because I want to encourage the developers I work with to think about the best approach to the work they do. Many, many, many times (including myself, I should add) I have born witness to seeing work duplicated, people running in silos (a euphemism for not talking with other people), and taking on too much work when others are sitting idle. All of this because people are trying to be over-achievers when they should really looking at emulating a couch potato.
Reuse Your Code
It’s a simple problem: you’re asked to develop a solution, and that’s exactly what you do. But you don’t look through snippets of code you’ve got (carefully organised from previous projects) to quickly slap together a jigsaw puzzle of previous work. Instead, you use a few extra hours to deliver something you’ve basically done before.
Most coding projects can be broken into modules, snippets, and libraries: ones you’ve used, and ones you’ve built. As much as possible, reusable code should be identified and tucked away in your programming bag of holding.
End result? More done, less time spent.
Libraries Are Your Friend
One thing developers generate hate: using someone else’s code. Why? One simple reason: developer want to do things themselves. (See the above note about creating.) It’s also, to a lesser degree, a trust thing — how can you really trust something you didn’t build yourself?
But it’s not about trusting others’ products — it’s about trusting yourself to implement them to the best of their (and your) ability. It also means that time you spent trying to get something to work properly across all browsers (especially the ever-dreaded IE6) is better spent by doing something more fun … like having a beer on the patio because you finished early.
I always encourage developers to use tools that already exist, be they open source or off-the-shelf. There’s almost always a solution to the problem.
Document Effectively, Not Completely
Now keep in mind that this is coming from an old technical writer — I used to make a living by documenting everything inexcruciatingdetail. In some businesses, especially if you’re producing a production-ready API, you’ll want to make sure there’s lots of detail, not just in real documentation but also in the code.
In this business, I’m quite happy to see two things:
- Variable, class, method, and IDs that make sense. Not entire sentences (believe me, I’ve seen that), but something more than just “obj”.
- A quick 1-line comment above methods that help explain something that’s not obvious.
Why only this? Because it’s quick, and any competent developer should be able to trace through a well-written set of code. Extra documentation is rarely read, and rarely needed.
Simple is (Almost) Always Better
Ever seen Scrapheap Challenge (known as Junkyard Wars in North America)? It was a really neat show. Basic premise: two teams of gear heads are given a simple task (e.g. build a device to throw a car as far as possible), and then set loose in a junkyard with eight hours to build it. Entertainment at its finest, and you got to see some really great out-of-the-box thinking.
One thing that was almost a universal rule with that show: the simplest device almost always won. Why? Less things to break, faster to complete, and quick to fix if something went wrong. (Incidentally, I see similar things happen on MythBusters.)
Moral: Don’t over-complicate things.
Google is Good
And no, I’m not talking about Google not being evil — I mean use Google to your advantage. The amount of things that are posted on the internet is truly staggering — and immensely helpful if you get yourself into a bind.
While a lot of companies seem to pooh-pooh the idea of people using Google to find an answer to a tricky problem, I’ve found that Google can shave of days of monkeying around.
Google is also great for looking up programming references. And before you ask, no, I do not expect developers to know a given language inside and out. That’s just insane. Any sufficiently solid language has too many methods and functions for someone to adequately remember.
(I do, however, expect someone to know how to use that language well enough that looking up a reference is only to check things like parameter definitions. If you know one (good) language really well, a good programmer can learn another one in a weekend or two.)
That’s not to suggest you should ask someone else first…
People are Faster Than Google
Quick question? Tap the guy next to you. Any good developer asks another good developer before doing their own research. (On corollary, any good developer will also gladly help instead of giving any indication of being inconvenienced in any way.)
Delegate, Delegate, Delegate
If you have the ability — and you won’t always have it — turn over simple complex tasks to more junior developers as soon as you can. First, it makes them feel more useful, and it allows you to focus your efforts where they’re most needed — on things that require your skill and experience. Besides, the more you can hand off, the less you have to do.
Make Yourself Redundant
I’ve seen more than my share of programmers (cough myself included cough) who hang onto key pieces of information and not hand them off to anyone else, for any number of reasons such as trust, job protectionism, and (my personal favourite) supposed superiority.
Only problem: You look like a Class A Jackass when you’re not in the office and that key piece of information trips up an entire team.
So make yourself redundant — hand that information out to others (write it down, email it, whatever), people you trust if need be, so you don’t have to be the key master.
Why is that being lazy?
That way you don’t get any phone calls on your day off…
