The Developer’s Fence
Date: November 8, 2016
Posted by:
“Some people might not care. Like painting the back of the fence or finishing the underside of the cabinet, it’s a detail that only people who take tremendous pride in craft really care about. And, of course, people who look for just exactly that kind of quality.”

It’s a quote from Rene Ritchie’s 2015 article titled, The difference between Apple and Samsung industrial design. In it, Rene looks at the differences in detail between the Galaxy and the iPhone. (Note, this article was posted pre-all the Samsung issues.)

For anyone that has OCD, I’m sorry in advance. The pictures are disturbing, but the differences are clear. Apple’s attention to detail is unmatched. Most people will not notice if minor details are aligned or askew, but the fact that someone took the time to polish off the design so well just oozes pride. As a developer, I feel that pride when I look at the code of a final piece.

The developer’s fence.

There are two sides of the fence with digital projects. The front-end, that the user sees, and the back-end that the developer writes.

There are also no rules that say your code has to be organized. Sure, there are some syntax details you have to follow so that it works, but there is no rule that says you have to be organized about it. What the users sees on the front end can still be beautifully functional whether or not the code is a hot mess.

If you’re a part of my team (or if you’ve ever worked with me), you know that I’m a stickler for organization within code. I want comments, consistent spacing, and structure within the piece. It’s a detail that few people will see and less will appreciate, but it is so important.

That specific attention to detail is part of my pride (and hopefully my teams!) in the work.

Why bother?

Whether you work with a team or freelance on your own, taking a few extra minutes to organize your code can help tremendously. You can cut down on back and forth between team members and save time on edits. Here are two things that can help you become more efficient in your work:

Giving your document structure makes a world of difference. This is especially helpful when working with long-form web content or newsletters. You can begin to collapse/expand sections of code and more easily focus on the part you’re working with.
Structure helps when looking for error too. Most development platforms are nice enough to point out when there’s an error in your code. It’s usually some kind of painfully red warning sign that means you have to comb through everything to find the issue. (And it’s almost always a needle in a haystack!) When I’m working within a structured document, it’s simple to go back and look for inconsistencies.screen-shot-2016-11-08-at-10-32-05-am
Everyone develops differently and there are many various ways to accomplish the same goal. If you’re sharing files across between team members, comments can help them understand how the piece was built. They cut down on a lot of internal, back and forth questioning.
In addition, when you’re attempting to make edits to a file, comments assist in locating them faster. Almost all the edits I receive on projects come from people viewing the front-end of it. They’ll say something like “Adjust the font size in the callout of the third section”. Lucky for me, I can scan through my document and easily spot the third section’s callout.comments within code

“Paint the back of the fence.. because you’ll know” A quote said to have come from Steve Job’s late father. Organized code, that’s my back of the fence. Painted.



Leave a Reply

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