3 ms·

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 t

by buff-a 15y ago

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.

einhverfr 15y ago
"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.
- buff-a 15y ago
  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".
mekoka 15y ago
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.

by buff-a 15y ago

einhverfr 15y ago

"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.

buff-a 15y ago
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".

mekoka 15y ago

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.