vsareto
The Agile style user stories that often lack technical details because the author doesn't know enough about the technical details means the developer is the one actually writing the requirements (usually as they are doing the work).
This seems a little inconsistent to me.
Is it really their fault if the industry says they are qualified and gives them a job when they are incompetent?
You'd be better off pair programming everything and forgoing code reviews.
Sometimes I think the people that come up with this shit are sociopaths.
It's possible he is right, but it is also possible that these traits aren't trainable, and without that, you may not have a population sufficient enough to sustain his ideal.
- being presented under-cooked ideas so you do the thinking for them.
- too many ideas (which can lead to the first) with an inability to focus
There is a feedback loop for the first where people don't dive too deeply into their idea because they know they'll get a lot of criticism.
The second can be bad because the idea or its implementation is never polished.
That market comparison is fraught with conditions and often only follows ill-defined job titles.
If you take a look at one of these postings - https://jobs.netflix.com/jobs/292552236 - you'll note that the way it's written, there aren't any exceptional job requirements here. It's hard to see why the salary range has such a high ceiling.
Obviously in the interview, they could have much higher requirements, but we don't know that unless someone from Netflix chimes in.
For example,
>You have knowledge of various regulations and controls (SOX, PCI, CCPA, GDPR, etc)
how much is knowledge of each of those worth towards the final salary? Pricing each of those would add more fidelity to the market's signals, but companies often don't do that. Same with technical skills or knowledge of individual products: how much is AWS knowledge worth at the beginner, intermediate, and expert levels to a job that needs AWS knowledge?
This is like buying a publicly traded stock (not yolo'ing) with roughly 80% of the company information not available to you. That information is there for a reason because it promotes market efficiency. It allows you to more easily compare two companies that do similar work.
This is what is meant by honesty, but the job market hides this information. And the job market is often dishonest because it does not price these things, because it is hiding information from applicants, because that gives an advantage to employers. An extremely wide salary range here only serves that goal.
And on the employee side, it would mean that I can go learn AWS to a certain level, and I know that skill would contribute $X amount to the final salary that I can ask for. I don't have to play games trying to sell my skills for more than they're worth.
But say you don’t want to forge one for just any company because that might not be legal. You could make your own company with a site and make offer letters that way.
This pricing scheme punishes people trying to be honest about their skill set. Otherwise why stop at the average? Just max it out and ask for $700k. Another $300k/yr won't break Netflix's bank and everyone else is getting rich that they won't care to call you out either.
This just rings hollow to me. We lost the fights for database portability, cloud portability, payments/billing portability, and other individual SaaS lock-in. I don't see why it'll be different this time around.
You can't trust companies to self-regulate.
That sounds tedious like commenting every line of code. You might have to do this if the code is hard to read and maintain though. Most of the time the why is "because feature X demands that it change".
Maybe it's just me, but I prefer squashed merges because lots of small commits are also annoying to switch between and if I'm diving into git history, I'm investigating and have some extra time to understand everything instead of relying on commit messages.
Secondarily, why should the author continue to fix things like this when they don't benefit, but others responsible are also not facing any consequences?
Finland has something different than that though and it sounds like it's harder to fire people.
I must be a mercenary because that still reads to me as "we can do these things instead of paying you more". In fact, there is no mention of where their compensation falls, so it would be especially rude to do all of these things and then underpay your employees.
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.
If some don't return, they'll relax hiring requirements until they're filled. Hiring requirements from top companies have a lot of room to relax - easier questions, less interview rounds, etc.
Maybe this time is different with higher interest rates?
Then they find themselves among high performers and can't keep up, really through no fault of their own.
Some high performers are just natural and born with it, which is unfair to let that affect how anyone judges others' performance, but it still happens too (esp. if the high performer is doing the judgment).
What I generally see when people categorize their workers into high/low performance is from a bigger issue of poor stewardship over the industry and training its talent.
This means I don't actually have to improve, I can instead just spam job applications and get lucky just because technology is such a large industry.
- you spend more time to keep up with both of those sectors compared to dedicated front or back end positions
- you context switch more often than dedicated positions
- you spent more time getting good at both of those things
- you removed some amount of communication overhead if there were two positions
You are definitely not being compensated for that extra work and benefit to the business given that full stack salaries are close to front end and back end position salaries.
And they likely won’t be as good as dedicated SRE teams.
But few businesses care about that right now considering layoffs.
Throwing developers at a problem even if it isn’t in their skill set is an industry trend that won’t go away and be more pronounced during downturns.
Full stack developers are a great example of rolling two roles together without twice the pay.
I have somewhat avoided this because it can make you look like you're changing things for no good reason (no easily communicable reason, anyway).
I still do it when people have too much going on for a single line though (ternary ops + function calls + string/number formatting, etc which is very common in enterprise-y programs).
I don't think this is a real problem IMO. If you learned it in the first place, you can learn it again after slacking off for a bit. You might need a few months for the focused effort, which is honestly not a cost but probably what we in the industry call a sabbatical.
It may add some risk to getting a job if your life is suddenly turned upside down after slacking and you need a job right this instant. That slacking might fail you some interviews, but not all of them. Even in this situation, there are financial options and temp jobs to get by with.
I don't think anyone should ever be convinced that if you stop practicing something that your ability disappears completely. I'd put some faith into the idea that you can relearn it just as well or better when the need arises.