Low Information Developer

BY ALEX TATIYANTS

November 6th, 2012

One of my favorite euphemisms of this political season is Low Information Voter. It describes a person who lacks a basic understanding of the issues, yet stills feels compelled to vote.

In fact, I like the term so much that I felt compelled to apply it to my favorite group: developers. Here’s my list of things (in no particular order) that would make one a Low Information Developer. Enjoy!

You’re a Low Information Developer if you…

What’s on your list?

You may also like:

Did you love / hate / were unmoved by this post?
Then show your support / disgust / indifference by following me on Twitter!

This post got 2 comments so far. Care to add yours?

  1. Will says:
    November 7, 2012 at 6:25 am

    Hmm, by this arbitrary list I’m a low-information dev.

    I think you need to explain why your information shouldn’t be stored in an RDBMS by default.

    I often just use raw JS.

    I have a healthy interest in functional programming etc but never find it useful in the programs I write.

    I really dislike CSS preprocessors, and all the preprocessors for JS in fact; I dislike trying to work out what actually runs. I even dislike minification of JS for this reason.

    I use mocks sparingly. I like proper tests that put information in the top of the app and check the information coming out the bottom.

    And I don’t have unit tests for the JS I’ve got. Perhaps one-day I will have some JS code that does heavy lifting and needs them. Not yet.

    • Alex Tatiyants says:
      November 8, 2012 at 3:27 am

      Hi Will, thank you very much for your comment. First, just to address the points you made:

      • In my experience, there’s certain data that doesn’t lend itself to a relational model. For instance, I work with highly structured, hierarchical clinical data which requires a very complex set of tables to store it. This incurs a very real cost of having to deal with the impedance mismatch, a cost that diminishes significantly with document databases. There are of course tradeoffs to be considered with non-relational databases as well, but storing everything in an RDBMS by default is willfully ignoring them.
      • there’s a big difference between using raw JS for processing as opposed to DOM manipulation (which is what I was pointing out). The former is perfectly reasonable, the latter is masochistic when we have tools like jQuery 🙂
      • the utility of functional programming techniques surely varies by use case, but knowing the concepts is important.
      • CSS pre-processors may add a bit of magic to your build pipeline, but I found them to be immensely useful and, quite frankly, fun to use with CSS. In my opinion, the trade-off is more than worth it.
      • For unit tests, I find mocks unavoidable for many situations, both in client and server side code.
      • You must not write a lot of JS. For heavy-duty web apps, having a set of assumptions canonized in unit tests is a real life-saver. Moreover, it limits how many functional tests you need to write, which is a plus in my book.

      To your larger point: You’re not a low information dev because you explicitly chose not to do these things for (what I assume are) valid reasons. That said, in my experience, you’re the exception. I find that most who don’t do these things, don’t do them due to ignorance and not well thought out concerns.

      Thanks again for reading and I’m a big fan of your writing. Keep up the good work!