Getting It: What Makes a Great Software Engineer | Hacker News Reader

Getting It: What Makes a Great Software Engineer

avandamiri.com

9 pointsavand20 comments

Not to nitpick but I think the title of engineer is being abused quite a bit by software folks. I'm a software developer and would never consider myself an engineer. We build things, great. But one has to be professionally licensed by an accreditation board. While the other just has to have a few successful projects under their belt.

One of my friends just got his PE license. 7 frikkin' years after we both graduated. Could you imagine if it took 7 years before you were legally allowed to run your own company? (I believe 7 years is the average amount of time to get a PE). Anyone calling themselves an engineer without that little piece of sheepskin might as well call themself an MD without the years of med school.

But this is America (assuming the majority of HN subscribers) so call yourself whatever you would like.

Couldn't agree more. I think the problem stems from the fact that most engineers don't have anything distinguishing in their title (ie doctors with MD or lawyers with JD, etc) to show that they have gone through a long and technical process. Most people falsely assume if you graduate with an engineering degree you are an engineer.

Thats because for large chunks of engineering, it doesn't matter. Engineers work on tons of things many of which aren't life critical.

The same could be said for lawyers and doctors. For every ER doctor, there are 20 family doctors (GP), medical sales, researchers. In the past year I've met many people who hold JDs but aren't practicing lawyers (some do it because of boredom, challenge, or an intersecting business interest). I've rarely met a lawyer that uses esquire, unless they are trying to impress a date.

What I'm trying to say is engineer is a generic term, and the PE's can go get their own damned word.

What software engineering licensure do you propose one obtain?

And why would folks bother to obtain it, if it is almost entirely, if not entirely, not required to do "software engineering" work?

The fact that there is no license in widespread use does not mean that there is no argument for creating one. See http://www.stevemcconnell.com/psd.htm for part of Steve McConnell's argument that we need to create, respect, and for certain kinds of projects require true software engineers sign off on the plans.

I personally agree that there should be one, but right now, there really isn't much of anything that requires it. A few organizations have dabbled with licensing software developers, but not much has come of it.

I work on software for avionics systems. We have reams of requirements based upon industry standards, plethoras of verification procedures, and seemingly endless rounds of peer reviews, followed by formal flight testing. It can take hours of paperwork to change one line of code, to ensure quality and meet certification guidelines. In my opinion, this sort of work is about as "engineering" as software development can get.

I suspect work like this would benefit from having developers who are seriously licensed to do "engineering" work... the whole mindset is a lot different from doing a web startup, and I reckon most software people recently out of college are more in tune with the startup way of thinking than the sort of work that goes on with avionics.

Of course, not everyone wants to work with avionics. Maybe a license shouldn't be needed for doing web startups.

When it comes to engineers being licensed, that is America. No such thing exists in Sweden, at least. "Civilingenjör" is an university degree in applied science, roughly equivalent to an MS.

I know it's not a valid source but according to her http://en.wikipedia.org/wiki/Professional_Engineer the title PE (and variations, all require accreditation) includes: Japan, Canada, South Korea, Bangladesh, Pakistan, Sri Lanka, EU (Ing. Eur).

Sweden requires 7 years experience and peer review in lieu of examination.

But the main argument still holds. Some guy with 2 years of experience can't bestow himself an engineer.

I'd prefer to see software developers, programmers, etc drop the claim on the title "engineer", though for different reasons than the ones you listed. I don't think the public associates "engineer" with PEs the way it associates JD with lawyers or MD with physicians/surgeons. I think the public thinks of an "engineer" as someone who does something confusing and technical - for instance, people don't really expect a "sound engineer" to have PE. I also don't think that PE's have a strong historical claim to exclusive use of the word engineer, which most people initially think of as the person who drives the train. Lastly, so many branches of engineering have little to no use for licensing, but does this mean they shouldn't be considered engineering anymore? Do they need to invent new terms for their practitioners?

That said, I never describe myself as an engineer (though I do have a MS in industrial engineering), because I don't want the PE people to start thinking they have a claim on software. Like a lot of people on this board (where an economic liberalism seems to prevail), I'm very suspicious of the professional associations, which are immensely cartel-like in their behavior. I also don't consider software development to be necessarily "easier" than engineering. I just think it's very different, and that we should assert and insist on our own identity, and rigorously resist attempts to form cartels and restrict the right to practice, especially from PE folks, who in my opinion have no business regulating software (if they want to regulate software related to civil engineering, they should do that as civil engineers, not by making up some software engineer title and using scope creep to form a cartel, which is typical of professional associations).

Right... The world is full of engineers without certifications. Did the guy who designed the circuitry of my TV have a PE? How about the guy designing the intake manifold of my car? What did your friend do in those seven years before he got his PE? Probably engineering. Software developers are engineers. Whether we do it well or poorly is besides the point. As far as I know the cert only affects legal responsibility when signing of on a design. So uner that PE there are probably a number of other engineers without PE's doing the grunt work.

