>It is a natural consequence of people who only “develop” by gluing things together. God help them if they’d actually have to write some core function themselves.
That's on the industry for not training and gating well. It would be nice to have glue/plumber positions so expectations are not out of line too.
People can claim to be seniors because the gates for getting that title are pretty permissive. But even if you had the conviction to re-evaluate yourself ("do I deserve to be a senior engineer?"), you'll find tons of opinions on what it means to be senior, what knowledge they should know, and what they should bring to the table before claiming that. It's difficult to build yourself a widely accepted roadmap.
You have to watch out for people being too exclusionary though, almost getting into no-true-scotsman territory.
For instance: you can be a valuable contributor to a large, interconnected system, explain each part of it, but maybe not have the skills to build it from scratch. I would call that senior, but I wouldn't say architecting it from scratch is a basic skillset of this position. My opinion is if you could build large systems from scratch for a company, I'd say you probably need a title and pay higher than senior.
If you did want to roll architecture into a senior job, I'd imagine the pay is higher than non-architecting seniors, but it's hard to quantify the architecture contribution to the salary's bottom-line. If you took the non-coding architect's salary and added it to the senior's most of us would be clearing like 300k.
Personally, I'm pessimistic around job duties because you'll find so many companies looking for do-everything one-man armies at lower-end wages.
- you have an opinion on how things ought to be done and want a dialog
- you see some code that's wrong or violates an agreed-upon rule and so it should be changed with no discussion
I'd switch the tone based on what you're addressing. Giving a rationale when you share an opinion or point out a mistake also softens the tone (for the better IMO).
>* Should we extract this to a separate function?
>* Could you extract this to a separate function?
These are essentially the same: opening a dialog over an opinion. I'd suggest this when there's not an obvious flaw or rule violation or you have a gut-feeling about how code should be and want the author's input.
>* I would extract this to a separate function.
This is almost a command but isn't clearly one. It should be followed by some rationale, at least.
>* This could be extracted to a separate function.
This one's the least useful. You could do a lot of things with code. It doesn't resemble the command or inviting tones of the other examples here.
>* This should be extracted to a separate function.
>* Extract this to a separate function.
These are commands and are practically the same tone and best when catching mistakes. Unless obvious, a rationale should be given like a demonstrable flaw in logic or inconsistent abstraction, etc. There should be a few sentences explaining this. If there isn't a clear violation, I'd prefer the dialog invitation tones.
Full stack is not really a skill level qualifier - that's what junior, senior, principal, staff, etc. are for. It means you work in different areas and can't say "oh I don't do that work here" when someone gives you work in those areas. People call themselves front or back end engineers long before they've mastered it, and you don't have to wait for full stack either.
The front or backend bias you and your parent's comment talk about are team specific things so you don't give a hard front-end task to someone who is biased towards the backend. That still means they can take the less difficult tickets.
You can replace full stack for your example with "extremely good/talented/gifted engineer" and I'm almost sure it has nothing to do with the full stack label because it's the only example in a decade you've found.
But also the jobs that they get feed back into what they call themselves. So even if that's your example, it isn't how the business defines it, which IMO is ultimately why it's just a cost savings label to get people to work harder for similar amounts of pay as front or backend people.
>I don't know why full stack webdevs are paid so poorly. No really, they should be paid like half a mil a year just base salary. Fuck they have to understand both front end AND back end AND how different browsers work AND networking AND databases AND caching AND differences between web and mobile AND omg what the fuck there's another framework out there that companies want to use? Seriously, why are webdevs paid so little.
Full stack compresses two jobs into one. It's purely for cost-savings. They're paid so little because companies revert to "well, you can still only do 8 hours, so you do half as much of each", but really that's just them trying to weasel out of paying for knowledge. They also blur the lines by putting full stack along-side other devs, even though the other devs may not have invested the same time to gain as much knowledge as full stack.
When you take a full stack job, you undervalue your knowledge (and the time invested) and are selling it for roughly half of what it's worth.
>Basically no real user or admin-oriented docs. There's some example configs and some getting started guides, and then some crypto-nerd look-how-secure-our-algorithms-are docs, but no real guidance on how to set up a reasonably simple network of hosts.
It wasn't really in release mode until it was merged to the kernel, so that's pretty understandable. I had no networking knowledge aside from pentesting and I was able to get a tunnel working.
I don't think Wireguard was ever going to be like those other things. It sounds like you should wait for products to be built on top of Wireguard. Judging a fish's ability to climb a tree and all that.
That's on the industry for not training and gating well. It would be nice to have glue/plumber positions so expectations are not out of line too.