Slashdot Mirror
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?
Here's an alternate link for the first article.
Or better yet, skip it. Usual shitty dice.com summary article.
The linked lifehacker article seems pretty good and I largely agree with it. Couldn't make it through the second one.
Two things I would add from my personal arsenal:
- Try to kick ass at least once a week. This sounds weird, but it's worked very well from me. In the perfect world we would kick ass every day, but I think realistically we (or at least I) would quickly burn out. So instead I try to just randomly pick a day where I come in with the mindset that I'm going to just fucking own whatever I'm working on. The day is random and sometimes I skip a week, but I usually manage, and while you would think inconsistent performance would stand out, I've found (at least where I work) that it doesn't, and people tend to remember the kick ass days rather than the average days.
- Dive into the stuff that others avoid / are scared of / don't like doing for various reasons. I'm not saying take the shit jobs, but usually there are tasks programmers hate because they involve working with hardware, dealing with clients, travelling, or doing something out of their comfort zone. Become the <whatever> guy.
Beer makes everything better ;)
The best "lone wolf" developers probably use something like Lisp and a high amount of math-like abstraction to crank out vast amounts of features in a short time.
However, a good team programmer knows how OTHER typical programmers think and read code, and writes code that is easy for them to navigate, digest, and change. Team programming is more like authoring a good technical manual, not clever gee-whiz tricks.
Table-ized A.I.
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.
"First they came for the slanderers and i said nothing."
It's not that great software developers never make mistakes, it's just that by knowing they can and will happen to anyone, they can try to catch them early.
It's the people who think the code they write is flawless that tend to have the most problematic code.
To be a great programmer (or even just a good one), you need to never stop learning. Always be learning something. Many times in my life I have learned something on my own, only to be able to apply is a totally different situation later in life.
Great programmer are insanely curious. They want to know the how things work, why one solution is better than another, always improving. That is the key, always be improving your craft, and your knowledge.
You WILL make mistakes and introduce bugs when coding. A great developer knows this.
Ask anyone you think is a great developer, "What do you do to help prevent or detect the mistakes you make?"
can tell fads from technologies that actually endure
And are therefore defined in hindsight.
Critical thinking, not buying anything some software vendor is willing to sell you, is one thing, and betting on the right horse every time is quite another.
At some point, you can't miss the latter by being conservative and only adopting "new" technologies when they're already mature (now, if you had some sort of almanac...). Also to note, "better" does not always mean "successful".
I have discovered a truly marvelous proof of killer sig, which this margin is too narrow to contain.
Whether or not it is called "Software Development" or "Software Engineering" or "Coding" or whatever the newest trendy iteration, they all boil down to identifying the need and/or problem and then SOLVE IT
From the primitive but extra-ordinarily crucial computer systems that ran the Apollo space program to Lotus 1-2-3 to Linux, all they did was the same --- they identified what is needed and then providing solution to get the problems licked
Muchas Gracias, Señor Edward Snowden !
I think one of the most valuable abilities for a good programmer is to be a good listener. A big part of that is also being able to ask good questions. You need to be able to fully understand the problem to be able to develop the right solution -- remember, the solution that customer actually needs is not always the one they think they want. Also, being able to listen also means you will be better able to learn new skills.
I believe in de-evolution. God made the world perfect, man fell, and its been going downhill ever since!
I started a software company back in 1999; we're still around and up to 10 employees, so I have had some moderate success in the software business.
I think the LifeHacker link makes a lot of good points. I especially agree with limiting overtime. I *never* ask my developers to work overtime. Just never. Because I don't set release dates. When someone asks when the next release will be, I say "when it's ready" and I mean it. It's far more important to get it right than to get it out "on time", whatever that is.
I would add that to be a great software developer, you need a lot of discipline. You need to write your unit and regression tests even if you don't feel like it and even if you'd rather be moving on to the next cool feature. You need to write your documentation clearly and comprehensively. You need to have your code reviewed; even the best programmer can benefit from suggestions that improve code clarity.
You need to listen to your customers. You can write the greatest software in the world, but if it doesn't do what your clients want, that's not much use. But you also need to have enough judgement to know when your customers are asking for something ridiculous and you need to have the communication skills necessary to explain to them why what they think they want isn't what they really want.
You also have to be passionate. If you went into computer science because you thought you'd get a secure job, but never particularly liked computers and didn't do programming on your own time, forget it... you won't be a great software developer.
Beer and lots of offshore help! :)
The more you rely on offshore help to solve the problems on hand the more beer you gonna find yourself gulping down
Trust me on that !
Muchas Gracias, Señor Edward Snowden !
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
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
To be a great software developer, you need to write great software. Any great software requires a lot more forethought than just coding.
Upfront design is the key to flexible and maintainable software. Peer reviewed, simplified, unoptimized design gives you a great base to start writing great code. It is akin to listening to a shakespeare play before writing one (as opposed to just winging it as you move along) .
Hint - if you think that you're the best coder in the world, and that everyone around you is only outputting a bunch of shitty buggy crap, it's probably time for you to do a bunch of introspection.
It's a well known phenomenon that experts will tend to play down how good they are (because they realise what they don't know), while non-experts will tend to play up how good they are. The fact that you're claiming to be god's gift to man kind, and that everyone else seems to be doing something different is a good indication that you may well be in the latter category.
Don't get me wrong - you may actually be god's gift to man kind, and/or you may be amongst a bunch of incompetent monkeys, but that's not the likely scenario.
Yep, I've never met a really good programmer who didn't use every tool he could exploit to find his bugs. Every one of them that I ever met had a strong leaning towards strongly typed languages, because they could exploit the type checker to find their bugs. They had a strong leaning towards testing, because they could exploit it to find their bugs. They had a strong leaning towards running profiling tools for memory, leaks, performance etc because they could exploit them to show were their code was really bad.
As far as I'm concerned - lesson 1 is to use every tool you possibly can to prop yourself up - get the computer to make you into a good programmer.
...Great programmers:
1) Provide reliable estimates that aren't inflated.
2) Meet aggressive deadlines, even when unplanned work was added to the project during development.
3) Take responsibility for their bugs and get them fixed, on deadline.
4) Don't take time off during crunch time.
5) Are willing to help when called to troubleshoot a surprising client issue on a weekend.
6) Are humble enough to be content with an average salary, rather than always demanding raises to be paid at the top of the industry.
IMHO, a good developer needa to CARE about what he/she is writing. Here are some points I've gathered from two decades of development work:
Care about the code
The quality of the code, efficiency, consistency are all key. Internal documentation is very important. Even if you don't think anyone will *ever* look at that code again, guess again. Someone will probably end up going back over it in the future to fix a bug or add a feature -- often times that is YOU, the one who wrote it. So leave enough comments behind to tell the next guy (or you when you've long forgotten that code) what in the world you were thinking. I've known way too many developers that simply say "yes sir" to their boss and crank out the code as fast as possible. They don't bother to think for themselves things like "what would the customer want" or "how can I design this to be as efficient as possible but still be understandable"? People who view development as simply a "day job" and don't take pride in their work end up causing themselves and others pain down the road. Being a developer should be more than simply writing code that works. You should care enough to write code that works and is elegant.
Care about the end user
Whether your code is a script that nobody will ever see, or a GUI application that people will use daily, a good developer puts themselves in the customer's perspective. They care about efficiency. They care about how the people who will use their software on a daily basis will perceive it, and how it will impact their workflow. Try to imagine how shaving even a few seconds off a process that someone does many times a day could add up over the years. With the power of modern computing, it's all too easy to become lazy as a developer and not put much thought into scalability, or to write sloppy code that doesn't make good use of resources.
Care about robustness and security
Writing good code also involves covering yourself in terms of error trapping. Make sure your code can (attempt to at least) fail gracefully when the unexpected occurs. Also, make sure you always code with a view to security. Way too much software is written in such a way where security and error trapping is put off until later. All too many times, due to time constraints or simply forgetting, these tasks never get done, and as a result insecure, buggy software is released.
Don't be afraid to start over
Good developers also aren't afraid to refactor their code. Sometimes it takes finishing a good chunk of code and analyzing how it performs in the real world to realize you did it all wrong and you need to rip it up and redo it. That's OK. Try to learn from it and do it less as you mature as a developer.
Memorize the headers and APIs you use most
Try to memorize headers and such of key APIs and libraries you use often. Personally, I find it all to easy just to keep looking up that function over and over whenever I need to use it. But if you trust yourself and memorize the documentation, then you can code more efficiently with less interruptions from having to go and look up that function call every time.
Keep it simple
It's easy for a developer to code "the kitchen sink" and bombard the user with a million options and settings. Yes, the program can do everything someone could possibly want, but overwhelming and confusing the end user is never a good idea. It's much better to think things through carefully and build only what is necessary, or if all the options must exist, build it in layers so the most important options are visible first, then the advanced users can dig in and configure to their heart's content.
Yep, I've never met a really good programmer who didn't use every tool he could exploit to find his bugs.
Good point. In that vein, the best programmer I ever worked with once said he had an "anti-fetish" for bugs. I think that at least partly explained the extremely high quality of his work.
For most of us, though, finding and fixing bugs is a chore that we'd rather avoid because writing code (and therefore more bugs) is more fun. I try to emulate the anti-fetish mentality of my friend, but that remains something that I sometimes have to discipline myself to do rather than something that comes naturally.
1. Skill
2. Passion.
File under 'M' for 'Manic ranting'