8 ways good developers become great

09.04.2013 | by Kyle Racki

I was recently asked by an interviewee what I think makes a good developer great. It's an interesting question, because since I'm only a pseudo-developer, what gives me the right to answer that question? Well, the fact that I hire and employ developers means that I need to be able to recognize talent, as well as attract and retain great developers, not just good ones.

Now, I recognize that some developers just have the gift to create mind-bending technology and usually end up being employed by Google, Facebook or Apple. No matter how good I think I am at something, I will always find others who are better, who just have "it". So my list is not taking into account technical genius, but rather qualities that any working professional can work towards improving.

So without further ado, here is my list of eight qualities I look for in a developer:

1. Be creative

Many people think developers are a nerdy bunch whose idea of creativity is making clever Star Wars puns in place of lorum ipsum text when they are adding placeholder copy to a website. However, what few realize is that great developers are as creative as interface designers, just in different ways. Some developers at Headspace have side hobbies that include playing lead guitar in a metal band, gourmet cooking, and building robots just because, robots.

And while a good developer can grab some sample code from the internet and tweak it until it works, great developers can perform the coding equivalent of bending spoons with their mind or dodging bullets Matrix-style. They understand the inner workings of computers, servers and how browsers interpret code and they can think outside the box to create elegant code that non-coders just chalk up to plain space magic.

Tell me that's not creative.

2. Be adaptable

Let me make this clear: Process is a good thing and good coders follow a process to make their code the best it can be. This may include solid database architecture or well thought-out use-case diagrams. They use test-driven development to ensure small parts of an application are working and vetted before moving on.

But at some point, a great developer knows when to bend the process to just get the job done, not allowing themselves to be tied down by a process that isn't working in a given situation.

The other way a great developer can be adaptable is to not be tied too closely to one platform. Take our team member Jonathan, for instance, who is the lead developer on Pitch Perfect. He came on board with us with a masterful understanding of PHP and Javascript along with several other languages. But he hadn't used CodeIgniter before, which is the framework we build our PHP applications with. After getting an overview from Nick and taking some time to review the code that was already built with the framework, he was off to the races, building some pretty intense shit.

Great developers have their favourite tools but are not bound to them and can MacGyver a solution when they need to.

3. Be Professional

There are a lot of ways developers can be professional. Obviously, good communication and team skills are important, but even mediocre developers should have those. Using industry standard tools is also important, especially relating to version control and offsite backup so that your code is never at risk of being lost.

Another way to be professional is to utilize best practices and make sure that solutions are crafted in a way that is extensible. Great developers refuse to hack together solutions or cut corners just to get the job done, unless they're building a prototype that is meant to be discarded. Just because the average Joe can't tell the code was hacked doesn't mean that it should be. It's got to be as clean and polished under the hood as it is on the surface, otherwise you're building a low quality product that's difficult to maintain and could have peformace issues down the road.

4. Know the business and the user

A great developer will not just code what she's told by the user-experience designer, client, or product manager without understanding the business problem it's solving. When a developer understands the business case for an application, why it will make a user's life better, then she will be that much more passionate about coding the product and will come up with more creative solutions based on this understanding.

This is kind of like how designers should actually read the copy they're given before coming up with layout or typographic solutions. Getting the context of a situation and understanding why it's valuable instead of just filling out an order in a function spec is what separates good developers from great ones. 

5. Respect and understand visual design

Similar to point #4, good developers will code the application so it works and then pass off the view to a designer or front-end developer to "make it pretty". Great developers understand that the visual structure and presentation of a website or application can make or break the success of it. In a lot of cases, it's the only thing users notice. Users expect that it will work without bugs and do what it's supposed to, but what stands out is how the product looks and feels while they're using it, and whether or not it's easy to use.

Great developers don't have to be designers or even front-end developers, but they should know when something is well designed and when it's not, and they wouldn't be content to launch an application when they see clear design or usability flaws. I think it's important for coders to keep up-to-date on user-experience which takes into account information architecture, usability, graphic design, branding and copywriting.

6. Don't stay still

Good developers find what works for them and then never move on. Great developers are constantly trying to find a better way of doing something. They are unsatisfied with the code they wrote a year ago because there's a better way of doing it now.

They also regularly read blogs that discuss new techniques and ways of doing things. They keep an eye on new tools and technology that make their code better. They even contribute some of their own findings to an open-source community. The point is, stay curious. Keep honing your craft.

7. Test your work

It's a personal pet peeve of mine when a developer tells me that he's fixed a bug or completed a task, but when I check, it's not even close to done or it generates PHP or database errors. That tells me that the developer just saved their change and then sent me an email without bothering to load it in a browser first and check it himself. In fairness, sometimes a developer may have checked it themselves in a browser first, and then when I test it there's an error that he couldn't possibly have detected due to browser caching issues or the like.

But great developers don't rely completely on QA testers. They do their best to minimize dumb mistakes like misspelled variable names that could have easily been detected by doing a quick check themselves before running it through the QA process and needing a support ticket to correct what should have been fixed before it was even committed.

8. Be lazy in a good way

This idea came from Nick, our technology director. He explained that it's better for a developer to be lazy and smart than to be ambitious and stupid. What he meant was, developers who are too eager to jump in and tackle coding a solution without first stepping back and thinking about it can find themselves painted into a corner. They write too much code, which is difficult to maintain, and it's not abstracted enough, so it contains too many dependancies that can cripple an application with bugs.

Instead, great developers are always finding a way to make themselves redundant. In other words, they want to write as little code as possible and they want to automate nearly everything. They would rather spend time writing an elegant class that automates 90% of their work intead of poring through countless templates and hard-coding a solution that will be difficult to change later on or that is just plain boring and labour-intensive.

These are all my own personal opinions based on ten years working with developers. Do you disagree with any of my points? Do you think I missed any important ones? Let me know in the comments below.