Engine Yard Cloud

That’s excellent Tammer. Wholeheartedly agree. Especially the beer part. Mmm.

This subject has been on my mind a LOT lately and you’re spot on. The glory boys (and girls) can have fun with all the new toys, I’d rather use the right tool for the job than the “new hotness”.

I agree completely. My hiring process includes judgement tests. The amount of impact a single developer can have on a company and a code base is so high that a severe lack of judgement can cause problems that last years and cost a lot of money.

This is especially true with senior developers, or developers who have little oversight or collaboration with people in companies who have proven themselves to be trustworthy, diligent and able to make sound decisions.

I’ve spent the last two weeks cleaning up messes from developers who quite honestly, should never be allowed to write code ever again. If anyone asked me if this developer should be hired I would honestly be professionally negligent if I were to advise anything other than “Do not trust this person even to hold an umbrella for you while you tie your shoes.”.

But people like this manage to move from company to company anyway, screwing over customers one project at a time while doing just enough to be able to plausibly deny any negligence  malice or inappropriate behaviour.

So, what do you do with the developers who are trustworthy and have repeatedly demonstrated the application of sound judgement? You pay them double industry rates. You do what you can to keep them. Because once they’re gone, the only way you’re gonna find another true start is the hard way.

The industry is full of charlatans and I don’t see it changing any time soon.

Sounds like you’re setting up a false dichotomy: great developers /do/ ask the questions up front, use the right tools for the job, and are keenly aware of maintainability. These important ideas are discussed at conferences, on blogs, twitter, etc. Do you really come across “Rockstar” developers who don’t ask questions up front, and don’t consider maintainability?

stopped reading after: “postgres would have been better”. Sir, it’s this that makes you a fanboi.

I agree. I’ve always phrased it as the best programmers are lazy, but I think we’re saying the same thing.

You make a good point. I think a good developer is one who steps back and wonders what the goal is before attempting to do anything.

I’m guessing you meant unwary and not unweary (which is not a word).

What is the definition of “sound judgement” and how do we measure it? Do we actually have a common understanding of what it means? At the very least, we would need examples and counterexamples, in order to delineate sufficiently precisely what it means, for “sound judgement” to be testable.

The author uses the choice of node.js as a counterexample for “sound judgement”. Even though I see what he means, I am not entirely convinced that all developers using node.js in their projects, lack sound judgement. Therefore, I am not willing to accept this as a valid counterexample for “sound judgement”.

Apparently, “sound judgement” should include a profound and naturally ingrained resentment for “Google Protocol Buffers”. Again, I must admit that I am not sufficiently convinced to accept this as a solid counterexample either, even though I must concede to see some merit in the attempt. 

Developer recruiters who try to implement the recommendations of an article like this, will probably go about applying their particular view on “sound judgement” during interviews, by trying to trap candidates with questions on their likes and dislikes for things like node.js, NoSQL, or “Google Protocol Buffers”, and conclude that:

“The candidate has no sound judgement, because he likes Cassandra and PostgreSQL. We cannot use this person in our team.”

I personally do not believe that implementing this recommendation will improve the situation for the recruiter and the team using his services.

10,000 requests per hour, so 166 per minute. Well within the capability of Sinatra and MySQL.

Agreed that judgement is important, but I think that your example is an example of poor judgement.  Sinatra and protocol buffers were both introduced publicly in 2008, so neither is particularly old (read stable).  Protocol buffers at least the release was an open-sourcing of a de-facto internal google tech so it will probably stay more stable.

>> Judgement

I don’t want to be too judgmental here, but the word – in American English – is spelled “judgment”.

http://public.wsu.edu/~brians/errors/judgement.html
http://en.wikipedia.org/wiki/Judgment_%28disambiguation%29

You’d be surprised…

“since 2008″ is like two decades in computer years…

What do you consider stable, Java 1.3?

