It's not just about the code. We need bigger devs, says Dan Frost of 3EV, and comes up with a list of skills the best developers should have.
Developers need to be more than code-generating grunt workers. We're expecting more of our digital life and it's these guys who build it, so what do the best devs need to know? Here are the things I see missing from too many developers. This isn't exhaustive but it's these qualities that turn a reasonable coder into an amazing developer.
But it isn't one thing, and it's especially never the ability to parse XML or optimise code, It's a surprising collection of skills that aren't taught in the books on writing code. They're a little something extra.
Why vent like this? Because development matters but developers are too often consigned to a different world, not always of their making. This never works. Development - anything technical - always thrives when those with the know how understand more than just the code.
01. Coding don't cut it any more
Forests of books have been published on the making of better programmers. The Passionate Programmer and O'Reilly are good starting points
We're in a world where coding is becoming less impressive. Everyone builds sites, some of them code but you don't have to. It's no longer just the nerdy who can create sites, apps and features.
Since the web came along and people could teach themselves there have been self-taught developers. But even the graduates are under threat. I get CVs with people with computer science degrees, AI courses, various media and coding under their belt but there's still something missing. Sometimes a lot missing.
I'm not the first to say this. 'Coding don't cut it any more' is the title of chapter 3 from The Passionate Programmer, which along with books such as Pragmatic Thinking and Learning urge programmers to improve themselves beyond the code; to become resposible and entirely human members of the team.
Latest Videos From Creative Bloq
Breadth and depth
Developers need to be better in two ways: breadth and depth. They need to understand the breadth of human interactions in their team and with the things they build. They need to understand the depth of the system they're working with, down to the O/S.
And it isn't just developers who should be reading this stuff. If you're working with devs, I think you should expect more of them. Make them sketch out what they're talking about. Get them to explain with pictures, objects and (it works) cut outs of people exactly what the system will be like for the humans using it.
02. The big caveat
I'm going to talk negatively about developers, but I think I'm allowed because I am one. Also because at least one thing I talk about here is true of many of the developers I meet. Although their work is great and they know their code, times are competitive. You need to have an edge, and this is:
be more techy
and
be much more human
03. What the internet says
Googling for 'essential web development skills' brings up what you'd expect. Framework knowledge, x-browser, CSS and JS. They list frameworks you should know, platforms you must be writting for and new trends you should be keeping an eye on.
These are our media. They're the stuff we build with but they aren't what gives a project success. A developer can understand every detail of the system, tell you every feature of an API and a new CSS technology but still produce something unusable.
Get the Creative Bloq Newsletter
Daily design news, reviews, how-tos and more, as picked by the editors.
Understand the medium
Developers, like everyone, need to understand their medium – but they must also understand the audience, be that the users, the team or other developers. They need to understand how their medium fits into the world (in other words, the production environment) and what effect it has (how people use it).
I've seen this described as the 'wide and deep' person. Wide, because you need to understand the world as a human working with other humans. Deep because you need thorough technical knowledge below the level of your part of the project. These developers give your project a huge boost and change the pace of the project, without which you'll find non-technical staff bogged down in tedious detail that overflows from the tech team.
04. The things we build with
I recently wrote down a list of everything we use to build sites, manage hosting and get stuff done so that people joining could have a cheat sheet of technologies to learn in their first few weeks. We were taking it as read that people knew these things, so to give new recruits a jump start we'd list everything we use each day.
I expected half a dozen technologies but ended up with far more. This list – 'what we use' – includes the usual CMSes, programming languages and browser technologies, but also a bunch of tools that the team didn't even remember themselves using. It was all muscle memory. Typing 'git', 'phing', 'thor' on the command line, we didn't even think that someone might not.
Build tools; CI; git for version control were taken for granted, but looking back over CVs these hardly appeared. The trendy ones would appear (and is it cynical that I think certain agencies add them in?!) but often without concrete experience.
These tools are important for accelerating project development, so make sure you have a far richer tool set than your language, the CMS and a couple of frameworks. You need deployment, testing, CI, strong version control (in teams - not on your own), and you need to understand the core concepts of these rather than just a few tutorials.
05. Devops
These extra tools and tricks fit neatly into what people are calling 'devops'. Devops flies in the face of two traditional silos: production, which keeps things running, and development, which makes new stuff (and often stops things running). The silos result in two camps with little sympathy for each other.
Developers without production knowledge more often produce code that isn't suitable for production, by using configuration or features not yet on the production stack. Because they aren't aware of the problems of the production environment, they code to complete the feature rather than to deploy it to production.
These little details can create painful delays, exacerbated by the trend for sending the server management abroad.
Understand the stack
Devops is a huge field in itself, encompassing continuous deployment and lots of automation. This is a sweeping summary, but the key thing developers need to understand is the stack they're running on. It isn't enough to delegate this to the server admin, you have to understand the implications the platform has on your code.
If you work on Rails, read the Rails code and know how Ruby is executed by Apache. If you work in Java, know about the configuration options. If it's Perl you use, understand how to install Perl modules and configure them.
Mysterious work
The 'what we use' list contains lots of this stuff, and good developers leap on that to understand how all this mysterious work is done. And once they get it, deployments go faster, work is deployed more smoothly and everyone is just happier.
Continuous deployment and related practices of devops are becoming so standard that any developer or company not practicing this is setting themselves up to be overtaken. Someone else will start doing it and then they'll be faster than you.
Handy tools
Googling for 'devops' gives you an idea of the tools these guys use. It isn't about PHP and MySQL, or Rails. It's about shipping software and keeping the risky bits of projects risk-free. They concentrate on deployment, automation and keeping the pipeline from developer to production environment running as fast as possible.
You'll find that this style of development gives you developers who work better with each other and with other departments and companies. If they're working with an API from a third party, they'll understand the problems likely to come up on the other side. When working with the server admins they'll understand what they need installed and know how their software sites on production servers. The reverse of this can be painful...
That search for 'essential web developer skills' brings a nice answer from Michael Greer (The Onion's CTO) on Quora:
Laziness: Refuses to do anything twice: writes a script or algo for it.
Cowardice: Thinks to test, worries over load and code impact
Recklessness: Tries new stuff constantly, launches same-day ideas
Cowardice is a nice way of phrasing 'attention to detail'. Debugging and testing is the 99 per cent of a developer's life no-one mentioned when they hit W3Schools or started the computing 101 course.
The ability to fix apps requires excellent problem solving skills, but not just debugging code. Sometimes the solution to users not being able to download their invoices is to make the page printable, rather than spending a day generating PDFs. Sometimes a link can replace a week of development, but that elegant solution won't happen if the devs are solving problems purely by writing lots of lines of code.
Testing is a wonderful blindspot for many devs, despite the many tools out there. Use unit tests, selenium, load testing and profiling tools such as xhprof. Analysis from things like New Relic to keep your app's footprint small. And consider this all part of the dev's job: it's your code, make sure you know it works as intended rather than hope it does.
Debugging
Debugging is a sore point as well. Not how to use a debugger, but how to debug a problem – so I would add to Michael Greer's list:
Impatience: agressively ignores irrelevant information to find and solve the real problem
This is the cornerstone of all debugging techniques. Ignoring the irrelevant and finding meaning in the relevant. Unfortunately, many are prone to slavishly hammering the irrelevant for hours or days, fixing a problem by trying the same thing 10 times.
The are many books (sadly, not the one I pitched to the publisher I won't name) on debugging and every developer should read all of them. A really great dev can debug problems on a system without seeing a line of code.
07. What users want
Understand what the people around you are trying to do. Enjoy the code – love the art of indenting CSS files perfectly, or optimising a rails app – but remember that it's all for a purpose.
Developers need to understand business, operations and the business processes because their stuff helps run it. Devs with this knowledge are able to build software and apps that help users, but they often seem unusually productive. This might be because of their lighting fast typing or amazing knowledge of the stack, but it's more likely to be because of their knowledge of what users want.
Competitive market
Going back to my original point, that development is getting easier and the market for great developers is more competitive any developer who's able to understand the business requirements and bring something excellent to meet them is going to have an edge. Understand the market, customers and why they people part with money all helps.
Understand the data and how it'll change over time. In the developer's mind they should be lining up new technologies with the challenges you have today or see coming. This way, when you suggest a fancy new idea to the MD or to a client it'll be based on what the customers really want and you'll get the budget/time on it. (In contrast, the worst thing to witness is developers peddling their new favourite technology as the solution for all our ills.)
Developers have a lot of control – do they need to know what each field in the database means for the end-user? If we change the data, what will the users see? Is there a better way of helping the users?Too often the view of DB admins is the the world is a bad reflection of their database rather than their database being a bad representation of the real world. The world is mess and surprisingly full of edge-cases. Deal with it, DB admins.
08. Drawing and writing
Drawing is the most direct way of communicating what stuff will be like. Developers must be able to draw their ideas on whiteboard, paper and beer mats.
Developers must be able to prototype on paper, printing screenshots and scribble on them just to communicate their intention. Don't trust the developer who nods, says they've understands and opens up their editor.
Fail cheaply: the best coding begins with drawing as a rapid prototype. Fail more often and make sure all the devs around you do the same as you're more likely to succeed that way.
09. Enjoy yourself
And what if you have to spend 10 hours solving a problem by moving a link around? Enjoy it – even if it's just the challenge of getting through the work.
The very worst attitude from developers (or anyone) is apathy towards what the team is trying to achieve. Unfortunately this is common, because developers see themselves as being outside of what the team is achieving. (The Passionate Programmer poses the question, 'how much more fun could you make your job?' – try it.) And be ready to show your work as the reverse of this is: don't expand having tried out a couple of tutorials on Ruby to 'Experience of Ruby'!
Web and app development is still a young profession, but the skill set really great devs need is expanding. Everyone should expect more of developers because the sooner we all come out of the nasty back room and get involved with the creative process the better the results will be.
10. Stay sharp
To bring this up to a nice round 10 I'll add one final thing. Stay sharp. Find competition. The worst kind of anything is one in isolation.
The worst – really, the very bad – programmers, coders, designers learn their stuff and rest on their laurels. Without a pacemaker, it's too easy to slow down and without seeing competition it becomes habit to see yourself above average.
So, be the worst you can by finding better. Join projects outside of work, contribute and seek out feedback and criticism because the more criticism you get, the less people will give you in future. When you're guessing what they want better than they are, then you're the ninja developer everybody wants.
Dan Frost is technical director of full- service web company 3EV, an official AWS partner. He has been working in CMS and web app development for seven years.
