Changes in the Wind, Part 3: Advice for Developers

[box]Note: This is the third part of a three-part series. Part 1 discusses advice for leaders and part 2 is for designers (and everyone who works with designers). Read Part 1 (Leadership Advice) or Part 2 (Design Advice)[/box]
 
For the developers in the audience, I want to take a moment to offer some general advice and good practices as I round out this series about my tenure as a leader and my ongoing role as a developer. Below you’ll find four simple tips, plus a practical reminder. I’ll have more to share in the many months to come, but these are enough to get things started. Without any further ado…

1. Program like a lazy person

Build solutions only when you cannot outsource them and build in the simplest iterations possible.

I’ve personally found that much more can be accomplished when you rely heavily on the work of others. Now, I’m not suggesting you pawn all your tasks off on someone else (that’s the job of a good leader). Nor am I suggesting that you lazily take credit for the work of others (that’s called “being a jerk”). What I am saying is that any solutions you may need probably already exist elsewhere else already, and you should borrow much code from them (if not use them in their entirety).

Building things in their simplest form leaves room for fewer errors and makes for expedited builds (rapid prototyping, multiple iterations, whatever you want to call it), always allowing you to gain features only when they’re actually needed.

Equally important is documenting things as you go (referring to the URLs where you found various components) — future you is never as clever as present-day you, he definitely won’t understand or remember why you built something a specific way.

2. Always pull a fresh copy of any file

Hopefully your team is using a managed codebase with tools like SVN or GIT. If so, you already know the importance of updating your local repository before pushing any changes (and you can skip this section). If that’s not the case, and you’re working with a team of people who are updating a project via FTP, GET HELP NOW! I’m kidding, but I’m also serious… version-controlled code is a godsend, whether you work alone or on a team.

Anyway, if you’re still reading this and you aren’t on a managed codebase, here’s what you need to know: if you’ve had your local copy for more than an hour, assume that it is already out of date and you need to pull a fresh copy from the server. My previous team was unfortunately relegated to traditional FTP at the expense of overwriting each other’s work time and again. That’s the cost of not working with proper version control. Hopefully new dev practices will help you avoid this in the future, but until anything is in place it’s always safest to check with someone before you push any changes.

3. Always Be Testing (ABT)

This is the most cost-effective part of your job, and its the most budget-justifying proof that you’re worth every penny someone pays you. Every time you push a new file to the server you should run it through the testing system to make sure things are okay. If the user cannot checkout, or cannot subscribe, or do whatever it is they are supposed to do that generates revenue for your company, you are bleeding money.

You should also know that you have the authority to challenge everyone else who isn’t testing the pages you build. This includes the project requestor. But, if you are not personally testing everything you also forgo this (important) right to challenge others.

4.Don’t worry about looking incompetent

It’s only when you draw attention to how incompetent you feel that people notice and wonder. I’ve almost never thought, “man, this guy is moving slow” or “man, i don’t think he knows what he’s doing” without a coworker or contractor bringing up their own insecurities first. Trust that we trust you and that we also know things are complicated and take time :) — You’re good at what you do, and that’s why you were hired. Just keep swimming!

Bonus Tip: Why “5 Minutes” doesn’t always mean five minutes

I covered this important realization on bug-fixing in an earlier post, but I felt it prudent to include again here. Be careful as you offer time estimates, and do your best to help others understand when you’re incorrect.

So, there you have it.

Some of the most practical advice I can give you from several months of being a leader and many years of being a developer. Let me know what you think and keep up the awesome!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>