That’s why I need some off to work on personal projects: I can have have an overdesigning-experimenting-trend-following-binge. Then, when I come back to paid projects, I can use my good judgement again. It’s well rested then. 

Somethings I do not agree.

Dev should use the tools that feels confident and this means to know its limitation and judge if it is suitable or not for that app.
Otherwise coder will spend half time googling snipers and learning about that new commands, and the other half debugging , and writings the actual code.
I’m not agaist googling for help, I see it more as a social coding era,
But if I want to compose a rap song , I won’t hire an opera singer…right… I just need to ask can you rape or just not? Do you have the tools or not.

“stopped reading after: “postgres would have been better”.” Sir, it’s this that makes you a fanboi.

“Jack makes a point of starting each project with at least three new technologies.”
Jack doesn’t “know” Google Protocol Buffers, node.js, and Cassandra enough to make a maintainable project.  DIane chooses what she’s familiar with. The bias in the article is not against the technologies but in the characters probably as a representation of the author. The author probably doesn’t “know” Google Protocol Buffers, node.js, and Cassandra so when he searched for examples those are the technologies he comes up with. The author probably “knows” MySQL which is why he came up with that example for Diane.

I highly doubt that the author wants you to consider the actual technologies whose only purpose is to serve as examples. Whats important is that Jack went overboard with technology he wasn’t familiar with (hint: totally unmaintainable) and Diane who believed PostGres would’ve been better decided to use MySQL because she was familiar with it.

He may have been using it as an example. She used MySQL—which she knew more about—despite knowing Postgres was better suited to the problem.

I see this story As a metaphor for any “artist vs. painter” comparison. The “artist” is rarely interested in making something that pleases other people. Whereas the “painter” wants to please their client and get hired again. The artist is usually more skilled, but the client has less control over the outcome. With an “artist”, you’ll be able to claim your system is “cutting edge”. As a client, you should be aware of your options and pick your battles.

Completely agree.

Employees with good judgment are the rarest and most valuable commodity any organization can have.
Find them. Keep them. Cherish them.

Americans don’t know what the hell they are talking about, so it’s ok.

If you discount something only because it is ‘the new hotness’, you may be passing over the right tool for the job. Hype shouldn’t factor into technical decisions at all.

No, that just makes him right.

heh… when asked to speak about myself I often reply and either being lazy or efficient.  :)

Least favorite part about Ruby on Rails? Creating “Hello world” installs 7 billion files.

I don’t understand your example at all.

If Jack’s solution is “elegant”, how is it also “totally unmaintainable”?  In my experience, an elegant solution is far more maintainable than an inelegant one.  Diane’s example is described as “simple, easy to understand, and highly maintainable”, which is precisely what I would call “elegant”, but apparently you think it’s the opposite.If Diane sticks with what she knows because it’s reliable for her, then why did she ever learn Rails?  Synchronizing kitchen devices isn’t exactly its strength.Cougar is a phenomenal developer.  He’s been using Perl since 1988 and NetBSD since 1993 (before either Javascript or Ruby was invented).  When confronted with a simple synchronization problem, he wrote 10 lines of Perl and then went out for a beer, where he laughed about people playing with database servers and frameworks and newfangled languages.  They’re “elegant”, whatever that means, but it’s hard to get more maintainable than a program so small it fits on one screen, and are trivial to debug because they simply use plain text files.

I think two things! The world needs both kinds of people. There is a time and a place for everything.

Dan

The world does not all speak American English.

I think the problem can perfectly well be solved by requiring developers to seek approval from their team leader, for new technologies they propose to use in their projects. In my impression, the problem with Jack, is more one of lack of oversight by management, than one of sound judgement.

The coding world does.

Great post, I wish I could double vote up your post in Dzone :) Cheers

Oh, I can rape, alright.

I wish people would stop using the term “Rockstar” in reference to programmers. For a start, there are no rockstar programmers. If you’re in programming for the fame then…well…wrong profession, we’ve only got one John Carmack and he builds rockets now.

