Hacker News new | comments | ask | show | jobs | submit login

The two examples you gave, linting and tabs, aren’t architecture at all. They are toolchain.

Architecture is questions like should this class of functionality be services or objects and why? Do these 3 functions belong in this class, or should they be a helper? Should this helper be copied between repos or be a separate module with a formal API?

I agree with your point though that every engineer makes the decisions and having a separate role for them is weird.






These and the parent's examples are very team-centric. The heuristic I use when thinking about these engineering roles is, "Where is this person expected to be a leader?"

The progression is usually: Team, Cross-team, Organization, Industry. Competent technical decisions are table stakes. The real differentiator is at what level can they effect change.


This is the very thing I'm criticizing.

"Leader" is one of the worst buzzword bingo terms in a company. It means nothing, it's just a convenient label to give people who you feel like promoting to maintain the 10:1 ratio.

You could argue Linus Torvald is an industry leader, or you could argue he doesn't show adequate leadership for cross-team.


I think you very much understand a leader can be something more than a buzzword: "If you’re a leader in an organization, you need to be aware of the stories that occupy the minds you oversee."

Or maybe more succinctly: "If a great manager screws up, he should lay awake at night until he fixes it, just as a great engineer would wake up to fix a production issue."

These traits combined with a scope of influence is what I was referencing.


Well, that very post is criticizing self-proclaimed organization "leaders" for not holding themselves to the same level of basic accountability as a senior engineer would.

I do believe in leadership, in the abstract. But at the end of the day companies do whatever the hell people in power choose to (e.g. Fire Steve jobs, promote their friend, hire somebody sexy) and then come up with fancy meaningless words after the fact.

"Force multiplier" and "cross-team leader" are among those. If you really wanted to promote "leaders" then have engineers vote on who gets promoted...


You believe there are qualities that good leader would exhibit — in the abstract — but experience has never offered mentor, teacher, motivator you respect thus all promotions must be based on facets unrelated to merit: ignorance, nepotism, and sexism.

You may want to ask yourself if your viewpoints are a case of WYSIATI bias or a generalizable fact about how businesses are run.


You've totally lost me there.

I've had good managers before, I'm not sure why you're saying I haven't, or how that's related to my central claim.

Also "WYSIATI" is a misdirection. You could suggest that to anybody in any argument (I could suggest it to you now). But without providing any evidence of what those unseen factors are it's of no probative value.

I don't think you're trying to understand my point in good faith anymore so I'll leave it here.


Sorry I lost you. I understood you believe titles rarely align with skill and companies disingenuously use "leader" to justify a ratio of employees to managers. A company is as likely to promote on the basis of "hire somebody sexy" as anything else.

This mindset seems corrosive. I assume you had good managers, but I cannot imagine a career in which that was the norm would result in such cynicism.

My point was only this: in my experience, healthy organizations have a better value systems.


> Do these 3 functions belong in this class, or should they be a helper?

That's very basic design. System architecture goes up to: "how do we deploy 2 million hosts across 40 datacenters?"




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: