Ask Slashdot: What Makes a Great Software Developer?

Nerval's Lobster writes: What does it take to become a great — or even just a good — software developer? According to developer Michael O. Church's posting on Quora (later posted on LifeHacker), it's a long list: great developers are unafraid to learn on the job, manage their careers aggressively, know the politics of software development (which he refers to as 'CS666'), avoid long days when feasible, and can tell fads from technologies that actually endure... and those are just a few of his points. Over at Salsita Software's corporate blog, meanwhile, CEO and founder Matthew Gertner boils it all down to a single point: experienced programmers and developers know when to slow down. What do you think separates the great developers from the not-so-fantastic ones?

Comments

Levels

[phantomfive]

First level is to be able to get the computer to do what you want. If you can do that, you have a career as a programmer.

Most people don't make it that far, so it's something. The next level is whether you can write readable code. A lot of programmers never learn to write readable code, but a good number of them do.

The next step is writing flexible software. Some programmers stuff everything into design patterns and think they made it flexible, but they're wrong. Other programmers try to make everything generic thinking it's flexible, but they're wrong (also, their code is probably hard to read). But writing code where small changes take little effort, and bigger changes take more effort......that is a rare skill indeed.

There are other ways of looking at it, but that's one way.

Re:Levels

[Anrego]

To be honest, I think a "team play" level is in there as well.

Working on your own software pet project, working on an open source project with other developers, and working in a corporate software environment are very different experiences. The rock-star programmer cliche still exists, but I think your average run of the mill programmer's success is more determined by how well he plays with others and balances his relationship with management and other forces of evil.

Also throw in a requirements level. A lot of people struggle with this early (and sometimes late) in their careers. It sounds simple, but figuring out what the customer wants (what they _actually_ want), and what you've agreed to provide, and what the program _actually_ needs to do (all three are often exclusive concepts) is a big deal. Sometimes the customer doesn't know what they want (but won't be happy until they get it). Sometimes the customer thinks they want the wrong thing, and won't be happy if you deliver it to them. Requirements analysis is a specialization all it's own, but speaking the language is a huge asset if you go into "big software" (aerospace, medical, defence, etc).

Re:Levels

[rwa2]

Yeah, there's probably a matrix of skills and abilities, depending on how much collaboration you need to do with customers / suppliers / other developers.

Great Coder: can make a computer do stuff. In code. No one else really cares how they do their thing. They just take a defined process and codify it to automate it or whatever.

Great Programmer: can write programs, presumably that other people have to use. Hopefully you still have this programmer around if you need to fix their program.

Great Software Developer: Now we're getting somewhere... they probably work together with other programmers as a team and start worrying about more of the stuff they learned in CS classes, like code reusability, refactoring, complexity, maybe some analysis of algorithms and pure math logic.

Great Software Engineer: Maybe less of the pure math and algorithms on how to do tricky things in code, but more of the practical stuff like defining code standards, test harnesses, and social aspects of code maintenance, like the discipline of setting up and maintaining the process through peer reviews, continuous integration, etc.

Great Software Architect: Solves problems before they occur by drawing pictures. But still gets blamed for all of the new problems anyway.

A lot of greatness involves managing complexity and making things as simple as possible for other people to understand and maintain. But no simpler.

Re:Alternate Link

[barrywalker]

I've become the "goto" guy for a lot of stuff simply by being curious. I've had a significant hand in every single piece of our application and know it better than anybody else on the team. I volunteer for things that scare the shit out of most of our developers. All it takes is, "Huh. This is broken. I wonder how it works?" to become Mr. Indispensable.

Eisenhower said it

[circletimessquare]

I tell this story to illustrate the truth of the statement I heard long ago in the Army: Plans are worthless, but planning is everything. There is a very great distinction because when you are planning for an emergency you must start with this one thing: the very definition of "emergency" is that it is unexpected, therefore it is not going to happen the way you are planning.

there's nothing like a real life emergency in programming but business culture is "get this done yesterday." no one can do that. but some programmers are very fragile and can only function according to one set of requirements/ work environment/ speed, and if you mess with that they get angry/ stressed/ tune out/ burnt out. while the "rock stars" can react to sudden and dramatic changes of requirement and need and crank out the changes relatively adroitly (not necessarily quickly). a sort of suppleness of mind and eerie lack of stress that's more about personality than training. and i say personality, and not training, because their code is a reflection of their personality: you can throw a curve ball at it from any direction and it can adapt without falling to pieces when "little" things (it's never little) change

your code is a reflection of how your mind works. which is your personality. and certain chilly stress proof people can generate flexible durable code that is almost like the redundancy and flexibility of logistics in war

Re:Alternate Link

[gfxguy]

That's what I would have added... curiosity. I think, like a lot engineers, the kind of people who took their parent's phones apart when they were kids to figure out how they worked... always playing the "what if" and "I wonder what would happen" games.