Secondly, for what piddling similarity there is left between “Rockstar” and programming, everyone interprets it differently. For some it’s the temper tantrums and diva nature, for others it’s the skewed productivity rate.

Use a real term, and then you’ll discover that what you though was a debate disappears. You want a productive coder? a cutting edge coder? you want someone who can solve your problems in half the time or someone who delivers code that’s understandable by a monkey?

Each of these are different skills, programming is not sprinting, there is no single 100m time to serve as a metric for whether someone is great or not. Some coders are great because they have an enormous base of experience with a myriad of technologies – that comes at a price, others are good because they obsess about producing code that is crystal clear – that also comes at a price.

Yes being aware of your limitations and not going for the cool toys just because they’re cool is a fine thing, but Dianne is no use to you long term, because the same reasoning that led her to use MySQL this time will lead her to use MySQL next time, and the time after that, she will never be comfortable with PostgreSQL until someone makes her use it against her better “judgement”.

Stop trying to find some kind of magic personality attribute that indicates a great coder. You have all the information you need, because there is only one half-reliable indicator of the ability to deliver, and that is having delivered before. Stop monkeying about with your judgement of their judgement or what their approach is to technology choices – unless you’re a great coder yourself you really aren’t in any position to judge that shit anyway.

Just go find what they’ve done before, go over it with a fine toothed comb, ask them about it. If the studies are true, if great programmers really are tens, hundreds or even thousands of times more effective than merely average, they will so visibly stand out that you cannot possibly mistake them for anything but.

If you’re not absolutely convinced the person you’re hiring is an utter wizard, then that’s because they’re not – you’ll never mistake one for a regular coder once you’ve seen their work. 

That’s not always a bad thing. Regular coders can code too, and they’re much cheaper (and often easier to manage). If they have good judgement, that’s a nice plus.

Not sure if you’re trolling or you missed the point.

The things i always worry about is managing complexity, aka maintainability. Can you have a new and amazingly cool new framework, and will you be able to maintain it when it breaks, or something goes wrong. When it breaks, will it just suddenly start working and you having even a minute idea as to why it broke in the first place, or did you just reboot your system and it works like magic.

Between the lines I read a couple of ideas that I don’t like:

1. Hire to sustain a mediocre team. Nothing exceptional has ever been made with this mentality.

2. Be a laggard. You DO want brilliant developers to follow the latest trends, and take the relevant calculated risks. The “good enough” mentality is as much risk aversive as risk prone.

Taking into account the fact that “judgement” is unquantifiable, it looks like this mostly a personal complaint than an overall good practice.

But maybe this is just how I read it :)

I think Jeremy’s point is that the boring solution is actually more formidable than we might be giving it credit for. That makes the justification of using leading edge tech even less clear and the Rockstar’s approach even more questionable.

Professionals do not approach production work as a thrill-seeking exercise or an opportunity to show off. They start by asking what the goal is and then matching it to the lowest risk, most expedient solutions. This means that they often use highly capable but boringly mainstream tech. Isn’t this what the article was about?

This coding Canadian disagrees, although I am not surprised at your opinion. Even if it were true, correcting people on the spelling of words that are correctly spelled in the Queen’s English shows  poor judgement in itself.

I will say though that a lot of people are too lazy (myself included sometimes) to fight their US English dictionaries that are installed with their software by default.

– Removed as I posted it in the wrong place –

 I just want to point out that I said “often”. Sometimes the new hotness
is truly so much superior that the tried and true approach really should
immediately become legacy. This is the case a lot less often that many
developers assert though.

Spot on! I just wrote a post about how judgement played an important role in my ex-military life, and how it manifests itself in the business of software. http://www.adnanymous.com/2011/11/spj-sense-of-proportion-and-judgement/

imo, a programmer venturing into new technology and tools must always provide extensive test coverage.

Must use as minimal working part solutions as possible.

Must educate other team or ‘sell’ the technology used to other team members.

