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.
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).
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.
And why would folks bother to obtain it, if it is almost entirely, if not entirely, not required to do "software engineering" work?
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.
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.
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.
"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.
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.