What distinguishes a good software engineer from a great one? | Hacker News Reader

What distinguishes a good software engineer from a great one?

quora.com

54 pointsrpsubhub24 comments

It's hard to answer this question because anyone who answers is implicitly claiming to be a great programmer instead of just a good one.

When I think of great programmers and think about what distinguishes them from me, I'd say it's probably their experience. The more you do it the greater you become at it. I've never looked at a project and thought to myself "wow I couldn't make that even after 10 years". I always think "I bet I can do it too if I spent the last 10 months working on it".

I'm a good programmer. Many people I know professionally may call me more than that.

I have a friend who, when he does stuff, I can look at and say that there is no-way I would ever come up with that. Once I've seen it, I can say that I could repeat that, given some time, but that isn't the same as coming up with the original idea and implementing it really well

That is a great programmer.

Can you give an example of something that, when you look at it, you just know you would've never been able to make by yourself?

"implementing it really well" mostly comes from dedication and attention to detail, in my opinion. And of course, you have to actually care about the thing you're doing, and always keep in mind the user's experience.

I always point to a lot of the early work from John Carmack on 3d engines. There's a certain level of innovation and creativity in his mind that I may never have, at least when it comes to solving programming problems.

I've never looked at a project and thought to myself "wow I couldn't make that even after 10 years".

"Until a man is twenty-five, he still thinks, every so often, that under the right circumstances he could be the baddest motherfucker in the world. If I moved to a martial-arts monastery in China and studied real hard for ten years. If my family was wiped out by Colombian drug dealers and I swore myself to revenge. If I got a fatal disease, had one year to live, devoted it to wiping street crime. If I just dropped out and devoted my life to being bad." - Neal Stephenson, "Snow Crash".

How old are you, hasenj?

Hah! How old are you?

I'm 26. off by one!

I see the point of the quote.

I didn't mean what I said in the naive dismissive attitude that a reckless teenager might have.

I'm not talking about the difference between the lousy and the great. I'm talking about the difference between the good and the great.

I consider myself a good developer, in the sense that I'm not a lousy one. I don't see myself as a great/awesome hacker.

What I'm trying to get at, is that the difference is dedication and experience. Yea I didn't create the first ever 3D game, but I never had the required mathematical knowledge, never had much experience with 3D modeling, nor the dedication to go through with such a project.

The same thing that distinguishes a good (fill in the blank) from a great (fill in the blank). Passion, drive, perseverance, experience, patience, brilliance, etc. If you want to be a great engineer, the problem is that you don't see yourself as a great engineer already. If you saw yourself as a great engineer, you would emulate all those wonderful words I mentioned before, because, well, that's what great engineers are. Fake it 'til you make it.

I am having a hard time coming up with a harder place to apply "fake it 'till you make it", because the way that will actually turn out is "fake it until your first big design project crashes and burns and possibly takes the company with it".

Fake it 'till you make it is for social skills, not engineering, and while social skills factor into being a great software designer it isn't even close to the whole story. The computer does not care whether you are faking it, it cares whether you've got it.

I've been involved in projects where lead architects did indeed fake it till they made it. It scared the heck out of me once I found out what was going on, and the "making it" wasn't due to anything they themselves did, but in fact because of the team going above and beyond. It doesn't change the fact that in the eyes of senior management, this guy had "made it".

The topic of the day is great software engineers and I'm taking that to mean people who actually engineer software, not people who convince clueless management that they are great software engineers without actually being so. I acknowledge your point but I think it's not terribly related to mine. You may have had a "lead architect" but they clearly weren't even in the running for "great software engineer".

Very true. I work every day on a system architected (in the loosest send of the word) by one of these types. Now he'd obviously been asleep in CS 101 where they talked about locality and big-O... But wide awake in whatever course teaches Applied Bullshit. He's gone off to another company now... He seems to veer wildly from project to project, saying all the right things and escaping to another role before the steaming pile of crap he's "designed" explodes. Bitter, moi?

First, there's no guarantees in life. For every good developer that turns into a great developer, there's a good developer who turns into an asshole developer. There is no formula that leads to 100% results. However, if you want to be great, the first step is having confidence in yourself and believing that you are great.

Second, there may be casualties along your path. A few projects crash and burn. Nobody is born great. They get there. You can't get there without experience. That's definitely on the list. The only way of gaining experience that I know of is through failure. The more catastrophic, the more you learn.

"Passion, drive, perseverance, experience, patience, brilliance, etc."

You beat me to this list of qualities. The only minor disagreement is that brilliance shows up only after a good developer, who embodies your list of qualities, follows his/her interests and gets really familiar with a couple areas of the field. As an example, someone who enjoys hacking graphics at a low level will eventually become great at that area, but may be only good at language design.

Our field is too broad to be great at everything.

Most of the things mentioned in the comments are co-factors; that is, things often found alongside greatness, but not necessarily the cause of the greatness. They are also often found alongside mediocrity.

I prefer simple tests:

Bad programmer: It can't be done.

Mediocre programmer: It's never been done.

Good programmer: It can be done.

Great programmer: It's done.

I'd also accept "I'm doing it" from a Great programmer.

Somewhere in there should also fit, "Let me teach you how to do it too."

http://philip.greenspun.com/ancient-history/professionalism-...

Or someone who recognizes that "There was a similar thing done in ..."

I like the first answer from quora, but with one exception.. That being an understanding of business and priorities. Great engineers understand that ultimately, they're responsible for shipping product in a business setting.

In your personal open source project or side projects you can afford to be experimental and push the box, but when you're in a business setting, you need to balance the need to ship with the desire and drive to be experimental and solid. Get from point A to point B balancing risk, reward, and speed.

Really? I think programmers who focus too much on the business side tend to not be the greatest. Or how I should say it? The vast majority of business programmers are in it for the "job", so that automatically makes them not great programmers.

Sidenote: refer to answers by their authors, because they are always changing positions :)

great programmers are very hard to work with and need a wingman for doc and cleanup.

Common misconception. Great programmers write clean code and document their work.

I loathe engineers who produce complex, unreadable code and have enough nerve to call that "cool". A great programmer knows when to refrain from saving two lines of code to spare the next person two hours of debugging.

Programmers needing wingmen that clean up after them are in my opinion simply jerks. It's a sign of disrespect towards their coworkers and a sign of a lack of an important skill.

This is simply not true.

I have met a few and know of a few other great programmers - the ones who do the work of 5-10 lesser programmers - who exactly fit this description (and some that don't). Either way, if you have one of these guys you shouldn't mind having to pay for a minder.

Guys like this are common in the games industry, but I've met a few working in other fields.

I have found that these programmers tend to be idolised and adored by the rest of the coders: good programmers tend to appreciate great craftsmanship. Plus, everyone ups their game in the hope that some of the magic will rub off. It's also easy to take a few clever risks if you have one of these guys standing behind you.

I disagree with -you-, sometimes even coders can buy into hype. If you play up someone's ego and idolize them, they'll just continue to do things like not document their code or - as wulzcer put it [save an extra two lines but cost the next person two hours of debugging]. Never thought I'd be the guy talking like this, but rockstar attitude does little positive for the team.

Kinda funny that Yelp's on this list; I see their office everyday as the elevator passes by on the way to mine, -and- they've one of the worst apis ever. haha

Reply on news.ycombinator.com