A few years ago, I read an article that changed how I perceived myself and my work. The article was by Venkatesh Rao entitled Developeronomics. The basic premise of the article is that good software developers should be kept around at all costs. The logic being that every company is becoming a software company and it’s pretty hard to make software (or at least good software) without good developers.
There are many factors that go into what a good developer is. Below is my list of ideal traits:
- Ability to code
- Gets Things Done
- Clear Communication
- Affable Personality
- Problem Solver
- Inherent Curiosity
- Optimization Addiction
This is an all or nothing type deal, not a menu of nice to haves. As I’ll explain below, each trait is inherently important to the success of your project and thus your company.
Ability to Code
This is kinda important to being a good developer. 🙂 All joking aside though, this doesn’t mean the person needs to have a college degree in Computer Science or even a related subject like Engineering or Mathematics. One of the best developers I knew was a philosophy major.
Note that I did’t put “Mastery of the Platform of Choice” but rather simply “Ability to Code”. Why is that? Unless you’re planning to recreate the framework from scratch or dig deep down into the internal bowels of some framework, mastery is over kill. Give me someone that understands how to get things done with a framework over someone who knows the inner workings of the framework any day. Which segues nicely into our next trait:
Gets Things Done
Frameworks are there to help you get things done. Good developers leverage frameworks to get things done for the project to be successful. I’ve never written a framework, nor do I ever plan too. There’s no reason because there are so many. I’d rather let other people geek out hard over the best way to build a useful framework, while leveraging their hardwork to get things done for the client.
Do the important things though. I’ve known devs who after a few weeks will have rewritten the same functionality 3 different ways. Each one more perfect in their minds, but no more functional than the others in the eyes of the business. Why? Let’s move on to the next trait to find out.
Communication is not a oneway street, though many treat it as such. To have clear communication, the developer must be good at not only communicating their thoughts to the client but, just as important, they must have the ability to understand what the client is telling them. The latter winds up being a lot harder than the former. This is because quite often what the client is saying is not what the client really needs.
If the client can’t clearly communicate the needs and desires for the project, how the heck is the developer supposed to understand them? Is there some sort of magic decoder for interpreting client communications? No, but reflecting back to the client your interpretation is a great way to show them what they’re saying. A better way is to get them to talk about their real wants and needs without them knowing, which leads to the next trait.
Developers are quite often a tough crowd to get along with in day to day business interactions. There are several reasons why that is. Many developers turn to computers because they are socially awkward and the computer doesn’t care about that. Some developers are more concerned with the sanctity of their code versus the success of the project. This causes them to get crabby when you bring in news that will break that sanctity.
If you look hard enough though, you’ll find developers that didn’t turn to computers for the lack of social interactions and sees their code as a means to an end, not as a holy relic that cannot be tampered with. What’s a good sign of this? The answer to that is our next trait.
Your project is a series of connected problems. You may think of your project as a game plan, but to the developer it is a series of problems that need to be solved. The deveoper’s goal is to solve all the problems while insuring the solutions don’t conflict or break each other.
In computers, nothing stays the same. There is always a new hardware version to buy and a new software update to install. Development tools are no different. Each new version of frameworks and SDKs make it easier and simpler to solve common problems. Going back to that “Master Mentality” mentioned above, some developers figure out one way to do something early on and fail to upgrade to use new features because they’re comfortable. To be a good developer, you can never be comfortable. You have to forever be treading new ground and territory in your thinking and toolset. This leads to our next trait.
A lot of people enjoy being comfortable. I remember a history teacher that taught from the same notebook for over a decade. History didn’t change, so why should his lectures? It’s why Computer Science departments often teach outdated, useless languages to freshman students. Known paths are not full of surprises and thus are comfortable.
Developers who like to master frameworks start off with curiosity, but then lose it as the time invested in the framework increases. “I’ve been doing it this way for years. I can’t just walk away!” To be a good developer, you have to be like Jack Bauer with your go bag, ready to walk away from a history of doing things in favor of a better, faster way. This brings us to our last trait.
Much like in life, they are many paths to successfully solving a problem in code. Where many developers go wrong is they find their first solution and stick with it for life regardless if it was the optimal way or not. Optimal can be subjective in coding. Is optimal less lines of code that’s hard for a human to read? Or is optimal more verbose code that’s easily read by humans?
To Omega Ortega, optimizations deal specifically with how fast we can get a known problem solved. We will take a few different approaches to solving a problem as we first encounter them, until we find one that works well. We then reuse that until a better way shows up in a new framework feature. We then replace our optimized solution with a newer one.
Good developers are hard to find. Good teams of developers, designers and project managers are even harder. Our team has known each other for almost a decade. Individually and as a team, we exhibit all the traits mentioned above. Because of it we are fast, extremely fast and efficient. Our speed and efficiency have brought us victories in hackathons.
The same skills that allow us to win hackathons also allow us to offer up an amazing product to our clients. We will come to your office and in a week, deliver a fully working Proof of Concept based on an original idea we hatch when we get there. Sound interesting? Find out more here.
We’re not saying you have to hire us, but do take all the things we mentioned into consideration. Also, if you were unfortunate enough to have a bad experience with a developer in the past, look through the list and see what trait that particular developer was missing.