4 ms·
This post just listed traits very prominent in hackers - deep fascination for technology, perfectionism, need for deep focus and few distractions, concern for e
by mekoka 15y ago
This post just listed traits very prominent in hackers - deep fascination for technology, perfectionism, need for deep focus and few distractions, concern for efficiency - and wrapped this package under the label of "lack of judgment".
The problem I have with such generalization is that these scenarios are always a bit caricatural and are usually presented in a way that nicely fit the argument.
The experimental developer is required to build simple stuff, but goes to extremes just because he wants to toy with new technology, while the great one is praised for her conservative approach. It also helps that she asks exactly the right questions and receives the right answers.
“How many devices do we expect to have?”
“Well, we hope to sell 500 in 12 months.”
“How often will they need to report in?”
“Roughly once an hour.”
“How reliable is the network?”
“It’ll use WiFi, so fairly reliable.”
In reality, sometimes you ask these questions, you get very accurate answers and based on that, you pick some technology that you believe will spot on address the problem. You might even make the judgment call that you have enough wiggle room to include one or two new concepts you've been curious about, that are yet still very relevant to the task at hand.
Then something happens mid-project and it turns out that what was originally requested wasn't actually what was needed. How many times has that happened?
Two possible conclusions in these situations, for either developers:
- the "rockstar" either looks like a god, for having foreseen some problems, or he'll be the guy who brought a tank to a knife fight.
- whereas the "great developer" will just look incompetent, or she'll just be, well, great.
Judgment is a nice trait for a good developer, but it is subjective. There are some hits and some misses.
What I believe makes a _great_ developer is the fact that they might work to push their own boundaries, which is the reason you're interested in them in the first place, but most importantly, when they do, they stand by their work.
I can't embrace a definition of a great developer, where the primary quality is to avoid causing trouble for the company, the project, the team or their boss. That has almost nothing to do with the discipline. You're describing a "great employee" or a "great team player".
The exact description of a great developer given in this article might absolutely not work in other environments, where developers are required to push the envelope and think outside the box. In such context, your great developer might be thought of as mediocre at best.
- ryan-allen 15y agoI define a great programmer as someone who is prepared to take responsibility for their solutions being effective or not. Can people maintain the system you wrote? Is the system appropriate for what was required? Did you do work that saved the company 50% of their operating costs? Or are you just having a great time farting around being useless and causing damage?
- mekoka 15y agoCan people maintain the system you wrote? Is the system appropriate for what was required? Did you do work that saved the company 50% of their operating costs? Or are you just having a great time farting around being useless and causing damage? I almost wholeheartedly agree with the sentiment. I do however have a problem with it when people that experiment with technology are painted in a way that automatically assigns them with the latter group. A lot of the traits listed as indicator of being a great developer are actually "effects", they don't necessarily warrant that you qualify as "great". Whereas most "causal" traits are relegated under the label "lack of judgment". That is my problem with the essay.
- ryan-allen 15y agoI didn't mean to say that developing with what might be considered 'experimental' tech as inappropriate. I think that sometimes breaking away from 'best practices' and 'how we do things in this company' is exactly the kind of thing that can create significant savings. I think there's a lot of entropy with tools and techniques on the tech industry generally, and more so in actual companies where cultures don't change as rapidly.
- einhverfr 15y agoI am often both playing with experimental technologies and pushing the envelope vs best programming practices. If you look at the approach of LedgerSMB's use of PostgreSQL (see http://ledgersmbdev.blogspot.com/2011/10/design-of-ledgersmb-13s.html http://ledgersmbdev.blogspot.com/2011/10/design-of-ledgersmb... and http://ledgersmbdev.blogspot.com/2011/10/introduction-to-soda.html http://ledgersmbdev.blogspot.com/2011/10/introduction-to-sod... for more) and also being critical of our approaches (see http://ledgersmbdev.blogspot.com/2011/10/soda-in-ledgersmb-13-critical.html http://ledgersmbdev.blogspot.com/2011/10/soda-in-ledgersmb-1...). The thing though is that a lot of this occurs within a framework of evaluating what is not working and rethinking it. On the whole though, this is what pushing the envelope is all about. Note here we are often bucking (rather than embracing) many trends, though we do look to trends to pick pieces that make sense.