Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Number One Trait of a Great Developer

engineyard.com

Post reply on HN
Print view View original

61–70 of 72 posts

Re: The Number One Trait of a Great Developer

#61

Post by jjguy »

I find the volume of defensive comments a little amusing, since three times a day we all vote up and universally agree ideas are cheap and execution is king. The author is drawing the same parallel to characteristics of individuals.

Unlike most of you, I read that and found myself saying "yes!" It's the tortoise and hare argument: good dev teams are disciplined, focused and stable. I suspect the backlash is because it stung a bit, since many here saw themselves in flighty Jack, versus measured Diane. I was there too, but have learned from a few failed projects and disappointed clients. I encourage you to reflect upon yourself a little more carefully; good execution is decidedly unsexy and needs more Diane than Jack.

Re: The Number One Trait of a Great Developer

#62

Post by jt2190 »

rickmb wrote: post #54
Robin_Message wrote: post #52

Earlier quoted context omitted.

> Judgment is a nice trait for a good developer, but it is subjective. There are some hits and some misses. I think you might have missed the point of the article: Good judgement is not subjective; it is about avoiding these "misses".

Methinks you're confusing "good judgement" with clairvoyance. Sure, you can anticipate change, but the decision for how much change you account for in your strategy still remains an educated guess.

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.

Re: The Number One Trait of a Great Developer

#63

Post by va_coder »

One fallacy in this article is the portrayal of the typical "regular programmer". The reality is that many regular programmers would pick something horrible but established in the enterprise like Java Struts or Oracle Web forms, not Rails, because that's "what they know".

Re: The Number One Trait of a Great Developer

#64

Post by einhverfr »

buff-a wrote: post #45
mekoka wrote: post #30

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 devel…

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…

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

Re: The Number One Trait of a Great Developer

#65

Post by einhverfr »

wladimir wrote: post #41
ysilver wrote: post #27

Earlier quoted context omitted.

I agree with the first point. Development is usually a team effort. Effective teams generally play of their strengths. This is probably more important than having a rockstar on board. Isn't simple code inherently more maintainable. I can see it having the problem of lacking scalability, but prematurely building in scalability is the root of all evil...

I agree that premature anything is bad, especially in extreme form, however, your other point needs some elaboration. Isn't simple code inherently more maintainable Verbose, over-simplified code can also be unmaintainable because you lose track of the bigger picture. The only really simple code is small projects, and code that was just written. In the longer run, as features are added, there is always complexity bein…

That's why I have come to define "elegance" as "simplicity perfected."

The best solution is the one which makes use of a number of clear, easily understood, simple solutions in combination to solve a problem. But the wrong approach to simplicity can be as bad as complexity.

Re: The Number One Trait of a Great Developer

#66

Post by einhverfr »

ryan-allen wrote: post #39
mekoka wrote: post #36

Earlier quoted context omitted.

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 assig…

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…

I 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... and 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-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.

Re: The Number One Trait of a Great Developer

#67

Post by einhverfr »

grannyg00se wrote: post #10
danso wrote: post #6

This essay seems to beg the question. A "good" developer, by its definition, is the who picks the most reasonable, easy to maintain technology, because she knows anything "much more complex would be beyond her current skill." Yet, if she is lacking in skill, how can we be sure her judgment is sound on what a "reasonable" and "easy" technology is? Doesn't the basis for that judgment require superstar-like experience a…

I would say that once you reach a certain level you are able to determine which technology is reasonable based on things like language familiarity, community support, and documentation.

Agreed and of course a clear understanding of what the tradeoffs of approaches are. In the end, I think that more than years of experience is the best marker.

I have come into codebases written by a few developers for 20 years that made me think "why don't these people ever get any better?" And when the codebase could function as a textbook of how not to program........

Re: The Number One Trait of a Great Developer

#69

Post by hello_moto »

tjsnyder wrote: post #16
danso wrote: post #11

Earlier quoted context omitted.

Sure, but I wonder if two years in Ruby, or any language, is enough? A superstar dev might go out and try a lot of the new, cool stuff, even when it is needed. But it seems that that developer would also have a grasp of the common characteristics of bad technology. So I think there are at a minimum two good traits of a great developer. The rockstar-like quality of having the skill, curiosity, and breadth of knowledge…

Two years? I think you can learn everything you ever needed to know about a language in a much shorter time period than that.

It depends to whom you're asking this question. Some people have high standard than others.

I wouldn't bet a consulting project performing integration of various systems using Ruby if the programmers on my team average of 2 years "side-project" Ruby/Rails.

I still wouldn't bet on Ruby developers with 2 years of experience on certain type of web-apps either unless I've seen their code, code style, discipline, judgement, etc.

I would trust a Ruby developer who got burned by some of the Ruby tricks though.

Case and point (or anecdotes):

I recently brought in a veteran Java, 2 year-ish Ruby/Rails, and 1 year-ish JS (thanks to Node.js and Crockford "The Good Parts") programmer to help us working on some of the JavaScript codebase. Java knowledge is intermediate despite the number of years(I consider deep JVM and standard JDK knowledge around hard-to-use packages such as NIO, Thread, Networking as expert, other than that, just intermediate). Pragmatic guy. Understand OOP and its gotchas.

I made an observation of her work in Ruby and JS. On the JS side, she wrote much more code than needed and my gut feeling tells me that she does this to increase her experience using JS. Kinda using it as a playground.

On the Ruby side, certain bad OO practice tends to be a little bit more accepted by her. Where as she would be critical when it comes to bad OO practice in Java.

Hence this is why I would prefer to observe developer's attitude more as oppose to the experience level. Because sometime 1-2 years are considered as "Honeymoon" period where everything looks fine and dandy. As soon as the honeymoon is over and your significant others start to show its true colour, then you're back down to the earth again.

Post reply on HN