Ask Slashdot: What Makes a Great Software Developer? 214
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?
Alternate Link (Score:5, Insightful)
Here's an alternate link [dice.com] 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.
Re:Alternate Link (Score:5, Interesting)
Re:Alternate Link (Score:5, Interesting)
Re: (Score:2, Funny)
>I've become the "goto" guy for a lot of stuff
Is that a subtle way of saying your co-workers consider you harmful?
(Sorry, just couldn't resist.)
Re: (Score:2)
Hello Barry, it's the other way round. Nobody is indispensable, everybody can be a nuisance.
Re: (Score:2)
Re: (Score:3)
Even the go-to guy can
Re: (Score:3)
Re: (Score:2)
As long as I'm good technically, I've got a job, and can stay technical. This is only a problem for people who want to go into management, which I definitely do not want to do, so it's only a problem for some people.
However, would you really want to select managers from those who don't do their best for the company?
The most important prerequisite (Score:3, Insightful)
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
Re: (Score:2)
I think you highlighted the wrong part.
"Identify the need and/or problem" is the crucial part and is what differentiates the great programmer who fixes that need, and the adequate programmer who is so focused on the solution he can forget what it is he's really supposed to be doing.
Or to put it another way, the great are those who listen before talking, the rest just prefer to talk.
Re: (Score:2)
In general, you won't find out what the real need is just by listening. Users tend to come up with solution frameworks that may be good or bad, and present them. It's usually necessary to probe further to figure out what the problem actually is. So, if you're really good, and you listen carefully, you will often brilliantly implement something that isn't what the users want.
From my perspective... (Score:2, Funny)
...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.
Re: (Score:2, Insightful)
Average salary? A Great programmer should expect great money.
What you've described is a chump who throws away his talents and time so that other people can make the good money. Screw that.
Re: (Score:3)
He's obviously a PHB.
Re: (Score:2)
This advice only applies to people who are trying to be paid more than they are worth by searching for desperate employers or simply being good at interviewing and negotiating instead of their job. If your employers are happy with your performance, they will not complain about your salary. If they do, it is time to look for a new employer because your current one doesn't know how to value key employees.
In the kind of areas I'm talking about, software is usually a small industry and word gets around. A company might also decide to phase you out, because they see the writing on the wall and bringing someone new up to speed on what you currently do will be cheaper in the long run.
You want word to get around, because you are an exceptional employee and any employer will be happy to hav
Re: (Score:2)
Raises are about more than retaining people, they're about avoiding morale problems. Developers are not usually heavily motivated by raises (there are exceptions) but they can be easily demotivated by not getting what they think they deserve. For example, if you hire a guy at $90K/year, and then the market gets tighter and you give him a $5K raise to retain him, and he finds out you're hiring new guys to do the same job for $100K, you've got a problem on your hands that'll likely cost you much more than
Re:From my perspective... (Score:4, Insightful)
I really hope this is sarcasm. You just described everything that causes projects to fail, take on lots of technical debt, cause burnout, and generally make people leave the industry. After working in many countries, I've also noticed that this is especially an American thing, like a badge of honor. You are a programmer, not a Marine.
Re: (Score:2)
I should add:
7) Is obiedient, listens, and doesn't talk back.
8) Stays technically current, but not on company time.
9) Gives their manager credit for good results. If the manager gets promoted, they will want you right behind them, making them look good.
Re: (Score:2)
Although I think it is pretty obvious you are being sarcastic, my take on each of your points is that Great Programmers:
1) Understand that all estimates are inherently unreliable and constantly track real progress so deadlines or promised feature sets can be realigned periodically.
2) Understand that unplanned work will be added during development. They don't complain about it, they simply realistically assess how these changes could affect deadlines and/or other promised feature sets.
3) Take responsibility
Re: (Score:2)
http://programmers.blogoverflo... [blogoverflow.com]
I think the main thing that most people skip is how to work alongside other developers, and how to write maintainable code.
Re: (Score:2)
"Try to kick ass at least once a week."
I try to do similar things. But then there are last minute meetings (scheduling 8 am meetings at 630 am? Really?), an overnight patch breaks my IDE, a bad switch in the blade farm hoses up routing so I can't make it to my test and development server, a new standard is implemented in coding tools, a new coding paradigm is adopted, HR says we need to get our compliance reports in RIGHT NOW, "Fred" get sick and I have to cover for him, etc.
So good luck with that.
Footnote:
Re: Alternate Link (Score:5, Funny)
Not enough agile bro.
Need to pick an hour everyday and kickass.
Re: (Score:2)
Urgh!
Re: (Score:2, Informative)
A good software developer is also someone who listens to user bugs reports and feature requests.
Maybe this is true of some places, but everywhere I've worked has seen a huge separation between the developers and the end user. I think it's actually a major failing in a lot of big projects.
A pretty common structure:
- contracts people and requirements analysts work out a set of contractually binding requirements with the "client" (a group which is usually themselves abstracted from the people who will actually use the software).
- designers build a design to meet those requirements, it's reviewed by "the
Re: (Score:2)
Beer (Score:4, Insightful)
Re: (Score:3)
it is also relevant that drunk people believe they perform better on driving tests than they actually do.
While sexy during the courtship ritual, blind confidence is something of a fickle mistress in many other applications.
You'd need a lot more beer ! (Score:2)
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 !
It depends (Score:5, Insightful)
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.
Re: (Score:2)
If today's software is used as an example, it seems like most team programmers are chosen for their willingness not to to rock the boat (or management ego) first and programming skills last.
Re: (Score:2)
and writes code that is easy for them to navigate, digest, and change
Unless you're working on a complex problem that other programmers can't understand in the first place, and the most minute detail is important. Then you find yourself trying to explain to the other programmers that by not doing something, they're now using an extra cacheline and causing a 10% hit in performance on their quad core and a 35% performance hit on a dual socket server.
Re: (Score:2)
Yeah- now in reality that doesn't happen. The whole lone programmer thing is almost completely a myth- pretty much all non-trivial programs are worked on by a team. At the absolute best you'll get someone who comes up with a new algorithm to do something by himself, but even then it will be one part of a larger whole that will need to be worked on by the full team.
Re: (Score:2)
If
Re: (Score:2)
No, they don't. But a lot of academics like to think they do.
Re: (Score:2)
Re: (Score:2)
Both. But in this case I meant the second one. In reality Lisp is dead as a doornail, and the rest of the functional languages with it.
Re: (Score:2)
Re: (Score:3)
People actually solve real-world problems, outside of academia, using LISP?
Here's some. [pchristensen.com]
Re: (Score:2)
Re: (Score:2)
emacs or autocad are news to you?
Re: (Score:2)
You haven't been keeping up. Lots of important software is in Lisp (the preferred capitalization). It's surprisingly flexible, and I've found I can change approaches quickly and try things out without putting too much work into them. Once the program is working, there are ways to make it fast. It's sort of opposite of C: in C, your program is fast with little problem, but correctness is much harder, while in Lisp, correctness is easier to get to and speed can be tacked on at the end. (I'm assuming re
Re: (Score:2)
If you can't at least read code in a language you don't necessarily use everyday and follow along or figure it out in a day, you don't belong in this career.
Best comment I've seen in a long time. Kudos to you sir.
Re: (Score:2)
Levels (Score:5, Interesting)
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 (Score:5, Interesting)
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 (Score:5, Insightful)
Re:Levels (Score:4, Insightful)
Re: (Score:2)
Who wrote this crap? Oh, I did. Was I ever that lame? Seriously? WTF does this code do? A one-line comment would've helped.
Eagleson's Law definitely applies.
Especially as you age. I'm pushing 50. I've become the king of docs, both in the code and on the wiki. Because I've learned that there's no guarantee that I'll remember
Re:Levels (Score:5, Interesting)
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: (Score:2)
Yeah, you probably have it right.
My description of a Software Architect was mostly tongue-in-cheek... at most of the places I've worked they were the ones that determined "high-level" things, like what expensive commercial middleware everyone was going to have to integrate with and spend all of their time coding around its deficiencies. Architects rarely touched actual code. Maybe they had a PHd or something but more often not, but they did get to make decisions that involved the movement of large amount
Re: (Score:3)
I like to divide code into two categories, code that 'does stuff' and 'glue code.' The goal is to minimize the glue code as much as possible, while still maintaining flexibility.
If you follow the rule of the Linux kernel development, "Each function should do one thing and do it well," then your code will be a lot closer to flexible almost immediately, even without building a f
Re: (Score:2)
The "do one thing well" philosophy is about purpose, not implementation.
For example, the grep family of tools search for patterns in files or input data streams. There's egrep for regular expression matching, zgrep for searching through compressed data (decompressing before searching, of course), etc. There's oodles of options to make all types of searching easier, but those are all aimed at the central purpose.
If you need to search for all of the numbers in a file and add them together, you could use gre
Re: (Score:2)
Ideally, you should be able to give each class and function a descriptive name. That doesn't mean it can't call all sorts of other functions; "DIsplayWidget()" (or "Widget::Display()") is likely to do a lot of work that's farmed out to other functions, but it does mean the function or method has a single clear purpose. If you find yourself putting "And" into the name, you probably should refactor it into two separate functions.
Re: (Score:2)
What if your function needs to call two other functions? It's then actually doing three things (the two calls and whatever it does with the results of them)...
So, this is a well defined principle of software engineering. If you don't understand it, then you need to figure out what's wrong with your brain because most people do understand it, the problem is you.
~make~ as opposed to *born* developers (Score:2)
Re: (Score:2)
And the truly exceptional separate themselves from there: they always have a little more "try" in them than the others.
Entitlement and freedom from obstacles is magnus infitialis.
Knowing you will make mistakes. (Score:4, Insightful)
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.
Great programmers are made not born (Score:5, Insightful)
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.
Re:Great programmers are born not made (Score:2)
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.
I agree. However, too many people can't be bothered to be curious. At best, they just want to get the job done. If you're innately curious, you're going to spend time looking deeply into stuff that "practical" people don't consider worth looking at at all. You're going to try things and see what happens, whether you're a kitten or a developer or Albert-frickin'-Einstein. And that, after all, is what learning really is. You don't so much force yourself to learn to become great, you become great because you c
A great developer knows how shitty he is at coding (Score:3, Insightful)
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?"
Re: (Score:2)
Codefusious say man who misread x86 page size, high on pot.
Re:A great developer knows how shitty he is at cod (Score:4, Insightful)
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.
Re: (Score:3)
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.
Re: (Score:2)
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
maybe that's the fundamental thing - the greater a programmer, the more he treats the work as work and not fun. A professional working on building a product and not some amateur playing with his hobby.
A great programmer will use whatever tools are needed or suitable, the 'coder' will use the tools he really prefers using. Like my mate, when presented with his new job th
Re: (Score:2)
That depends on the "why" though. Currently, one of the thing that will prevent a company from growing is how hard it is to get resources. An argument could be made that good C++ devs are rare and expensive. PoS systems are frequently written in higher level languages, so you'll more easily be able to find people to work on it if you use one of those languages. So the time and money you lose rewriting it will be made back, often several times over.
C# is actually a pretty wonderful language, with its platfor
Re: (Score:2)
I guess I've never known a great - or even good - programmer who didn't find it fun. (Imagine, for example, a concert pianist who didn't find playing the piano to be fun. Unlikely, at best.)
Of course, not ever aspect of a programmer's job is fun, so that's where professionalism comes in. Like many programmers, I don't always enjoy the documentation aspects of it, but that's part of what my employer is paying me for.
(BTW, the title of this thread makes me think fishermen are likely to be better at cod tha
Re: (Score:2)
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.
Long ago, I had a set of "Programming Proverbs" books. I think that's where I ran into the term "anti-bugging".
Anti-bugging is simply the process of designing and coding so as to make bugs either impossible, or at least easier to detect. It can be as simple as always coding brackets around conditional clauses instead of only when needed, to pre-initializing variables so that in case all the various logic paths fail to set them that their value will be consistent (and ideally, obviously wrong). Coding tests
Re: (Score:2)
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?"
Computers are devices whose primary purpose is to make developers look like idiots when they make statements about what the computer is going to do or not do.
Don't even get me started on photocopies and traffic lights.
It's a conspiracy, I tellya!
Crystal ball ? (Score:3)
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".
Re: (Score:2)
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".
Oh, I dunno. I've found that if it's too good to be true, it's probably going to be a fad.
If it promises to make developers obsolete, it won't.
If you can get a flashy application working in under 15 minutes, everyone will adopt in and then discover that it takes just as long or longer to actually produce industrial-grade apps as the "old-fashioned" stuff does with the added excitement of discovering new security vulnerabilites.
On the other hand, if something comes along and I go "WTF is this? What does it d
Be a Good Listener (Score:5, Insightful)
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.
My opinion (Score:5, Insightful)
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.
Re: (Score:2)
Re: (Score:2)
You completely missed my point. You have to be passionate about your craft. I didn't say you have to be passionate about a particular employer.
There are at least 2 types (Score:2)
You have the 'knows how to work efficiently to get the project done as quickly as possible'.
And then you have the 'knows that they'll have to maintain it, and will work to make sure to minimize shortcuts, or document every od trick they used, so that two years later they'll be able to modify it when some new requirement comes along'.
I actually enjoyed doing the first type of programming. These days I see paralized and might be over-designing things because of times that I've gotten stung by not being type
Eisenhower said it (Score:4, Interesting)
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: (Score:2)
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)
All well and good until that is expected every time. The "this is going to be a problem but don't worry about it, X will fix it" mentality probably makes a lot of poor management teams lose good talent.
Re: (Score:2)
Agile is intended to handle the sudden and dramatic changes of requirement. Because I can virtually guarantee that any significant project that makes its way into user hands is going to get a lot of requests for changes. Not simply because of bad/sloppy original specs but because the users, given even a partial solution will discover new things that need new solutions. Sort of a software "Heisenberg effect", if you will.
What makes a developer great is the ability to allow for this and design for it instead
Re: (Score:3)
well yeah, by definition a rock star is very rare
so if you want a rockstar working for you, you better be ready to shell out big money or provide truly extraordinary perks
you can't just expect or demand rock star status from average or even above average programmers. you can't mold people's personalities like their technical proficiency. i suppose there does exist stress mitigating strategies someone can consciously adapt. but from the rock star i met, it is a sort of chilly immunity to even the concept of
Good Taste (Score:2)
People without good taste (regarding to the code) will never become great software developers.
Re: (Score:2)
I agree wholeheartedly. But is good taste born or made? A few years ago, I mentored a new grad who had very good taste in coding from the beginning. It took me a lot longer to develop that. Certainly, experience helps. But I've also met highly experienced people who had poor taste in coding. Like so many things, I guess no amount of experience will make up for a complete lack of talent.
Well duh! (Score:2)
Software Design (Score:2)
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) .
TEPES (Score:2)
Having built a long-term development team from scratch, and having screened a lot of consulting software engineers, I eventually came up with an acronym that describes what I look for: Talent, Experience, Professionalism, Education, Skill (TEPES). I wrote a post on the subject back in 2008 -- you can read it here [brucefwebster.com]. ..bruce..
You need to care (among other things)... (Score:3)
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.
Re: (Score:2)
IMHO, a good developer needa to CARE about what he/she is writing.
I'll say that again! Good developers also need a proofreader when posting on /.
Great qualities (Score:2)
I don't know about great programmers.. but I've found some great qualities in coworkers who seemed great to me throughout the years:
1. Nice people: People who get along well with others and through their good qualities make everyone better. Not only can they write awesome code, but since everybody likes them they can get the knowledge they need to do it right. This is probably the quality I admired most in the GREAT programmers I've met.
2. Deceptively simple designs: I've met coworkers that can design thing
It takes two things (Score:3)
1. Skill
2. Passion.
Planning & Vision (Score:2)
Re: (Score:2)
Be the problem solver (Score:2)
In most places people don't like to think. Thinking is hard and people don't want to do it. Solving problems involves thinking and if you save people from doing something they don't want to do they will value you.
Even better is if you do the problem solving and leave them with the 'how-to', you will be idolized every time that solution is used and considered essential.
Agism tries to trump experience but it never works because agism is so naive, so if you can't avoid getting older then grow up slowly and
Six key points (Score:2)
My key points on the subject are:
1. A love of the art and the job.
2. An eagerness to learn and try new things.
3. The willingness to risk your job to do "the right thing" on a project.
4. Acceptance that others in the business (not just the team) have valuable inputs that need to be respected.
5. Experience. Years and years of in-the-trenches experience with a variety of technologies and techniques.
6. (And perhaps most importantly) A background in the history of computing. The realization that "
It's all about balance (Score:2)
Software development like almost everything else is about balance.
Do I refactor/rewrite or not? Add the extra layer of abstraction? write defensively?
Do I commit a partial solution to keep integrated with mainline?
Should I deploy a partial solution to get real feedback?
Do I make it more complicated to handle some future requirement?
The best software developers have a good sense of balance. You can always learn a new language/technology
you can also learn to do things by-the-book learning balance is tricky.
Jo
According to their managers? (Score:2)
An undying devotion to their craft and diligence towards completing their projects so strong it blinds them to how poorly they are treated (I would say paid, but that's subset of "treated").
Re: (Score:2)
Wait... you can tell the difference between American and Canadian?
Re: (Score:2)
Re: (Score:2)
Groups within some nations can also bring in a lot of shared experiences about college, how they where taught and past work.
That can shape a team or really allow group think to set in, cult like with a leader.
Re:Difficult to answer (Score:5, Insightful)
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.
Re: (Score:2)
Many programmers have an issue of using the wrong tool because they don't understand the minor differences between two tools. All they know is doubles and ints are both numbers, so they don't care which ever they use, and their decision may not make a huge difference 80% of the time.