Dark Matter Developers

Posted by Fernando Zamora on Jul 9th 2012

I was listening to a podcast yesterday on Coder Radio and I heard an interesting term for the first time. That term is “dark matter”. I know what you’re thinking, dark matter is well known in science and we’ve all heard that term before. What caught my attention is that I had never heard it used in that particular context before. The idea of dark matter as it was referred in that podcast, was used to describe the 99% of programmers who just see their programmer jobs as, well, a job.  That’s those programmers that work with tools that are considered legacy like VB6, COBOL, etc. Those programmers don’t read blogs, don’t listen to pod casts (on programming topics), and are not interested much in programming topics outside of work.  The concept of dark matter is used because, just like in space, even though we don’t see them there is quite a bit of evidence suggesting that they are there.

I did a quick Google search and was surprised to find out that the term dark matter in this context is more common than I thought. Some describe dark matter developers as those that don’t read blogs, don’t have a blog, don’t attend user groups, and are not present at large conferences. Others, like Scott Hanselman, describe them as those that simply work to get the stuff done.

I agree that as a developer your main objective is to get stuff done. You have to provide a working solution or keep a solution working. What I don’t agree with, is the concept that as a professional programmer you should not do any research or learning related to software development outside of work. It is extremely important to keep up to date with techniques and concepts.  Even when you don’t use these new concepts and techniques, it is beneficial that you know they exist.  Additionally, you may need to learn old and well-established concepts to get your work done. It may be old in the industry but new to you. Also, you should not do all of your learning on your employers dime. I believe many developers already do much of this outside of work, even though they may not do many of the things associated with the one-percenters. That’s why I think that the spectrum of 1% and 99% is less polarized than we believe.

I think there are many developers that find other ways to keep up with technology besides user groups, conferences and blogs. To simply say that dark matter developers can be identified because they don’t do all of these ten things or these seven out of ten things is an incorrect conclusion. I do think that we have a lot of those developers in my opinion, but the number is no where near that 99%. Yet at the same time we couldn’t expect everyone to be a one-percenter. Let me rephrase that, we could not expect everyone to do those things that the current one-percenters do.

I think one-percenters serve their purpose. The one-percenters help push the industry forward.  They try out the new concepts, tools, approaches, methodologies. They are the first to adopt all of these things.  Without them we, wouldn’t have all of the things that are now considered and accepted as best practices. All of these things have come from that effort, such as continuous integration, agile development, IoC containers, BDD, all the JavaScript frameworks, the list goes on and on. Yet at the same time, we couldn’t possibly get any work done if we were all one percenters. One-percenters usually create or experiment with all the new and shiny toys – many times at their employer’s expense. Other times, they do it as part of their jobs for research. In many cases they use the wrong tool for the job simply because it is the new hot thing. I will be the first to admit that all of this helps the community as a whole but if everyone did this it would hurt the field more overall.

However, I think that there is a middle ground. This middle ground means that while one may work with established or possibly legacy systems, one can do enough side research to have an understanding of the current trends. This middle ground also means that one can add new concepts and techniques to their existing projects, but in a controlled and organized manner. This middle ground means that while one might not attend any user groups, one might discuss new concepts with their colleagues. This middle ground means that one may not attend the large conferences but one may spend a few hundred dollars on programming books and magazine subscriptions a year. This middle ground means that while one does not have a blog and doesn’t comment on blogs, they read them from time to time.  What I am really saying is that dark matter developers are really listening in on the activity far more than we think.

I think that part of this dark matter has a large subset of people in this middle ground. I also believe that if you are not in at least this middle ground, you should be. Otherwise you will one day no longer be able to live up to your utmost productive level or even worse, remain competitive in the market.

I’d be interested in hearing what your thoughts are on this topic and would like to know if you see yourself as a dark matter programmer. If you don’t consider yourself a dark matter programmer, what do you do to keep from becoming one.

2 Responses to Dark Matter Developers

  • Robert Jones
    July 13, 2012

    That the Dark Matter Developer (DMD) is not “keeping up with the Jonses”, I think, is not the point of Hanselman’s article. Rather it’s simply that there are tradeoffs.

    The DMD’s tradeoff has given him an extraordinarily deep understanding and skill set, perhaps in in a focused niche (the particular company, computer languages, business, etc.). This gives them the ability to “get things done.” Further, it seems like ignoring all the hot topic blogs, seminars, etc. does not hinder them from doing so.

    • Andrew Gray
      July 18, 2012

      To use Robert Jones’ acronym, I see the DMD herself as a tradeoff.

      The DMD focuses on getting the business problems of the organization done (definently a plus), but with this more ‘focused’ goal, dosen’t openly improve their skills…or maybe they’re using a ‘dead’ computer language that cannot grow any further, but is mission-critical to the organization’s business needs.

      The best thing that can happen I think is to cultivate DMDs away from being purely dark matter, but requiring them to make the jump to light-speed. I think it would be a better idea to actively produce ‘Grey Matter’ developers who get things done, but are always passively evaluating their work and seeking ways to improve the code they are working with. Endeavors like this may help with code base migration and other necessary, but typically painful tasks in software development.

      The light-speed developers are probably playing with new, shiny ways of making it happen…our grey matter devs can leverage that, while the Dark Matter devs keep things realistic, and best of all working. I see the Light-speed, Grey Matter, and the Dark Matter all as parts of the same whole that is a healthy software shop.

Leave a Reply




Post Comment

Connect With Us

Recent Posts

A Guide for Learning Design Patterns

July 28th 2016 by Fernando Zamora If you’ve been writing code for more than a year, you might have h...

Read More

Using UML to Analyze Legacy Code

June 30th 2016 by Fernando Zamora For every programmer out there creating brand new code and working...

Read More

Python vs. Other Languages

April 29th 2016 by Fernando Zamora For the last two months or so my fellow McLane Advanced Technolog...

Read More

Naming Your Adapter When Implementing the Adapter Pattern

October 19th 2015 by Fernando Zamora At some point in your project you may need to use a third party...

Read More

10 Methods to Help You Debug Legacy Code

September 24th 2015 by Fernando Zamora A large majority of the work we do in our project is to fix r...

Read More