Item — HN Reader

I think this is a decent article, with some distilled wisdom... Though I also think it has some repeating status-quo mumbo-jumbo.

Every time somebody says a soft-science claim and presents it as a fact, I try to vet it with this heuristic: It can't just sound good, or satisfying, but is it actually true? Imagine whether a case can be made for the exact opposite statement, or whether there may be circumstances that the statement is obviously false.

For example, once a principal engineer asserted rather confidently, "At my level, the most important work you can do is usually in Jira." That's a claim that's hard to assess with any objectivity, but I can certainly imagine a different principal engineer feeling the exact opposite, and I can certainly think of many companies where they wouldn't hire/want a principal engineer primarily for Jira work.

Back to this article, any time somebody says "A manager is X" or a "staff is X" I think to myself... well can I think of a company that would want managers who focus almost entirely on not X? The answer is almost always yes.

2 comments

As someone whose been sort of "up and down" the role ladder, and is very intentionally closer to the bottom than the top for right now, I think I am disproportionately perceiving the wisdom in that jira comment.

I don't think it's the _only_ important thing, but I think I do agree with the sentiment that it may be the most important.

Personally I'm all about diversity of perspectives when it comes to building a team. I would be thrilled to have both a principal who loves jira, and one who doesn't. Someone who tries to straddle both just strikes me as neutered.

When it comes to roles, I always end up back to the Ron Swanson quote "never half ass two things; whole ass one thing."

I do agree with you though, one-size fits all definitions are almost all laughably based on "vibes."

Then again, isn't management pretty much just vibe cultivation?

I think it only takes a few moments of skepticism to show that "Is X the most important thing about being a Y?" doesn't mean anything.

Being good at something obviously comes down to multiple different skills (manager may require social skills, writing skills, perception, business acumen, intuition, etc). So to try to ask which of those skills is "most" important is a poorly-defined problem, because there isn't such a thing as an 1-unit of of writing skill to weigh against 1-unit of intuition skill.

For whatever reason, a lot of people are drawn to these types of oversimplifications that are so drastic they become meaningless.

The hypothetical question as I understand it isn't about which skills, but rather which activity yields the greatest expected value.

I really wish people would stop calling software developers engineers because they aren’t.

A professional engineer is competent by virtue of his/her fundamental education and training to apply the scientific method and outlook to the analysis and solution of engineering problems. He/she is able to assume personal responsibility for the development and application of engineering science and knowledge, notably in research, design, construction, manufacturing, superintending, managing, and in the education of the engineer. His/her work is predominantly intellectual and varied and not of a routine mental or physical character.

https://en.m.wikipedia.org/wiki/Engineer

Never does that occur in software. Most people employed to write software struggle to use giant tools to put text on screen and cannot measure things. That isn’t engineering. By the time a developer does graduate to a level commensurate with engineering we call them senior principles to distinguish them from the false engineers.

As someone who holds degrees in Real Engineering, I don’t care what computer programmers call themselves. I agree that most of the time, Software Engineer is an aspirational title, but you could say that about a fair number of electrical engineers too. You’re just not close enough to the field to see what marginal competence looks like. For that matter, Doctor was once an aspirational title for physicians, having been reserved for those licensed to give instruction in church doctrine. My point being, it’s fine. Nobody is ever going to confuse a software engineer for a real engineer, any more than you’re going to ask an MD about the nature of the Trinity.

> For that matter, Doctor was once

In that case what would it take for Software Engineer to become more than aspirational?

IIRC, Australia has actual licensing to call yourself a "software engineer." I assume you'd need actual laws passed to regulate the industry.

Eventually our understanding of the term will evolve to match its use, which is my point with the Doctor anecdote. Don’t try to fight the evolution of language; you may as well stand with Canute by the sea, yelling at the tide. No more did Victorian prescriptivists end the splitting of the infinitive.

Also, and it's striking to me that there never was a crackdown on this, but in a lot of countries, you cannot call yourself an engineer unless you have an engineering degree from a vetted higher-ed institution and are part of your provincial/state engineers' association.

For example, in N.S., your job title cannot contain the word engineer unless you're registered as an engineer with Engineers Nova Scotia, the provincial regulatory body. And to get the EIT status (engineer in training, the provisional period before becoming a professional engineer), you must hold a CEAB-accredited undergraduate degree. So, software engineers rarely exist and it's mostly software developers in N.S.

Why do you want the government to regulate what people are allowed to call themselves when there's no public benefit?

What harm is being caused by software developers calling themselves software engineers?

It's seems like authoritarian power-tripping to want to regulate this.

In the United States it is illegal to identify yourself as a police officer when you are not, and there are clear consequences for violating such laws. Professional titles either carry some sort of significance or they don't. The very clear consequence of titles/labels that aren't valid is fraud and there are very many laws in the US about this for a variety of venues.

It seems the only reason for a person to identify themself as some sort of engineer when they are not is fraud. What other would a person have to misrepresent themself?

Many professions have legally protected titles. In the USA it's illegal for someone without a CPA license to claim the title of "certified public accountant", and since engineering failures can have fatal consequences the same protection is offered to the title "engineer" (or "professional engineer", etc) in some countries.

You might argue that it's the certification that matters, not the title, but the title of "structural engineer" has been around for approximately as long as humans have been stacking up rocks to sleep under; the certifications have not.

There's a difference between software developers who glue together libraries to build cat picture voting sites and software developers who write real-time avionics firmware. The second type of developer can reasonably claim to be "software engineers" -- blueprints for a garden shed and for a skyscraper are distinguished by content, not medium.

Between those two limits the line must be drawn somewhere, and honest people will disagree about exactly where, but it seems reasonable to claim that people working in most software development positions of interest to Hacker News are closer to the latter than the former.

If you want to claim that junior developers are apprentices (journeymen? are apprentices interns?) and senior/staff/principal/whatever are engineers then that's fine (if idiosyncratic), but that's not what other people mean when they say or hear "software developers aren't engineers".

To be clearer: when you say the latter, do you mean the latter of your blueprints example or your avionics one? I'd guess that since most developers/engineers are working in things like web apps, fintech, applied AI/crypto, etc. these days that most of the folks contributing to and consuming HN are closer to the "not engineers" in your specific example, but that is indeed just an educated guess.

I meant avionics/skyscrapers -- edited to disambiguate.

The idea that most software developers are working in low-skill positions (i.e. distributing the output of an LLM over their Jira queue) is probably not as wrong as I wish it was, but those kind of developers aren't interested in software development as a craft to begin with, so I think (hope?) they aren't anywhere close to comprising most of the HN readership.

Also those positions don't pay as well; HN cares more about the $600k/yr jobs than the $60k/yr ones, and nobody pays $600k/yr for someone to copy-paste NPM invocations from Stack Overflow.

Reasons why nobody worthy of the title engineer should take this definition seriously:

1. It is recursive

2. It equates training and education with competence

3. It was written by a bureaucracy

I don't see why any of those are negative qualities.

Well number 1 is a negative quality because it is a negative quality.

And number 2 is bad because dogs (or LLMs) are trained, while humans are (hopefully) educated.

Sorry, not going to stop calling myself that. I have a diploma to prove it. It is in no way worse (or better) than any other diploma issued by my university.