Back when software was developed in Fortran and C, you needed a lot of knowledge to write anything of significance. Originally, Fortran lacked even the concept of a data structure . In the 1990s, an array was a contiguous chunk of memory containing a fixed number of structs or of pointers. Alternatively, one could create a struct where one field was a pointer to the next struct in the array, a true linked list. You had to write all the code that manipulated anything. You had to decide if an array or a linked list was best for each situation. You had to decide if you were gonna use Quick Sort or needed a Heap Sort or if a Bubble Sort was more than enough.
Additionally, there have always been design patterns and the insight to know when to use one over another; the need for an understanding of programming languages and their compilers which affect everything we do; as well as the operating systems on which everything is built. This list is long, going down deep all the way to discrete applied mathematics and probability. There is a lot one can know which affects the quality of the software we write.
Today, everything has changed. Languages do more and more. Frameworks are getting better and better. With Ruby on Rails, inexpert coders have so much functionality built into Ruby and even more built into Rails. Given the objects which contain data structure and an astonishing amount of algorithms and code doing so much of what you need. The ORM with migrations, algorithms and code doing almost all the database management you need, and generators which create boilerplate code inside an opinionated MVC layout, one can write a pretty complete web application while writing surprisingly little of the actual code. It can be quite some time before one really must make a deep technical decision which one used to make from day one.
This has changed the nature of writing software. Back then, no company would hire someone after nine months of training let alone nine weeks … but that happens now and reasonably so. It is perhaps analogous to the difference between a mechanic who can work with a car and a mechanical engineer who can design a car. An upshot of this is the question of how do we categorize people writing software. When asked, I figure software people, particularly those who write applications, generally fall into about 3 categories. This post is in no way scientific. It is written in a definitive voice but understand these are generalizations. This is just for the sake of starting a discussion and being analytical. I have no proof. Your mileage may vary.
Coders know how to … code. They may no longer be muggles but they are more Ron Weasley than Hermione Granger. They might know a few incantations but there’s still a lot of smoke. They often use examples or starter apps. When hitting a roadblock, which normally comes with an error message, they will put that error message into a search engine and see what comes up on StackOverflow. They find a solution that sounds good and try it. If that one fails, they try another. Eventually one works. They can’t really own their code because so much of it is still magic to them. But, they can write serviceable code that works the way it should work. Their knowledge is usually narrow, shallow and limited . It should be said most are voracious and learning quickly about all the stuff they don’t know. They do well in a collaborative team environment especially when they get to pair. Many will go on to be solid developers.
Developers have a much broader understanding than Coders of the frameworks they use and languages in which they are written. They understand their code. When it breaks, they generally know why and can often fix it. They understand objects; how to write a good one and, preferably, how to test it well. They understand where the magic lies and often how it works. They have an understanding of the underlying technologies (SQL, HTTP, SSH, Unix, etc.) and how to work with them directly. As they become more senior they will know more about more technologies and understand how and when to use them. Their knowledge is still clearly limited. They might know a lot about one area, technology or layer and know little or nothing about others. They do not have the knowledge and experience to architect complex systems well but can build well thought-out features that cut across much of an application and know how to refactor properly to bring simplicity and elegance to a complicated design.
Engineers have deep knowledge of most every layer of the system on which they work from the OS and servers on which things run, the compiler that munches their code, through to the languages they use and the frameworks on which their products are built. They understand patterns and architectures, can determine which is best at this moment and can explain why. They know where the magic lies and understand how it is implemented and how to extend or fix that magic. Whereas they often have a degree in computer science, there is a growing number who do not, who have delved in and taught themselves. They understand their code as well as the underlying technologies and they also understand the theories behind why things should or should not work a particular way. This gives them the facility to fully understand and design architectures as well as solid objects and well-thought-out tests.
When building a team to build your applications, you must know what mix of skills you need and who can provide those in the same way Ford or Tesla will have a mix of skills on a team creating a new car, some deep engineering skills, some mechanic skills. There are many senior engineers who can architect and understand objects but have fewer skills at coding than some coders. Many ambitious coders know the mechanics of a specific technology and can, especially with oversight, use that technology more effectively than others with more overall experience and knowledge. Personally, I have found pairing two such people (one with more specific tech knowledge and one with more in-depth knowledge) can be very powerful. They can learn from each other and your team gets stronger faster.
We must understand who is who, what to expect from each, how to help each grow to their potential and how to get the best code our team can build. These are complicated enough that each should be another post in what I expect will become a series.
It is a brave new world in which we build applications. There are amazing advances in technology that allow us to build a better product faster than we could ever build in the past. It has created the opportunity for many more to be able to contribute in meaningful ways.
Thanks for reading!
This is the first of a series of guest posts by Ken Decanio, a software engineer, architect and product manager. If you would like to read more of his work, you can find find it at his blog.
 Ask me about the DD Array someday.
 Actually, it is preferable that a Coder’s knowledge be narrow and focused but that’s another post.