Judgment involves more than that.  As a lead I have to constantly explain “why”.  And when you talk to other developers, you frequently find out they have no clue what they are doing.  Making simple choices may seem like judgment at first.  Intuition might be a better word.  But in the end most developers reason for their choices are random and unbalanced and designed to increase their personal comfort level.

People are sheep.  A sheep can be safe.  But a sheep is a sheep you will eventually be sitting around waiting for it to grow some more wool and there wont be time.

What I would call judgment is a little more subtle.  The experience to know when something you are doing is GOING TO FAIL due to adopting horseshit tools like Rails and bullshit databases like MySQL.  When you know those answers up front, you dont fuck your customer.

[...] 发布时间：2011-11-7 08:35     来源：博客园     分类： 程序员 都等你发言 :) 分享到： 博客文章顶部右侧 公司在招聘程序员时，可能更注重开发者是否聪明，是否有深厚的开发技能等，但 Tammer Saleh 在 EngineYard 中发表文章《The Number One Trait of a Great Developer》中表示，判断力才是一名出色开发者所应具有的首要特征。下面是对该文的译文： [...]

While I completely agree with your general point about judgement, I think those 2 very extreme examples don’t suit it particularily well. Embracing fancy technical solutions just for the sake of it like Jack does is in my opionion just as bad as completely denying innovation like Dianne does.

A good portion of judgemental quality in my opinion is being aware of other technical options than those you already know and embracing them when you see fit. If you, for example, heard about this fancy new NoSQL db and, of course after getting more information on it than just the general buzz on the net, consider the risk of the project failing because of it minimal, I think it is perfectly fine to pour it into projects where it fits, evaluating and discussing what the takeaway is afterwards. You and your coworkers will learn a lot and maybe even choose to go down that path again next time. Of course you should not try to build all of the application with fancy new things you just read about on twitter – if you think the risk is manageable just pour a little bit in here, a little bit in there, and see how it went. Especially on small one-off projects like internal tools I think this is a great way to try out new things, extend your toolbox, learn and start fruitful discussions.

From what I understand you expect innovation to happen “outside work hours”, developers only being “allowed” to use some non-mainstream tech if they already know it inside-out from some personal playing. For most developers, I don’t think that is a good path to go down, since it essentially kills of all sparks of innovation in your work environment. While there are coders who love to tinker as soon as they get home, most of them go back to a family, kids, or some other kind of social life and therefore relying on innovation coming in from “outside” in my opinion just let’s it slowly die.

Identifying those cases where you can play with some new tech is just as important as knowing when to better stick to your established skills and not go into any risk at all and to me indicates shows great judgement in a developer.

There are cases where one database can be better than the others: for example, two years ago I had a project that needed to do heavy spatial operations; postgresql was a better fit for that, even if it’s not the only solution: in this specific case, it was just the better compromise, despite I came from a mostly MySQL and Oracle background at the time, so maybe it was not a simple fanboy comment.

Rockstars are people with guitars. Speaking as a web developer, the inappropriate use of the term ‘rockstar’ just makes us all sound gimpier than we do already.

“Jack talks about all the latest trends at all the coolest conferences around the world.”

Nothing wrong with that as long as you keep experimentations to your time to avoid putting customer projects in danger. On the contrary, thanks to curiosity, you may become aware of solutions to the problems you face that would not have even occured to you otherwise.

That’s why it’s imho important to have side projects, otherwise you can never keep up with what could potentially save you tons of work if you had known about it (or even what is going to make the technologies you’re working on obsolete), that’s why I personally explicitely keep 20% of my revenues and time for such research.

The best judgement calls have data to back them up.

lol love the arrogant response. No, the coding world doesn’t speak “American English” (what the hell is American English, so in Belize it’s Central American English?). The coding world speaks English as given by England. English… England.. get it?

This reminds me of the one single Ted Dziuba article that I can stomach reading. 
http://teddziuba.com/2010/10/taco-bell-programming.html 

