Changes in the Wind, Part 3: Advice for Developers

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)

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!

Fixing Bugs -or- Why 5 minutes Sometimes Means 2 hours

I’ll try to keep this brief, as I’m sure you all probably realized this already. Even so, it’s always a good reminder and will help keep developers and non-developers on speaking terms.

I’ve got a simple analogy for you as to why some (many) things take longer to develop than developers initially estimate and, more importantly, why we perpetually believe it will only be “just 5 more minutes” as we continue to debug.

The leaky sink.

Now, a leaky faucet is presumably simple fix. You will usually have a good idea where the problem is coming from because you can clearly see where the water is leaking, but not always. Most leaks can be fixed with what you already have around the house, but sometimes you have to go out an get new parts. Many times you’ll already know how to fix it, but now and again you’ll need to do a bit of research. Lastly, once in a great while you’ll need to call in an expert, because the problem either wasn’t what you expected OR it becomes too big for you to quickly do by yourself.

Sometimes it’s a simple problem… (5min or less)

The best scenario. This is when you didn’t close the tap all the way, or something has come just a little loose. In programming, this would be a typo or a simple logic error. No big deal, it’s already fixed.

Sometimes it’s a different problem… (5min, x2)

This one is annoying. You thought it was a problem with the faucet, but later found out it was a problem with the tap. You’ve already spent 5min working on the faucet, and now realize you need to spend another 5min on the tap. This happens a LOT in programming.

Sometimes it’s multiple problems… (5min, x2, x2, x2)

Now you’re really frustrated. You looked at the faucet and saw it wasn’t there, then you spent 5min on the tap and the leak still exists. Now as you look more closely you see there’s actually another (two, three, four) problems happening underneath the sink. Or, worse, because you fixed one problem you’ve actually created a problem elsewhere (without the steady leak, now a pressure buildup has busted a pipe. $#!&).

Sometimes there’s a false positive… (5min, x2 …. wait 30min, try again)

The leak has stopped! …temporarily, until you or someone else tries to use the faucet again. You’ve spent your 5 (10, 15) minutes fixing what you thought was the problem, and now the problem is back again. In programming, this is especially troubling because now you’re not sure if it’s just a caching issue or something else entirely.

Sometimes there is no problem… (30min for nothing, FML)

There wasn’t a leak, you (or someone else) just splashed some water up behind the sink. In programming, you’ve spent the last 30 minutes chasing a bug that doesn’t exist. Do not pass go, do not collect $200.

Hang on, just 5 more minutes…

Next time a developer tells you “Just 5 more minutes” and they’re wrong, remind yourself that they’re not lying and they’re not bad at estimating (and no, they don’t hate you), they’ve just encountered a new or different (or additional) problem than they set out to fix 5 minutes ago.

Would You Pay for WordPress?

Michael over at has written an interesting and compelling article questioning what if Automattic began charging for WordPress?

I feel that the short-answer is that the community of users would cease to thrive as many would look to other free alternatives., their free public blogging site, would lose countless users to services like blogger, livejournal, etc. Beyond that, however, there are lots of other unseen factors.

Others have already sounded off in the comments (myself incuded) pointing out things such as the inherent value of something you have paid for verses something you have gotten for free, a very valid point. The flip side to this, however, is that by gaining the CMS for free the overall cost of developing a website is greatly reduced. As a web designer and developer, I am able to pass these savings directly to my clients and provide them a level of service that they otherwise could never have afford.

So, there you have it. What do the rest of you think?

Curious about WordPress?

For anyone who may be on the fence with this subject, I have some powerful literature for you:
Should I Use WordPress To Create a Website?

Hmm, still not convinced? Alright, here is a slightly more thorough article:
Why Power Your Small Business with WordPress?

In all seriousness, I have been involved in web design and development since 1998 and in the past 12 months I have centered my entire web development process around WordPress. Hands-down, it is the best and most user-friendly (and FREE!) Content Management System (CMS) I have ever used. This is why every site I make is powered by WordPress.