Coding: Genius vs. Monkey

Recently, a client who was looking to build a large app on a budget proposed a great question. He was deciding if he should hire a firm, hire a full time developer or get an intern from a local university to develop his application. At one point, he said: “The problem is, I don’t know how much of coding is genius and how much of it a monkey can do!”

I realized that this is a pertinent question that would help a lot of our readers. Although the answer varies project to project, I believe I can shed a little light here.

A Quick Background
I’m going to simplify coding into two parts. The frontend and the backend. The frontend is anything that the end user will see on the web. This is probably what you think of when someone mentions a website. The backend is everything that goes on behind the scenes, which in some cases is a lot more complex than the front end. For example, backend coding involves complex calculations or pulling content from databases. For particularly complex sites, I refer to the backend as the “heavy lifting.”

Future Proofing
So to explain which parts of coding are genius and which are so trivial that a monkey could do them, I’ll start with the frontend. There is a very important factor in frontend development that I call “future proofing.” Future proofing is very important to us at Brolik, and I believe it’s a sure sign of professionalism when done right.

Future proofing includes three main factors. The first is scalability. Code should be written to make sure that it’s ready for future additions. This could be a new tool that comes out or a new trend that emerges on the web. If the client comes back with a request after a project is finished, we don’t ever want to say, “No, you can’t add that without starting from scratch.”

The second factor is updatability. After initially coding a website, we’ll sometimes need to make specific or global changes to how it looks or functions on the frontend. If coded properly, it should be simple and quick to make these global changes. This requires properly structured, organized code that is well commented (what’s code commenting?).

The third future proofing factor deals with standards and depreciation. The web is always changing, and sometimes bits of code get “depreciated” and eventually phased out. Also, website “best practices” change over time, and code that used to be cutting edge eventually becomes outdated. There’s enough documentation out there, however, that a good developer will be able to know what’s going to be outdated soon and avoid it.

As you may have guessed, all of this future proofing falls under the genius side of coding. There aren’t many worse surprises than picking up a project from another firm and realizing that it wasn’t written in a way that makes modifying easy.

The Backend “Hidden” Code
Some parts of a website or application are more set in stone, and a good coder will break these parts off into separate, “hidden” files that run in the background. If you’re familiar with coding, these parts would be javascript includes or PHP class files, for example. They’d most likely control common or standard functions, like an ecommerce shopping cart.

These files take in information, process it, and then output new information for the website’s frontend to display to the end user. Because this code is usually very function-based and is unlikely to change much in the future, it’s not as important to be future-proof or written in with human readability in mind (it’s good practice to format code so that it’s easy for a human to look at and assess what’s what). As long as this “hidden” code functions as intended, it matters less how well the code is written.

For this reason, “heavy lifting” is typically able to be handled by any coder with a computer science or information technologies degree. Of course, experience and individual skill will factor in here, as I’ll get to next.

Complexity of Project
Sometimes that heavy lifting backend part of a website or application is much more complex, important or sensitive than a typical project. In this case, you’d be a lot safer in the hands of a genius. Because there are differences in good and bad code, cases where bad code is a potential security threat (like sites that handle credit cards or store huge amounts of sensitive corporate information) shouldn’t be left to a monkey.

Knowing when you should hire a genius and when you can get away with a monkey will surely still be a challenge if you aren’t a coder yourself. Learning and understanding these general concepts can, however, go a long way for a business owner.