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.
jahsome 36 days ago [-]
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?
zug_zug 36 days ago [-]
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.
jahsome 34 days ago [-]
The hypothetical question as I understand it isn't about which skills, but rather which activity yields the greatest expected value.
austin-cheney 36 days ago [-]
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.
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.
sevensor 36 days ago [-]
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.
austin-cheney 36 days ago [-]
> For that matter, Doctor was once
In that case what would it take for Software Engineer to become more than aspirational?
withinboredom 36 days ago [-]
IIRC, Australia has actual licensing to call yourself a "software engineer." I assume you'd need actual laws passed to regulate the industry.
sevensor 36 days ago [-]
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.
fffrantz 36 days ago [-]
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.
ahtihn 36 days ago [-]
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.
austin-cheney 36 days ago [-]
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?
jmillikin 36 days ago [-]
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.
jmillikin 36 days ago [-]
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".
mathgeek 36 days ago [-]
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.
jmillikin 36 days ago [-]
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.
fallingknife 36 days ago [-]
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
austin-cheney 36 days ago [-]
I don't see why any of those are negative qualities.
fallingknife 35 days ago [-]
Well number 1 is a negative quality because it is a negative quality.
MonkeyClub 34 days ago [-]
And number 2 is bad because dogs (or LLMs) are trained, while humans are (hopefully) educated.
odiroot 36 days ago [-]
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.
t43562 35 days ago [-]
Cultural fit to me is a completely inadequate term to describe what I'm thinking about in an interview.
Are they going to be an arsehole? This is my biggest worry after dealing with a couple, first as people above me then as members of my first team as a combined team lead/line manager. This is about being able to be reasoned with and not destroying team morale. I have always tended to feel that being right is more important than harmony but over time I realised how many of my "right" decisions were balanced by wrong ones and however many times I thought I saved the team with some good idea, someone else did it just as much with another one.
In other words I'm on the very edge, at best, of being the arsehole myself. Someone who is further over the line than me definitely makes it miserable to go to work. I want my team to get on reasonably and each get a feeling of fullfillment out of the day and feel respected which requires good behaviour from me but also from them. I perhaps wouldn't want to say this to my own boss (who is ok) but I really care about this more than about the company itself.
Companies have no loyalty and will make you redundant at the drop of a hat. They also sometimes do silly things which doom them and prevent you from being able to save the situation. You get given impossible things to do and stress out trying to do them. While this is happening, however, we can have a reasonable week without undue drama, fights, humiliation or fear. There's no reason that good software can't be the end result but more importantly you'll have an experienced team at the end who get better and better at working together and are potentially going to stay on.
dfee 35 days ago [-]
> For those looking to transition into leadership,
My biggest pet peeve in this industry is the self anointing of the “leadership” attribute.
Its management. Just management. Some managers may be leaders, but most aren’t. Some ICs may be leaders. Most aren’t. Some politicians may be leaders, but most aren’t.
Or maybe I just never grasped what leadership means. Either in the context of the world or our industry.
cbsmith 35 days ago [-]
I'm with you. There is a world of difference between leadership and management. Plenty of engineers who are good leaders.
AllegedAlec 36 days ago [-]
Before reading: making the text highlight colour the same as the background is a choice.
drorn 36 days ago [-]
This needs to be discussed more.
Great article though.
roenxi 36 days ago [-]
> Whether it’s debates like the shift from master to main in git or deeper discussions around inclusivity in language (master/slave rename in redis), these things can shape team culture.
Well, that'll certainly do something to team culture. If an EM seemed to be significantly invested in this sort of decisions then I would form strong opinions about their ability to prioritise.
This is just not an issue that is going to determine the success of the company. If, in some amazing conjunction of circumstance, it does there are terrible terrible problems in the hiring pipeline or in who is being promoted to leadership positions because it suggests the company is a barely controlled powderkeg.
And, frankly, this is not what culture looks like. This is preformative name changes to provide a distraction from whatever the real cultural activity is - which is determined by what the EM rewards and punishes; not by what they signal in low-impact cosmetic policies. That is branding - which is important but not a fraction as important as culture.
dijksterhuis 36 days ago [-]
You're seemingly presenting this as an option between two binary cases.
paraphrasing my impression of the vibe of your comment into the two distinct options:
> Your collective opinions about how we work as a team matter
> You're only here to work on things that are considered a priority
In reality, there is always some nuance/middle ground available
> Your opinions about how we work here matter. If this is something that requires a full rewrite it's probably going to be a no. But if it's not a major change causing a lot of work, we can possibly take a look at it.
If you've set up CI/CD properly, changing the name of the default branch can be done in less than an hour. Source: I did it at $last_company for circa 10x repos in about an hour. This was not related to inclusivity, but it did involve a discussion about whether we should switch or not: why; how; pros; cons.
Having a conversation about changing due to inclusivity is just a different meeting with a different why, how, pros, cons. One of the why/pros arguments might be -- that's now the accepted general default for most (external) repositories so keeping it as master would be kinda weird and might end up needing some explanation during onboarding -- i.e. more work somewhere else later on.
twelve40 36 days ago [-]
i think this is actually good advice when rephrased as: you are now a low-to-middle manager (that is called out specifically), so you neither call the shots nor are you mainly measured on your daily tech contributions, so from now on you can no longer avoid whimsical, irrelevant BS that is a waste of time like debating the branch names, because fielding that is a part of your job description now, so you need to embrace it and handle these conversations with a happy smile on your face, so that the people who actually move the project forward are not distracted by it.
dijksterhuis 36 days ago [-]
Sort of. I wouldn't call it whimsical, irrelevant BS though. From the article:
> I remind myself that my role isn’t to be the most skilled person in the room but to create an environment where the most skilled people can thrive.
If most people in the team think we should switch to main instead of master, why would I sit there and deny the change? How am I going to find out if most people on the team think this way? Ask the question, let a discussion in whatever forum ensue, make some notes, ask some "dumb" columbo style questions, see what comes out of it.
It's not about me being right anymore. It's about the team being right. Ideally, together.
pas 36 days ago [-]
Usually these things are obvious, no? (If not then it's going to be very challenging to be a [people] manager.)
Depending on location and/or cultural composition of the team these things will be either no-issue (no one cares enough to voice either approval or opposition, if some change is requested by management or some platform introduces some changes it's just inconsequential for the team) or there will be someone who sometimes will voice suppport/opposition so their needs have to be weighted (but as long as there's no conflict within the team it's smooth sailing) and then, if there is conflict then there's obviously a cold war in the making. (And at that point either the manager has enough authority and agency to work out some lasting compromise, start removal of someone, or they are at least can recognize that it's time to look for a new job, as things about to get ugly.)
dijksterhuis 35 days ago [-]
I find your comment interesting. You start by saying, well, this should be obvious, right? Then you list five cases where, to me, things are not obvious. Like, i have so many hypothetical questions about each case. I won't bore you with them, but the change being pushed by management one i find particularly interesting.
Usually these are things we don't want to do, or shouldn't do (else we'd probably have done it already or have a plan for it at least). But folks in "management" or "executive teams" usually don't listen to engineering arguments about complexity spirit demons :(
so there are a lot of political questions i'd be asking in my head with that. e.g. Can we use this as a negotiation tool to stop "management" pushing for this-other-thing-we-also-don't-want-to-do?
pas 33 days ago [-]
I have trouble applying your comment to mine (and back to yours about master/main changes, or in general to issues relating to culture fit), sorry!
Can you give a concrete example?
dijksterhuis 30 days ago [-]
sorry for the delay, hope you end up seeing this reply.
so, specifically with “management hast decreed thou shalt do X”, there’s always quite a bit of politics stuff that can be played here.
- do they also want Y?
- out of X and Y, which one do they want more?
- if the engineering team are really resistant to Y, can we say we’ll do X first and see if they forget about Y by the time we’ve done X?
- what about Z? Z is kind of similar to X, but solves a specific customer’s problem alongside it. can we suggest Z instead?
- or are management too pissed if from last month when i spent half of it negotiating about S? do we just need to lump it with X?
- is engineering fed up with these requests? is morale tanking because of micromanaging from executives? or are people fine with it?
- is there some 80/20 hack solution we can put live in one sprint and then depreciate in 3 months time? are they going to notice this?
those are the sorts of questions i’d have around X being asked by management.
unless it’s a legal compliance thing, i generally doubt anyone in management requests anything because they use the product and want a solution to a problem.
so, they get a very strong filter applied to them.
like, $previousJob built a poor man’s clone of apache airflow in django. management were coming up with new feature ideas while we were literally in a meeting about replacing everything except the frontend with apache airflow or similar.
like, no, we won’t be adding event/time based triggers. airflow does that already! that’s the point of this meeting dammit!
the data science team on the other hand are basically dogfooding our imaginary product, so their filter is a bit lesss harsh. they actually have problems that need solving in the imaginary product.
so i usually “negotiate” less with them and focus more on understanding why they want what they want.
don’t let shit roll down on the team basically.
that help clarify things? probably not :/
pas 25 days ago [-]
Ah, okay, I think somehow you parsed my very terse comment to mean something about (top) management's request, but I wanted to illustrate that a (line = engineering) manager knows roughly how their team(s) would react to these requests, and knows which battles to pick and with which side(s).
Like you said, if there's something crazy coming down from up? maybe it's umbrella time. If there's a company- or industry-wide shift and someone in a team is not having it? Maybe it's time for some fluctuation. And so on.
I'm trying to say that most things are "obvious" (well, yeah, either so obvious that I wasn't even able to describe it by the examples, or "so obvious" that it takes 4 pages of back-and-forth to clarify it :D)
My comment was a reaction to your recommendation of Columbo style. "How am I going to find out if most people on the team think this way" ... and my very "zen" (and unhelpful?) answer was that "it should be obvious", uh, sorry :)
bilvar 36 days ago [-]
Oh my god, if my manager asked me to waste my time on such trivialities - or even worse, calling team meetings to “discuss” them so that we can now collectively waste our time, I would quit the next moment. During my exit interview I would state that my manager was an imbecile, incompetent and the reason I am leaving.
dijksterhuis 35 days ago [-]
> calling team meetings to “discuss” them so that we can now collectively waste our time
it's not a dedicated meeting conversation. I would probably post it as a slack thread. If anyone wants to put their thoughts in, go ahead. If you don't, fine.
Number of people in the team who don't post by the end of the day ==> number of people who don't care.
Number of people in the team who do post by the end of the day ==> number of people who do care.
if number of people who do care > number of people who don't care, read the comments on the train home and have a think about what to do about it.
> During my exit interview I would state that my manager was an imbecile, incompetent and the reason I am leaving.
Well... that sounds like a good way to burn a reference.
edit —
> waste my time on such trivialities
in your own individual personal opinion this thing is trivial.
being part of a team means being part of a larger whole. whatever that looks like — including if other people on the team don’t share your opinion, or have similar but different opinions.
funnily enough the article explicitly mentions differing opinions being a good thing.
bilvar 34 days ago [-]
Your job as a manager is to cut noise down for your team, so that they can focus on the signal. If you cannot decide on your own that some things are just plain silly and not worth their time to democratize the decision, then you’re not cut out for this job - sorry.
fallingknife 36 days ago [-]
But changing the name of the default branch is not worth one hour of eng time, much less the annoyance of the other team members. I understand that the term "master" is offensive to upper class white people, but I just don't care. They need to stop acting like crybabies and get on with doing their jobs.
dijksterhuis 35 days ago [-]
It was in our case, because of legacy working practices from the old team (who weren't there when we arrived). It was making everything more confusing for us, and annoying. We weren't working in the same way they did (which was completely nonsensical in my view).
So it made sense to switch things after putting up with it for 6 months. We were annoyed enough that the mental load of not being annoyed about it anymore was worth one hour of me changing it so we could show up to work free of being annoyed of this specific thing. Plus we were getting new hires who were very junior, so having things match "how to git" tutorials on the internet made way more sense. Plus it made every repo match, no longer did we have 10x repos doing things one way and another 30x doing things another way.
I legit just had to click a bunch of buttons in gitlab for an hour. It wasn't hard. I've wasted way more time sitting in meetings with executives talking nonsense.
The pro strat would probably have been to do this while in a meeting with executives tbh.
36 days ago [-]
twelve40 36 days ago [-]
Yeah if they have time for "deeper discussions" about this, just run. Apparently, it's higher up in the article than the "choose postgres" managerial advice lol
rectang 36 days ago [-]
Fine by me. Tech companies can sort themselves into groups: those where such discussions are welcomed and those who run from them.
And I'm happy to see a manager put the "people" section above the section on "technology":
> As an EM, your role isn’t just about managing the technical—it’s about understanding the people behind the work.
36 days ago [-]
roenxi 36 days ago [-]
> As an EM, your role isn’t just about managing the technical—it’s about understanding the people behind the work.
Yeah it is a lovely sentiment, but it is a sweet nothing if someone doesn't understand the techniques to back up nice words with an appreciation for the people behind the work.
We discover in the follow up that to this EM it means engaging in endless debate (the GitHub issue may have more spilled ink than a Tolstoy work) over the appropriate default branch name. That isn't what prioritising people should look like in practice. In fact that sort of debate springing up and becoming a serious milestone is the sort of thing that should trigger a check for whether empathy failures are taking place. Why is a culture developing where the team is being focusing on such trivialities instead of something that promotes their success or the success of groups like the greater organisation or customers? People with empathy tend to focus on the actual success of real people; and anything more than a cursory aye/nay poll on branch naming would be a concern because it suggests that the real problems every team has aren't getting attention.
fzeroracer 36 days ago [-]
> Why is a culture developing where the team is being focusing on such trivialities instead of something that promotes their success or the success of groups like the greater organisation or customers?
> People with empathy tend to focus on the actual success of real people; and anything more than a cursory aye/nay poll on branch naming would be a concern because it suggests that the real problems every team has aren't getting attention.
I think there's a bit of irony in your two statements because you're arguing that the EMs should lack empathy for changes you deem trivial, and have empathy for changes you don't deem trivial. This is how you destroy an organization because these small issues fester into something more poisonous for your org.
For example, the branch naming schema cuts both ways. You could have a mostly yay vote on the branch naming pass, but the nay vote interprets it highly negatively or vice versa. Which means it's the EMs job to try and defuse that situation both by being welcoming enough to address these trivial complaints and by trying to identify the root cause.
roenxi 36 days ago [-]
> ...you're arguing that the EMs should lack empathy for changes you deem trivial
If an EM can't identify this change as trivial then they are going to be on the bottom of the spectrum of EM managers. It is trivial, everyone can tell that. Which side of the decision anyone comes down on is up to them, but if the issue of prioritising branch names becomes a subject of long talks, meaningful debate, inquiry and fact finding missions then the EM has done a bad job. OSS projects can tolerate that sort of thing because the entire OSS movement is ideological from the foundations up so they have to deal with ideological issues. But workplaces are for a different set of standards and ideally involve some professionalism.
If you have formed a genuine connection with someone, probed their emotional state and determined that the default label of the git repo is important enough to them that they are going to feel strong emotional disturbance over? And that it is the biggest issue in their professional life and deserves to be prioritised for follow up? The right thing to do is probably to send them to get some professional help. Or congratulate them on having achieved true joy in the workplace. Or reassess your ability to read people because you just probably got it wrong. Any which way such people are remarkably rare - generally more empathy will uncover that the default branch name is not the major issue that needs work.
36 days ago [-]
dijksterhuis 36 days ago [-]
Nice write up. Liked the thing on spotlighting. Experienced that in a non-dev role before and never really realised what that was at the time.
Some bits reminded me of some of the lessons in the linux kernel management style guide, so gonna link it here in case someone hasn't come across it before.
In my experience engineering managers have been just exception handlers, not leaders. If they can handle the exception by finding the right person to delegate to its fine, otherwise they rethrow so that that it bubbles up and the next level of management can catch it.
Generally, they never made any real decisions or have any real vision to inspire with and execute.
withinboredom 36 days ago [-]
Are you on a team with strong personalities that actually lead? If so, then that manager is probably a bug in their ear about what the business wants. I love and hate managing those types of team because it is literally like herding cats. When they are going in the right direction, it is a blast. When they disagree with you, it can be painful. Especially if you have no real teeth to provide negative feedback.
Leading a team when everyone is just "there for a paycheck" is much easier, but not as much fun. You basically just need to make sure all the tickets are lined up and everyone is working on the right things.
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.
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?
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.
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.
In that case what would it take for Software Engineer to become more than aspirational?
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.
What harm is being caused by software developers calling themselves software engineers?
It's seems like authoritarian power-tripping to want to regulate this.
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?
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.
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".
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.
1. It is recursive
2. It equates training and education with competence
3. It was written by a bureaucracy
Are they going to be an arsehole? This is my biggest worry after dealing with a couple, first as people above me then as members of my first team as a combined team lead/line manager. This is about being able to be reasoned with and not destroying team morale. I have always tended to feel that being right is more important than harmony but over time I realised how many of my "right" decisions were balanced by wrong ones and however many times I thought I saved the team with some good idea, someone else did it just as much with another one.
In other words I'm on the very edge, at best, of being the arsehole myself. Someone who is further over the line than me definitely makes it miserable to go to work. I want my team to get on reasonably and each get a feeling of fullfillment out of the day and feel respected which requires good behaviour from me but also from them. I perhaps wouldn't want to say this to my own boss (who is ok) but I really care about this more than about the company itself.
Companies have no loyalty and will make you redundant at the drop of a hat. They also sometimes do silly things which doom them and prevent you from being able to save the situation. You get given impossible things to do and stress out trying to do them. While this is happening, however, we can have a reasonable week without undue drama, fights, humiliation or fear. There's no reason that good software can't be the end result but more importantly you'll have an experienced team at the end who get better and better at working together and are potentially going to stay on.
My biggest pet peeve in this industry is the self anointing of the “leadership” attribute.
Its management. Just management. Some managers may be leaders, but most aren’t. Some ICs may be leaders. Most aren’t. Some politicians may be leaders, but most aren’t.
Or maybe I just never grasped what leadership means. Either in the context of the world or our industry.
Great article though.
Well, that'll certainly do something to team culture. If an EM seemed to be significantly invested in this sort of decisions then I would form strong opinions about their ability to prioritise.
This is just not an issue that is going to determine the success of the company. If, in some amazing conjunction of circumstance, it does there are terrible terrible problems in the hiring pipeline or in who is being promoted to leadership positions because it suggests the company is a barely controlled powderkeg.
And, frankly, this is not what culture looks like. This is preformative name changes to provide a distraction from whatever the real cultural activity is - which is determined by what the EM rewards and punishes; not by what they signal in low-impact cosmetic policies. That is branding - which is important but not a fraction as important as culture.
paraphrasing my impression of the vibe of your comment into the two distinct options:
> Your collective opinions about how we work as a team matter
> You're only here to work on things that are considered a priority
In reality, there is always some nuance/middle ground available
> Your opinions about how we work here matter. If this is something that requires a full rewrite it's probably going to be a no. But if it's not a major change causing a lot of work, we can possibly take a look at it.
If you've set up CI/CD properly, changing the name of the default branch can be done in less than an hour. Source: I did it at $last_company for circa 10x repos in about an hour. This was not related to inclusivity, but it did involve a discussion about whether we should switch or not: why; how; pros; cons.
Having a conversation about changing due to inclusivity is just a different meeting with a different why, how, pros, cons. One of the why/pros arguments might be -- that's now the accepted general default for most (external) repositories so keeping it as master would be kinda weird and might end up needing some explanation during onboarding -- i.e. more work somewhere else later on.
> I remind myself that my role isn’t to be the most skilled person in the room but to create an environment where the most skilled people can thrive.
If most people in the team think we should switch to main instead of master, why would I sit there and deny the change? How am I going to find out if most people on the team think this way? Ask the question, let a discussion in whatever forum ensue, make some notes, ask some "dumb" columbo style questions, see what comes out of it.
It's not about me being right anymore. It's about the team being right. Ideally, together.
Depending on location and/or cultural composition of the team these things will be either no-issue (no one cares enough to voice either approval or opposition, if some change is requested by management or some platform introduces some changes it's just inconsequential for the team) or there will be someone who sometimes will voice suppport/opposition so their needs have to be weighted (but as long as there's no conflict within the team it's smooth sailing) and then, if there is conflict then there's obviously a cold war in the making. (And at that point either the manager has enough authority and agency to work out some lasting compromise, start removal of someone, or they are at least can recognize that it's time to look for a new job, as things about to get ugly.)
Usually these are things we don't want to do, or shouldn't do (else we'd probably have done it already or have a plan for it at least). But folks in "management" or "executive teams" usually don't listen to engineering arguments about complexity spirit demons :(
so there are a lot of political questions i'd be asking in my head with that. e.g. Can we use this as a negotiation tool to stop "management" pushing for this-other-thing-we-also-don't-want-to-do?
Can you give a concrete example?
so, specifically with “management hast decreed thou shalt do X”, there’s always quite a bit of politics stuff that can be played here.
- do they also want Y?
- out of X and Y, which one do they want more?
- if the engineering team are really resistant to Y, can we say we’ll do X first and see if they forget about Y by the time we’ve done X?
- what about Z? Z is kind of similar to X, but solves a specific customer’s problem alongside it. can we suggest Z instead?
- or are management too pissed if from last month when i spent half of it negotiating about S? do we just need to lump it with X?
- is engineering fed up with these requests? is morale tanking because of micromanaging from executives? or are people fine with it?
- is there some 80/20 hack solution we can put live in one sprint and then depreciate in 3 months time? are they going to notice this?
those are the sorts of questions i’d have around X being asked by management.
unless it’s a legal compliance thing, i generally doubt anyone in management requests anything because they use the product and want a solution to a problem.
so, they get a very strong filter applied to them.
like, $previousJob built a poor man’s clone of apache airflow in django. management were coming up with new feature ideas while we were literally in a meeting about replacing everything except the frontend with apache airflow or similar.
like, no, we won’t be adding event/time based triggers. airflow does that already! that’s the point of this meeting dammit!
the data science team on the other hand are basically dogfooding our imaginary product, so their filter is a bit lesss harsh. they actually have problems that need solving in the imaginary product.
so i usually “negotiate” less with them and focus more on understanding why they want what they want.
don’t let shit roll down on the team basically.
that help clarify things? probably not :/
Like you said, if there's something crazy coming down from up? maybe it's umbrella time. If there's a company- or industry-wide shift and someone in a team is not having it? Maybe it's time for some fluctuation. And so on.
I'm trying to say that most things are "obvious" (well, yeah, either so obvious that I wasn't even able to describe it by the examples, or "so obvious" that it takes 4 pages of back-and-forth to clarify it :D)
My comment was a reaction to your recommendation of Columbo style. "How am I going to find out if most people on the team think this way" ... and my very "zen" (and unhelpful?) answer was that "it should be obvious", uh, sorry :)
it's not a dedicated meeting conversation. I would probably post it as a slack thread. If anyone wants to put their thoughts in, go ahead. If you don't, fine.
Number of people in the team who don't post by the end of the day ==> number of people who don't care.
Number of people in the team who do post by the end of the day ==> number of people who do care.
if number of people who do care > number of people who don't care, read the comments on the train home and have a think about what to do about it.
> During my exit interview I would state that my manager was an imbecile, incompetent and the reason I am leaving.
Well... that sounds like a good way to burn a reference.
edit —
> waste my time on such trivialities
in your own individual personal opinion this thing is trivial.
being part of a team means being part of a larger whole. whatever that looks like — including if other people on the team don’t share your opinion, or have similar but different opinions.
funnily enough the article explicitly mentions differing opinions being a good thing.
So it made sense to switch things after putting up with it for 6 months. We were annoyed enough that the mental load of not being annoyed about it anymore was worth one hour of me changing it so we could show up to work free of being annoyed of this specific thing. Plus we were getting new hires who were very junior, so having things match "how to git" tutorials on the internet made way more sense. Plus it made every repo match, no longer did we have 10x repos doing things one way and another 30x doing things another way.
I legit just had to click a bunch of buttons in gitlab for an hour. It wasn't hard. I've wasted way more time sitting in meetings with executives talking nonsense.
The pro strat would probably have been to do this while in a meeting with executives tbh.
And I'm happy to see a manager put the "people" section above the section on "technology":
> As an EM, your role isn’t just about managing the technical—it’s about understanding the people behind the work.
Yeah it is a lovely sentiment, but it is a sweet nothing if someone doesn't understand the techniques to back up nice words with an appreciation for the people behind the work.
We discover in the follow up that to this EM it means engaging in endless debate (the GitHub issue may have more spilled ink than a Tolstoy work) over the appropriate default branch name. That isn't what prioritising people should look like in practice. In fact that sort of debate springing up and becoming a serious milestone is the sort of thing that should trigger a check for whether empathy failures are taking place. Why is a culture developing where the team is being focusing on such trivialities instead of something that promotes their success or the success of groups like the greater organisation or customers? People with empathy tend to focus on the actual success of real people; and anything more than a cursory aye/nay poll on branch naming would be a concern because it suggests that the real problems every team has aren't getting attention.
> People with empathy tend to focus on the actual success of real people; and anything more than a cursory aye/nay poll on branch naming would be a concern because it suggests that the real problems every team has aren't getting attention.
I think there's a bit of irony in your two statements because you're arguing that the EMs should lack empathy for changes you deem trivial, and have empathy for changes you don't deem trivial. This is how you destroy an organization because these small issues fester into something more poisonous for your org.
For example, the branch naming schema cuts both ways. You could have a mostly yay vote on the branch naming pass, but the nay vote interprets it highly negatively or vice versa. Which means it's the EMs job to try and defuse that situation both by being welcoming enough to address these trivial complaints and by trying to identify the root cause.
If an EM can't identify this change as trivial then they are going to be on the bottom of the spectrum of EM managers. It is trivial, everyone can tell that. Which side of the decision anyone comes down on is up to them, but if the issue of prioritising branch names becomes a subject of long talks, meaningful debate, inquiry and fact finding missions then the EM has done a bad job. OSS projects can tolerate that sort of thing because the entire OSS movement is ideological from the foundations up so they have to deal with ideological issues. But workplaces are for a different set of standards and ideally involve some professionalism.
If you have formed a genuine connection with someone, probed their emotional state and determined that the default label of the git repo is important enough to them that they are going to feel strong emotional disturbance over? And that it is the biggest issue in their professional life and deserves to be prioritised for follow up? The right thing to do is probably to send them to get some professional help. Or congratulate them on having achieved true joy in the workplace. Or reassess your ability to read people because you just probably got it wrong. Any which way such people are remarkably rare - generally more empathy will uncover that the default branch name is not the major issue that needs work.
Some bits reminded me of some of the lessons in the linux kernel management style guide, so gonna link it here in case someone hasn't come across it before.
https://www.kernel.org/doc/html/latest/process/management-st...
Generally, they never made any real decisions or have any real vision to inspire with and execute.
Leading a team when everyone is just "there for a paycheck" is much easier, but not as much fun. You basically just need to make sure all the tickets are lined up and everyone is working on the right things.