The guy that designed the circuit for your TV, or his boss, would have to be accredited. The reason the PE title exists at all is so some idiot with a basic understanding of electricity doesn't design a death trap.

The PE isn't some exam you pay $50 and take. You take it when you're ready. You can be an engineer without the PE, but you can't certify your own work unless you have a PE. Everything you mentioned has either been design, approved, or inspected by someone with the title.

Right but we still call those non-PE'd engineers engineers. And in many cases the "isn't a hazard" aspect is only a tiny part of the design.

What they do is engineering so they are called engineers. Software is very different from what an engineer requires. As Toyota is learning at the moment. Mistakes can be extremely costly. Not in firetrap way, but in the end product. You design a product that will have a permanent physical form. You only get one shot to get it right. It's how AutoCAD and Solidworks can justify their existence. Engineering is all about rules, you are constrained by them.

Software is about everything except rules. Software development is one of the few professions that has a creative and methodical aspect. There is very little preventing me from writing the next great app. I just need the creativity to get me there and the methodology to keep me on track.

I'm not sure creativity or rules are a good distinction. People can engineer lots of things in different ways and software can have plenty of rules.

I hate this type of article.

"Here is a distinction I just made up. We'll make it sound somewhat reasonable, put all of the positive characteristics on this side, the negative on that, and now which do YOU want to be?"

What if I think your distinction is half-baked and your description is somewhere between useless and wrong? Sorry, but I'm not buying into your world view today. There are a lot of variations of "darned good programmer" out there, and your oversimplification didn't even begin to capture what is involved.

What I still don't get though is what that made up distinction is.

I don't always hate these, but this one is especially nebulous:

These guys know what they’re doing but seem to be lacking something; somehow, everything they work on seems incomplete.

That's it? Just a vague feeling? A "smell"? In my experience developer smell doesn't correlate with ability.

After reviewing the attributes I identified that make up a great software engineer,

Wait, what attributes? None were enumerated.

I realized that they are in many ways common to all engineers.

Without any attributes, yes I think it's fair to say that for all engineering disciplines, some practitioners have a certain je ne sais quoi.

Car analogies work really well to conversationally describe software applications, but I’m going to use the metaphor of a carpenter to describe our quintessential developer.

Avoiding (but mentioning) the most cliched software analogy in favor of the second most cliched software analogy...

Software is exactly the same - only worse. It’s way easier to type rails superfluous-app than to fire up the saw and cut a piece of wood.

Up to this point no concrete thing has been said about actual software development. I guess that's why he feels safe saying that it is exactly the same as carpentry. However I would disagree that generating a Rails app is way easier than cutting a piece of wood, based purely on the numbers of people who have undertaken such ventures.

The master knows that the best cut is no cut.

This is a trite truism, yet still stands out as the best paragraph in the article.

As with the carpenter, a software engineer can fall anywhere on the skill ladder.

Mixing a ladder metaphor with a carpentry metaphor is daring in any context.

Think about the last time you saw a master at work. Someone that’s just qualified goes through often obvious and intuitive steps to get the end goal. But the masters ways are much more enigmatic, maybe skipping steps or starting with something that seems like it logically belongs at the end.

What does this even mean? What are the "intuitive steps" of software development? There is no such general case. That's what makes software development so interesting and challenging.

That’s how the get-its work. They’ll read a simple feature request and think through the ramifications it has on the whole project.

A programmer who doesn't think through global ramifications is incompetent in the most fundamental sense. The challenge is being able to make a good guess at global ramifications, and architecting systems so global ramifications are minimized. Exploring how great programmers approach those ideas might make a good article, but you'd definitely need some actual case studies or it would end up being just the same puddle of goo that this article is.

Get-its don’t just challenge the products their working on. They also challenge their tools. If it sucks, they build a new one.

Sure, but of course the real question is when does it make sense to take the time to build a new tool, and what qualifies a tool that "sucks".

They’ve got their heads up, listening to other get-its, and are always a little uncomfortable because they understand that the only definite is that something’s about to change. The best of them are the catalyst for that change.

Soo, what makes a great programmer is that they "are the catalyst for change"? This is gobbledygook. What makes a great programmer is that they are solving more problems, more elegantly, with less code, and more resiliency over time. That, in and of itself is pretty banal and hopefully broad enough that most programmers could at least agree that its not un-true, however it still doesn't find itself anywhere near "catalyst for change" which is awfully close to "change for change's sake" for my taste.

I am truly stupider for having read this article.

Sounds like the No true Scotsman fallacy.

http://en.wikipedia.org/wiki/No_true_Scotsman

Reply on news.ycombinator.com