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.
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.
Fights over. The guy with the knife killed you while you were putting the treads on. Meanwhile, the guy with the knife discovered that his customers actually wanted something else because they could run the first iteration of the actual product while you were worrying about scaling to a million customers. Maybe the customer is in the steak-house business, but you just stopped reading at "customer wants knives", got a hard-on and started building tanks.
Then something happens mid-project and it turns out that what was originally requested wasn't actually what was needed.
So you advocate over-engineering a just-in-case tour-de-force, instead of agile, iterative, responsive development. How are you getting up votes????
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"
Not so. The post listed traits found in very prominent in hackers but also found in ineffective, inexperienced hackers. And advised that to focus on just those traits is wrong. The key trait that separates these two groups is judgement. A "prominent hacker" will use the right tool for the job, right now.
"So you advocate over-engineering a just-in-case tour-de-force, instead of agile, iterative, responsive development. How are you getting up votes????"
There's a time and a place for heavy engineering, and a time and place for agile, iterative development, and sometimes both have times and places in the same project.
One element of good judgement is realizing what the tradeoffs between older and trendier development methodologies are, and then navigating them intelligently.
For example, the direction LedgerSMB is moving is towards a heavily engineered, intelligent database with a well-engineered API, and a more agile application built on this framework. The database engineering (esp. in an accounting app) needs to be done right and account for a lot of "just in case" while the actual application running on the database should be able to be customized relatively easily.
Its funny, because the only code I write that is 100% TDD is the stuff that has to be done right. "Heavy Engineering" without agile, iterative development is actually just "Heavy Wishful Thinking", or "Heavy Waterfall".
Fights over. The guy with the knife killed you while you were putting the treads on[...]
This could go both ways actually. I'm sure even you could come up with some concrete examples of behemoths that came into an industry and just annihilated the competition, because they decided to go the extra mile, when everybody else had a myopic vision. FYI, the tank to the knife fight is not an approach that I necessarily embrace or advocate for. I'm merely stating here that vilifying the practice of foreseeing something bigger, as a counter-example of what constitute a "great" developer, doesn't necessarily work. Tell me a great developer has good judgment, just don't go as far as listing a developer's fascination for technology as a pathology. If it can be good, then leave it as an inconclusive attitude whose outcome is highly dependent on the dev's said judgment, or lack thereof and her ability to carry out the execution of what she undertook.
So you advocate over-engineering a just-in-case tour-de-force, instead of agile, iterative, responsive development. How are you getting up votes????
Nobody here advocates over-engineering, the term in itself is negative and the practice indefensible. My position is that "over-engineering" is a subjective thing, like judgment. You think we need a tunnel, I say we should build a bridge. We foresee different things, but the need is still to get across. Does our difference of opinion qualify you as "great"? The point of the segment you're referring to was that it is possible for something that was originally labeled "over-engineering" to become, in the right circumstances, "sound engineering".
The post listed traits found in very prominent in hackers but also found in ineffective, inexperienced hackers.
This is one problem I have with the article. Here's a specific excerpt:
[...]When given what has the oportunity to be a “fun problem,” developers without judgement tend to run to their cave to craft the most elegant solution possible. They have a natural desire to over design the solution either in terms of flexibility, speed, feature scope, or simply to get a chance to play with their new pet technology. They need to be constantly checked on to make sure they aren’t half way down a rabbit hole[...]
How many bad hackers have you encountered that were concerned with such things as flexibility, speed or feature scope? The description here is crafted in a way that superimpose hackers clichés with bad judgment. It doesn't segregate good or bad hackers, but it grabs traits that are generally seen as beneficial and just displays them in a bad light. It doesn't say "They have a natural desire to design the solution in terms of flexibility", but rather "They have a natural desire to _over design_" That, is my problem with it. You can make Dianne look good by all means, but you shouldn't have to make Jake look bad in order to do it (btw Jake is supposed to be a rockstar. Last time I checked, in the tech community, this is a guy who's taken his craft to new depths. As far inexperienced and ineffective go, this falls short).
I agree 100% that a prominent hacker uses the right tool for the job, but that's an effect, not a cause, of being a great hacker.
I 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?
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?
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.
I 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.
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.
When it comes to software engineering, I always think back to my first year Calculus teacher, Mike Lavender, and his admonishment that "in mathematics, power tools are consider inelegant where hand tools will do." Words to live by in programming and engineering.
So I'd go so far as to redefine elegance in software programming and engineering as "simplicity perfected." The simple fact is that where requirements change, a well engineered simple solution will usually turn out to be more agile than a heavily engineered, complex one (whether programmed with "agile" methodologies or not).
When one takes the idea of trying to perfect simplicity in the art of programming (and software engineering), it becomes easier to recognize foot-guns and inherent problems, and tradeoffs often become more conscious and controlled.
So while my view is slightly different from the article, it's difference is perhaps one of nuance rather than substance.
I think the post could swap "developer" for "hacker" - where you seem to be switching "great" for "hacker".
I think what you are saying sort of agrees with the post. A bad hacker will make a mess, a great hacker exhibits judgement - and brings in new technologies because they are the right solution.
Indeed, the post says nothing about the great developers experience with Sinatra... perhaps it was what she always used. Or perhaps she knew a little about it, and realised it was the most effective tool to use (and therefore used it for the first time).
What the post is talking about is the bad rockstar hacker who doesn't ask the right questions (lacks judgement), trys to over engineer the solution (lacks judgement), uses new technologies for the sake of it (lacks judgement).
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 post is talking about the aspects that make a great developer.. working in a company.
I think they are right; they need a developer with the judgement to find out what the company needs, build a solution with effective tools and who has the ability to iterate as the spec develops. All of that ties to having good judgement.
Not someone who gets all enthused with the latest tools and delivers a much more elaborate solution :)
From the perspective of hiring or contracting a new developer someone who doesn't cause trouble in that way is a good thing. Especially as what the post describes is someone who actively produces solutions instead!
In my experience many excellent hackers don't even try to make the educated guess about how much change to account for. The Hacker assumes that the system must handle various far-off scenarios which gives them an excuse to play with [insert tech here]. Or the Hacker assumes that "the business" has thought of the best strategy for dealing with various technology issues that might occur (as if non-technical types could really do that), which gives them the ability to say they were just doing what they were told.
The industry conditions Hackers to avoid thinking strategically, at least in part. The Junior Hacker is browbeaten for not thinking of every possible scenario when things go wrong, however unlikely. The Junior Hacker is rewarded for following the directions of their technical supervisors to the letter without thinking. It shouldn't surprise anyone that by the time the Hacker is promoted to Senior Hacker, they have little experience designing and developing software that will ship quickly, not be a maintenance burden, and can adapt to success if it comes.
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.