There has been a lot of fuzz in the developer open source community lately. Mostly towards the developers that criticize ever changing open source projects in a public demeanor. A post about "the sad state of web development" has caught the attention of many developers. This is where you really see the different developer mentalities shine through.

Different Types of Developers

It's important to point out the gap of knowledge as another dimension. The mentality of a developer often shine through and amplifies if it's backed up with a lot of knowledge. This post draws some inspiration from Mattias Petter Johansons video about The growth stages of a programmer.

Dark matter

The Dark Matter Developer

The dark matter developer is, unfortunately, the most common developer there is. According to Scott Hanselman, 99 % of all developers are dark matter developers. Although I think that the percentage of these kinds of developers are shrinking with the emerging open source communities out there. They dwell in the darkness and never display their opinions. Like a bat hunting prey. They simply follow the conventions and their opinions are often a reflection of other developers opinions. These are the quiet developers that doesn't partake in discussions about the design of the open source projects. These developers have all kinds of knowledge, but are never really visible in public forums.

Nested code

The Hacker

The hacker has one goal. Make shit work. The hacker never really cares about how a problem is solved and will often resolve issues with libraries and plugins. They get stuff done, but leaves an obfuscated trail of mixed code practices and hacks. Being a maintainer for after the works of these developers often result in confusion and tears. And when a reliant open source library/framework changes drastically, I understand the frustration when it's time to upgrade. Some hackers understands the needs of an application and doesn't use a lot of time to add unnecessary complexity. This often results in code that is easy to understand since it's straightforward.

Trust me I'm an engineer

The DIY Developer

The "do it yourself" developer has grand ideas of good software. The ambition levels are sky high and the first weeks of development are jack packed with positivism and high spirits. These developers are usually knowledgeable and has an idea of how to correctly structure software. "There's too much stuff in a framework" they say, while they smugly continue to put stuff in to their home-made software. As the weeks go by, the edge cases become too much for the DIY developer. So they find ONE framework and every feature rely heavily on that framework. Apposed to the hacker, the DIY developer will carefully evaluate each functionality and will try to find the best solution without causing too much mess.

Homer thinking

The Conceptualized Developer / The Implementator

Implementation isn't as important. Frameworks aren't as important. Doing work isn't as important. So long as you got a nice concept and interfaces, everything else will sort itself out. This developer is probably the one that worries the most about the flexibility of the domain. This means that the code makes the changes of the framework's architecture easier than a typical "hacker" approach (than using the frameworks directly). The testability of the code will also be fairly good. However, the efficiency could lack from this type of developer. But they produce really pretty code!

Be Aware

Open source projects are probably the most rapidly changing projects in the world. The frustration is understandable. It doesn't take long before the software that's a central component in your application starts rusting to pieces. It's important to note that some software doesn't age like wine. It ages like milk. Especially in the browser game! Suddenly you have a clumpy mess of bad browser compatibility and new ecmascript standards. Therefore I think it's important to follow good programming practices. This makes it easier to switch, upgrade and test frameworks at any time.

Any implementation is, of course, up to the needs. In smaller applications that needs to be made quickly, you can probably use a more direct approach. And when that application grows and needs more advanced functionality, you can extract the parts of a framework/library you need and modularize your application into parts. It's always hard to tell when to add complexity to your domain, and I think it's always good to prepare the app for heavy complexity.

What kind of developer are you? Are there any other developer types that you encountered? Share the love!

Image credits