UPDATE: I’m currently a CTO for a small software development firm, specializing in human factors and behavioral analysis for the education market. I’ve worked for banks, start ups, military contractors, myself, and more banks. Secure software tends to be what I write, but detecting the behavior of those who would commit fraud seems to be the direction I’ve been heading. That said, I have some older thoughts to discuss below. On top of that I’m an amateur inventor, a write-every-day writer, and someone who loves travel and challenging fears.
*The Following was written about 5 years ago.
Technology is what you write, what you know and how you grew to understand it. I started with RPG and some COBOL, and melded that with C based languages, Unix at NCSU, and then added web technologies afterward. I spent a lot of my time in the hardware side, even helped build video cards and controllers, before the classic build and sale of computers, and an eventual shift to systems admin and then programming. I think Developers come in about thirty or so major flavors, but you can ask them a series of questions to help narrow down their “religious beliefs,” with regard to computing. This could also be referred to as somewhat like a Myer’s Brigg for Programmers with a few more major axis points.
1. Design versus Math: Some developers are born to draw out what they think it will look like, and then design the underpinnings to make it work that way. Some people think that foundational logic is required first, and they build from a series of understandings that establish how things are done. I’ve found the first group tend to come at programming from a Graphical or Arts background. They see what will be. The second are the math folk. They start from the data given and start sketching out how things work. They understand how things move under the skin before the skin is ever conceived. I feel much more strongly aligned to the math folk. My favorite tag line to that is I married a designer, because I was so fascinated by what I could barely even comprehend.
2. Linux versus Windows, or more aptly, command line versus GUI: There are some, in fact many, who will argue they are Command Line Windows users, and that my paradigm is flawed, and I’d argue they merely stand on the cusp of this division. Windows users, usually must know the correct check box. I feel comfortable finding those check boxes or even scanning the registry for them, but I feel the most comfortable with Linux, mainly because AWK/SED and Bash can pretty much do anything I want to do, and avoid me messing with that clicky mouse thing that slows me down so much. In Windows, you’ll see a command line guy alt-tab and hot key through dozens of screens. In Linux, that same person won’t install a GUI on a webserver, won’t use a GUI for debugging SQL if they can help it, and will go through keyboards at an alarming rate. I side with Linux, but know somewhere inside of me, I approach the center line. Usually when I’m trying to “think like my users.”
3. With words or with a marker board: I feel very eloquent sometimes. I write stories, occasionally poetry, and wars on bulletin boards from my youth were fiery and verbose. That said, give me a technical concept and tie my hands under me, and I find it difficult to explain to you succinctly. This is the distinction of a developer I’m most confident in defining. Some people need to speak with pictures, and it doesn’t necessarily define or break the 1st paradigm if they’re also math folk. If you’ve met a developer who can rattle off exact answers in a design review,. they’re either prepared, experienced in the topic, or a word person. If they need to get up and draw it, they’re the second category. Developers who demand Visio are the second, those who demand One-Note first may be the first.
4. Team Players versus Soloists: Every developer must be somewhat a soloist. The epic struggles with cognitive dissonance, the long hours trying this or that, and figuring out what works and what does not are characteristics of the practice of the trade, but there are some developers who cannot play with a Quartet, Quintet or Symphony. You find many of them in quiet offices with the doors closed. Often distantly friendly or sometimes stereotypically odd or stand-offish, they master their skills moving painstakingly across each variable. The Team players are the vast majority and the most often successful, but there are some honorable mentions among the soloists. I tend towards the Team, and even when forced to play alone, I feel the quiet urgings to hear an accompaniment, even if only a tambourine player like a business analyst (Bazinga).
5. The Paranoid versus the Optimists: This is a shift many developers may cross back and forth across. Perhaps paranoid is too harsh, perhaps they should be called “overly-cautious.” The Overly Cautious, do not over sell. They routinely under-sell, and as such set expectations as low as humanly possible, often to the point where when they succeed, they damage their images. The Optimists over sell. They are convinced, as well they should be, that everything is possible, but time is always the question. Optimists have the advantage of often being tireless in their pursuit. Paranoids often workd 35 hour work weeks. Somewhere in between all of this, I and the rest of the successful developers fall.
6. Purist versus the Hacker: The term hacker has been abused by popular fiction, media and a host of elements ranging from Nigerian Princes to the kid who liked Anna Kournikova. Hackers get things done by quickly duct taping any solution available into place. Purists at the extrema, have perfectly formed objects running in immaculate MVC, that is a bear to debug, because all elements must be completely understood before any perfect solution can be made. Some would argue that one of the strengths of MVC are that you cannot hurt other code with properly implemented MVC, they have not met a true purist, who would write watchdog objects that prevented the successful completion of items not included in some registry. The scariest of purists are also soloist and paranoid. I find a happy middle, but at heart, I was born into this as a hacker, who has become more enlightened as the days go by. What works is what you have to do most days. Few purists can survive day one at any new or old enterprise.
7. Teacher versus the Student: This is actually not the concept of one Developer tutoring another, as much as one type of developer is constantly learning and the other is constantly teaching. The teacher is a Howard Roark sort, from Ayn Rand’s Fountainhead fame. They seem to come up with a variety of methodologies and preach it from the rock. The Student goes out and brings back 50,000 new ideas he’s found in journals, blogs and seminars. One could call the teacher an inventor, but that’s rarely what they actually do. They usually didn’t make the compiler, the framework or the tools used, but instead just figure out a good way to do something and spread it around. It usually seems to come from thin air. As much as I admire the Teachers, and I often just solve problems, my best skills come when I adapt what I understand from industry standards to the principles at hand.
Those are my basic paradigms, I reserve the right to edit and add, but these are how I measure myself and prospective interviewees.