Top 10 Traits of a Rockstar Software Engineer
readwriteweb.com
readwriteweb.com
I guess my favorite part is that it ends in "knows basic computer science". Yeah, that's good to know. Also, the rest of computer science can come in handy. But definitely, read Getting Things Done and Refactoring first; that'll definitely be more helpful than LALR parsing for getting forms hooked up to databases.
Not only are many of the items on this list wrong ("Uses design patterns" should be replaced by "Laughs at the phrase 'design patterns'"), it's missing the defining quality of the really great programmer: Redefines the problem.
1. Can estimate accurately.
2. Can solve problems involving graphs.
3. Can frame and solve problems compiler-theoretically, including parsing, domain-specific languages, and virtual machines.
4. Can code bare metal and understand the memory hierarchy well enough to know when that makes sense.
5. Can assess whether a problem is going to be compute bound or IO bound and plan accordingly.
6. May or may not write code that is easy to read ("maintainable"), but tend to write code that is extensible.
7. Understand caching, load balancing, and compression.
8. Can work with large data sets.
9. May or may not formally unit test, but can debug fast and can design code to be debugged.
10. Steal ideas from other strong projects (implying also that they read and evaluate other people's code).
Obvious caveats: I'm not one, but lists like this are always biased. "A rock star developer looks exactly like the ideal me!". Like with the original list, I could easily put a book to each of these.
A comment thread with nothing but people's lists would be fun to read.
All the things on your list seem reasonable, except for numbers 1 and 5. In my experience, great programmers know that the world is so surprising that they tend to avoid even trying to estimate things. They may try to predict at a coarse granularity, but beyond that they just try to set things up so they can easily change their minds later when their predictions turn out to be wrong.
Mmm... moreover the article seems to be a bit biased toward Java that is not exactly the rockstar software engineer preferred language.
-Is so successful and in demand that he can do whatever he wants, and set his own rules.
-Makes a ton of money, at least millions of dollars per year.
-Is a household name, at least among some circles. People get excited by a software project just because he is involved.
-Has enough social status to get many women.
-Uses drugs.
I don't think there are many software guys in this category. John Carmack and John Romero in their heyday is what I'd have in mind, or Richard Garriot (I mean come on, he built a castle!), or Sid Meyer. Or Linus of course.
Yup. The only people I've worked with who thought they were rock stars were, in fact, prima donnas: temperamental, difficult to work with, unlikely to help. I'd hire programmers in the same way I vote for politicians: look for the boring, able, hard-working ones, because they'll be a lot less trouble than the exciting, mercurial, "I'm so gifted I don't have to try" ones ;)
A good developer will do all the other things to the degree they matter for #2 and #8 in their environment. Some places need ubertesters and others need polyglots.
I cringe at the title 'Software Engineer' coming from an engineering background
---Ha. What's wrong with engineer? I actually cringe when I see Code Ninja, Pirate, Monkey, or whatever. Very juvenile. Sure, I am a programmer, software engineer, I can hack, and all that. But Ninja? WTF? It must be an american thing. Maybe kids in here were raised watching Ninja Turtles, and that's a wait to attract them, but seriously, it is just very juvenile and naive'.
"Monkey," "Ninja," etc may be informal, (I don't know how you mean naive,) but it at least doesn't usually imply posturing.
Sometimes these terms are pretty funny and alive when first coined, then die off and become cringeworthy. There are degrees of cringe, too, like the circles of Inferno. You know you're reaching the inner circles when articles start to appear like "How to Keep Your Code Ninja Happy: A Manager's Guide" :)
I wonder if it's an American thing or a programmer thing. Software development is still new and widely misunderstood, and most metaphors to existing disciplines suck. That's the real problem with "software engineer" (as it is with "software architect"). So people come up with wacky terms that are free of entrenched connotations and convey a playful creativity that's actually closer to what good programmers do. But they're disposable. Once the novelty is gone, so is the reason for using the term in the first place.
Edit: "hacker" is an interesting case. It's been around long enough to have had all the life sucked out of it and yet it lives. Perhaps that's because the term (as used here) shadows a more exoteric usage that's sinister and scares the corporate types away.
This list is a checklist of the mediocrity that the programmer has been reduced to. Everybody is a great programmer now, and everybody uses java or C#, and knows about all the latest skinnable components or whatever.
Lower the bar, attract more people to become programmers because they're tired of working in QA and seeing the programmers make more money, provide the clueless bosses with business degrees with simple checklist metrics (like that list), and voila!, a whole industry of books, seminars, cert programs, and finally, Sun and MSFT maintain their mindshare takeaways.
This is all part of the shadow industry that props up the hardly legitimate software development industry. That's my conspiracy theory and I'm sticking to it.
Knows basic computer science?!? WTF. You don't need to memorize Knuth, but knowing more than basic computer science is pretty important.
- Alexander's "The Timeless Way Of Building", from which it borrows the concept of defining a vocabulary of design based on small, proven ideas applied fluidly --- where the GoF misfired was that Alexander's book has hundreds of patterns, and they only have like 15, which made the GoF patterns seem more brittle and simplistic than the concept they were talking about really is. Go read Alexander before laughing at Patterns.
- The extended "Patterns" movement, which can only be an improvement over (gag) OOPSLA --- for a credible application of the idea, see Schmidt's Pattern-Oriented Network Software books. Schmidt (of ACE/TAO infamy) managed to use the Pattern concept to discuss some valuable ideas in concurrency and distributed systems, and I still refer back to those books.
Good. At least I'm not the only obsessive compulsive refactorer.
Of course the reason is that you can make it 1/2 the lines of code (or even better, sometimes it happened to me to reduce a 30 lines existing code function to 4 lines of code), more modular, trivial to understand even after 6 months and more beautiful.
From a review of "Code Reading: The Open Source Perspective"
http://books.slashdot.org/article.pl?sid=05/03/02/1951204
I was reading this book in the bookstore the other day (too expensive to buy).
See also: "Beautiful Code: Leading Programmers Explain How They Think"
// Mozart