This definitely does seem like the Top 10 Traits of a Rockstar Java Developer. Agile, unit tested, gang of four patterns, refactored, usability-engineered.
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.
For once I agree with you. This reads like a description not of the rockstar but of the "team player" that big companies look for.
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.
For your snarky "for once" comment, you owe me a response to this: withholding distaste for the term "rock star", rock star devs:
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.
Great programmers I've known seem to have a narrow rather than a wide sort of ability. They tend to be unbelievably great at some things but maybe know nothing about others. What they all have in common is the ability to have good new ideas, and to write code that works.
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.
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 ;)
What's with this idea of a "Rockstar" developer? Is it just me or is it incredibly stupid. Unless it means:
-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.
The most essential things on that list are #2 (Gets things done) and #8 (writes maintainable code). If the developer is working on the right problem, those two can be rephrased as "creates value" and "preserves value".
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.
Lots of good comments. Why not add to the list "is a MSFT MVP" or "is Java certified," or some other certificate?
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.
---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'.
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.
The problem with 'Software Engineer," with me anyway, is the that the title just reeks of pretension. There is an actual field called software engineering and it refers to an actual development style and methodology and is not synonymous with all-purpose hacking. Despite this, many developers refer to themselves as software engineers even if that isn't what they do, simply because it sounds more important.
"Monkey," "Ninja," etc may be informal, (I don't know how you mean naive,) but it at least doesn't usually imply posturing.
I don't know, a ninja is a lot cooler than an engineer, and while I may or may not get away with calling myself a software engineer (Computer Engineering degree), I certainly don't have any stealth or assassination skills... "Ninja" seems like more posturing to me!
That book takes an unfair beating. I think I could still lose an argument defending it, but if you really want to consider the concept fully, you have to take into account:
- 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.
This is a very good indicator of smart coders indeed, people that don't love to code and are not interested in the beautiful of the code itself will reply "but it already works well, why do you like to modify existing working code?".
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.
You are right. There is an aesthetic beauty in code. Even in complex problems it should be clear and simple. I wish more people could appreciate this. Many times they don't see it, (because it doesn't give any problems) or they they see the finished product and think it was an easy problem. They do not know how hard was to find the simple and clear solution.
"Chapter 1 introduces some of the basic tenets of the book, namely that code is literature and should be read as such. All too often people only read code when they have a specific problem to solve or want to get an example of an API. Instead, if you read code frequently you'll always be learning things and improving your skills. Also, Spinellis discusses the lifecycle of code (including its genesis, maintenance, and reuse), which simply must be taken into account if code is to be good. Poorly skilled developers forget these things and just slap it together, never thinking ahead."
From a review of "Code Reading: The Open Source Perspective"
Another reason to reduce lines of code: every line you write is another chance for a bug (this is the argument that I tend to use to convince people who don't believe in beauty).
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.