31–40 of 72 posts
When I do my first interview (as the interviewer) one day, I'm going to ask "Do you read blogs by software developers?" and if they answer "Yes", I will not hire them because these blogs are a bunch of horse shit.
Blogs like Coding Horror and Object Mentor should gain your respect, not your disdain.
What this article is saying is you need someone with experience to make the right judgement. This means you need to find someone that has already gone on the 5-8 year roller coaster that a developer goes through. This from the 'just get something working', to astronaut over-architecture, to practicality that might come with running many projects and being through many successes and failures. A good developer might be…
So perhaps n years of experience is a cludgy filter for the relative graybeards who understand that technology is just a tool, not an end in itself.
This article is totally true, but almost impossible to act on. It's very very hard to differentiate people who have a passion for doing good work and people who just like to play with the latest trendy technology. Especially since the latter is often just an immature stage of the former.
This is actually a big reason why non-trendy technologies persist - indeed, why they often thrive in the larger marketplace precisely at the moment that they become least sexy and fall off the geek radar. Non-trendiness is a market signal of its own. There's a lot less noise in the backwaters, and those products which survive to become boring have demonstrated staying power. People obviously aren't using them for fun, or because they're easy to promote on popular blogs, or because VCs can impress each other by dropping their names. They must have survived for another reason. Perhaps they are... pragmatic, useful, or cost-effective?
This strategy must be used in moderation, of course. The final stage of nontrendiness is obsolescence and death; You don't want to hire those who are expert only in obsolete things. (Oh, my IE6-CSS-hacking skills will soon have no market value. Thank goodness!)
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…
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?
Earlier quoted context omitted.
What dichotomy? Are you being misled by the fact that the article uses only two examples? That's a rhetorical shortcut, not a proposed dichotomy. The article does not actually claim that "those who use Sexy Tech X tend to have bad judgement" or anything like that. What it says is that folks with good judgement use appropriate tools for appropriate reasons, which may be situational.
I'm not making a rhetorical argument. You should take me seriously. The article stereotypes "rock star" developers as being obsessed with using the latest tools and compares them to more "average developers" who (it is claimed) better know their limits and ship more maintainable products. I believe that this is a false dichotomy. There are plenty of "rock star" developers who ship maintainable products which use appr…
Let me see if I can make this boring enough to understand. Let's draw a classic management-consulting two-by-two matrix:
GENIUS-JUDGEMENT GENIUS+JUDGEMENT
AVG-JUDGEMENT AVG + JUDGEMENT
Of course, if the original blog post used my four examples it would be as dull as... management consulting. The moral of this story is that writing is hard. You have to leave some ambiguity, and trust the reader to fill in the gaps, and hope the gaps are not too large, and that your sly invocation of the trendy-yet-pragmatic NoSQL user in the penultimate paragraph helps people take the hint. But sometimes the whole thing just doesn't work. C'est la vie.
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…
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?
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.
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.
Similarly, Ruby has many different little variants -- Rails, Rake, various sorts of DSLs -- and that adds significantly to the time to learn it.
Really learning Ruby is learning several similar languages, which makes two years a much harder number to achieve.
C++ could easily have been like that if it had different constellations of features that were routinely used in different ways by the same programmers. Imagine if there were a whole "C++ tools" subculture that used templates extensively but differently, along with one or two other nontrivial features (say, multiple inheritance and exceptions) used in specific ways with specific non-compiler-mandated rules.
You'd have to learn, in effect, about another programming language's worth of material to program fluently within that subculture.
Ruby has several of those.
Don't just routinely foist gobs of data off onto others; you were hired for your brain. Use it.
Earlier quoted context omitted.
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 assig…
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.