Putting the Dev into Front-End Dev

I’ve been doing a lot of thinking about front-end development lately. Between teaching an introductory college course on front-end development, pair developing on projects, assisting with RDG’s code standards, and attending DrupalCon Portland 2013, front-end development has been at the fore of my mind a lot recently. As I’ve developed on the front-end, I’ve realized that I approach it very much as a developer. Some people approach it from their backgrounds as designers, graphic artists, and webmasters. Since my background is application development, I see the front-end through those lenses. I would like to take some time in this article to jot down some of the values that a developer’s approach brings to front-end development.

Standards

Developers don’t like surprises. They like to know exactly what to expect when they are doing something, and they want to know exactly how something should be done. They don’t want to have to guess, because guessing causes errors. That’s why standards are important to us. They tell us exactly what we should do in every situation, and they tell us where we should go if we need to fix something. Whether it’s code formatting, naming conventions, or file structure, standards dictate what should happen. This is especially important with teams, as standards ensure everyone is doing everything the same way.

Consistency

Right on the heels of standards is consistency. Developers like having things be predictable. They are the ones who will notice if a topping on a fast food hamburger is out of order, missing, or out of proportion. That’s because they’ve eaten that same hamburger dozens of times before and have come to expect it to be a certain way. The same thing applies to code. Want to annoy a developer? Do something fifty times one way then slightly different on the fifty-first time. They’ll notice it, complain, then probably change it to match the others. So why is consistency so important? It goes back to the same reason standards are important: Developers want to know exactly how something should be done, and expect it to be done that way every time. This instructs them how to do something when they attempt to do it, and ensures that best practices are followed.

Readability

Developers want to comprehend what they are working on, and things that slow down their comprehension are bad. Standards and consistency are annoying, but they don’t necessarily slow down comprehension. On the other hand, something that’s hard to read and grasp does, so it must be dealt with. Good standards will increase readability, but there’s more to it than that. Good visual organization of code, like visually grouping related information and distancing unrelated information, goes a long way. So does intelligently naming variables and functions so their purpose and behavior is immediately understood. 

Maintainability

Developers know that code changes over time. They know because they are the ones that have to make the changes. Anything that makes that task difficult is evil. If a developer has to make a small change but it takes forever because they have to make the change dozens of places, you’re bound to see smoke coming out of their bright red ears. They have this acronym that really helps avoid this issue: DRY – Don’t Repeat Yourself. If a person writing code is writing the same (or nearly the same) thing twice, they are working too hard. Developers would rather be lazy than do something twice. In this instance, laziness is actually a virtue rather than vice, because it means being smart and letting the computer to the work for you. That’s the point of using computers in the first place, right? So if you’ve gone ahead and were lazy, didn’t repeat yourself, and let the computer do your work for you, then your code will actually be easier to maintain because the small change you need to make only has to be made once.

Efficiency

Developers want to do things in the best way possible. Whether it’s the work they are doing or the work the computer is doing, working smarter is better than working harder. It often results in faster, easier work. Developers love to be efficient as they code and in their code. They’ll utilize all sorts of tools to help them create functionality or troubleshoot bugs quickly. They’ll use pre-existing solutions instead of re-inventing the wheel so to speak. Not utilizing tools just doesn’t make sense to developers. To them, it’s just like using hand screwdriver when a power screwdriver is sitting right there. Using the power screwdriver would let you finish the first screw, move on the next one much quicker, and save your hand from cramps. In addition to tools, developers want their code to be efficient. They want their code to be smart, not do needless calculations, and be optimized for quick response. No one likes a slow computer or software, especially developers. 

So there we have it. Developers bring really good values to the front-end: Standards, consistency, readability, maintainability, and efficiency. Can you think of any others? How have you seen this go right? Or even wrong?