The point is that you don’t always need to the latest greatest thing. I would call Dianne a great programmer as long as, at some point fairly soon she did a side project or spent some time reading about Postgres.

She needs to come out of her comfort zone and grow. If I were Dianne it sounds like I have a great background with Unix and now have a solid understanding of Ruby I think it might be time to try something like SICP or 7 languages in 7 weeks.

I realize Dianne is completely fictional but as phirate said, unless she or someone else forces her out of her comfort zone once in awhile she’s going to become stale.

“… their US English dictionaries that are installed with their software by default.”

Thus proving that the world does generally speak US English when it comes to computers/software … or coding!

“I just need to ask can you rape or just not? …”

Seriously, check what you’re posting BEFORE you post it … one little vowel can cause so much trouble!

Maybe the best programmers aren’t those who spectacularly solve crazy problems

I think Dianne decided to use technologies and tools familiar to most of the fulltime developers at this company, whereas Jack decided to use (possibly appropriate) tools that are completely foreign to everyone at this particular company.  Imagine if the next 10- 15 contractors decide to “be like Jack” and use different technologies for the next 10 – 15 projects!

The fulltime developers will be unable to do more than simple maintenance to any of these in-house applications.  New features will usually “require” re-writes.  Individual developers who know a bit more about a particular technology will become fully responsible for a whole set of products using that technology. People will panic if a reboot doesn’t solve a problem in the whatchamacallit module using that funky thingmajig technology.

I would prefer to maintain and evolve the minimal-number-of-moving-parts product developed by Dianne than to try to decipher the how-on-hearth-does-that-work thing that Jack put together in 2 weeks and then was gone before he could transfer his knowledge…

Jack cares about his CV, because companies do not really care about Jacks and Dianas.

is “spelt” judgment.
not spelled..

Just gonna write some css quickly

h1 {
color: #fff;
}

Shouldn’t that be colour, if we’re speaking English? 

Unfortunately English has been bastardised by Americans and we now have two languages which are very similar in pronunciation but differ in spelling.

If I was to ask someone a question, should I be asking their favourite colour or their favorite color?

I’m English, so I’ll stick to favourite colour.

Great write-up! I always interview with judgement as the front and center thing I am looking for. This doesn’t just apply to developers, but project managers, engineering managers, etc too. Good people are usually the ones who talk ideas (passionately but not zelously), draw heavily on their experience (don’t jump around in their toolset), and leave the buzzwords out of the conversation. 

That’s Because the Americans are generally the one’s who is the producer of “defaulted” software.

I used to rant about “It’s the Business, Stupid” in conferences, implying that we should be solving problems for our clients, not simply playing with the next shiny toy. Sure, I love shiny toys, and I love to play with them — especially when they make sense within the context of solving a problem. But your scenario is an oft-spotted pattern where folks lack the engineering skills required to build right-sized solutions to meet the here-and-now needs.

And of course, anyone can come up with a complex solution that sprawls across multiple cubicle walls on e-size plotter paper (that’s easy). Only a rare few can come up with the minimalist solution that meets the needs of the business, and can easily grow over time.

As far as hiring, I like to look for the “engineering” mind. After all, engineers put man on the moon, not scientists.

Great post!

[...] read this very good post “The Number One Trait of a Great Developer” by Tammer Saleh at Engine Yard, and it made me [...]

Well, it depends if you want to innovate or only to solve problems.

If you want only to solve problems: hire for judgement
If you want to innovate: hire a diverse team where good judgement sometimes is put aside.

[...] 公司在招聘程序员时，可能更注重开发者是否聪明，是否有深厚的开发技能等，但Tammer Saleh在EngineYard中发表文章《The Number One Trait of a Great Developer》中表示，判断力才是一名出色开发者所应具有的首要特征。下面是对该文的译文： [...]

[...] Great blog post from Tammer Saleh on the number one trait for a developer: http://www.engineyard.com/blog/2011/the-number-one-trait-of-a-great-developer/ [...]