As web developers we all love to code; that's why we do what we do. I'm assuming we all strive to be the best we can possibly be. Working in the fast-paced environment at BKWLD, our team of developers have to learn to adapt in the moment to meet deadlines, most of which arrive a little more quickly than we'd like. I'm often forced to attempt to straddle a line between doing something well and doing it quickly.
The expectation is that these can both be achieved, which sometimes is true. More often than not, however, I'm forced to lean more to one side, choosing to either make something clean and beautiful, or make something that is complete when the client needs it.
Which approach is better? Our tech director, Justin Jewett, summed it up excellently when he told me: "We need fewer assassins and more street fighters." Jewett points out that we need people that can code quickly, roll with the punches and do the finest job possible - something that's especially difficult when things get heated and clients are less than friendly. This has led to many intense discussions about what approach is correct.
Poetry is good
There is a reason good code is considered to be a form of poetry. It's elegant, clean, easy to read, and fun to write. These are all exceptional qualities that we should strive for every single day. This approach is philosophically correct. If code is structured well from the beginning then, late in the game, things are easier to find and edit. For example, creating a JavaScript file to hold all config-level variables is good practice, making tweaking things like animation speed and delay durations later a breeze.
Speed is good
Speed is often overlooked and/or argued about among devs. The simple way to do things is often viewed as bad or amateur. Shortcuts and hacks are further frowned upon, and their practitioners are considered by the community to be bad developers. I'm a proponent of speedy development for many reasons, chief of which is getting things done on time - or early. This leaves more room for polishing, and can make both producers and clients very happy.
Not everything fits convention
Creating a framework undoubtedly speeds up development and makes things faster, but not everything fits a clean, packaged convention. There are times when a simple image tag, tables, or even (dare I say it?) frames, are a quick solution to a problem that would take far longer to build using standards or some new innovative workflow. I've worked on sites that were way too complicated for their need and context. Not everything requires complicated environments, Python frameworks, or minified concatenated scripts with cache-busting hashes. All those things have their place for specific projects, but a good dev needs to pick and choose what is best for the scope of the project, rather than just use the most complex technology in all cases.
Find what's right for the project
When considering the project you're working on, think about what the needs are and where the majority of time should be spent. For example, if the site doesn't have a need for complex JavaScript, then don't add a script-loading framework and modules that will take time and energy to set up. Instead, a simple script file or even some inline JavaScript will work just fine. That way, requirements are met and you can spend more time on the rest of the site.
If the project is a personal one you're intensely passionate about, spend all the time you want making sure every line of code is where it should be and is reduced to its cleanest possible form. If the project is for a three-month campaign that must be completed next week, the shortest path to the finish line is probably best. I've only been a developer for five years, and 95 per cent of my professional projects are the latter. We need to complete quality work in the shortest amount of time possible.
Words: Matt Aebersold
Matt Aebersold is a developer at BKWLD.
This article originally appeared in net magazine issue 246.
Liked this? Read these!
What's your code philosophy? Tell us in the comments!
