As well as a reminder for those not good at staying on task, it sounds worth considering for those who spend their day satisfying constant small ad hoc requests who later get asked "What have you been doing all day?"
Hopefully it has a "same as last time" button, I doubt this has the same cognitive distraction level as fielding a question from a colleague as well. I.e. understand their question, think of the context, etc etc
Bear in mind the tutorial is prefixed "Relearn..."
Though I'd class myself as a "full stack developer" css for a long time was the 2nd class citizen, with most of my time spent on learning to use front end frameworks in their idiomatic way, the "it depends" peculiarities of SQL and RDBMSs and making inroads on the vast tomb that represents architectuliary sound back ends.
So an article focussed on improving my "it's only css but it works" knowledge is one of the best things I've seen on HN in quite some time :)
A good full stack developer should have double the salary of a frontend/backend developer. Do you find this is the case? You need to be an expert at both roles plus have a third skill connecting them together.
A good full stack developer should
have double the salary of a frontend/backend
developer
There are (at least) two major reasons why this is not the case.
1. While theoretically possible, it's uncommon (and given the rate of change and increasing complexity of both front end and back end stacks, unrealistic) for a "full stack developer" to have expert-level production knowledge in both domains.
2. Even if #1 was true for a given developer, they wouldn't have double the productivity (and/or billable hours per week) as somebody who was more of a front-end or back-end specialist.
It's similar to the reasons why, in the medial world, general practicioners (aka "family doctors") do not earn money that is the... sum of all other medical professions earnings. They are generalists . Their role is to solve many problems, but also to refer many problems to the appropriate specialist.
I think there's often a leeway given to the full stack dev that they have strengths and limitations. I haven't got to the point where I could compete with the true / good front end dev with my skills.
Even at the backend you have the application backend (c# or whatever) and then sql/rdbms. If you are that good perhaps you deserve thrice the pay by this logic ;).
Jokes aside, at the last good company I worked for where I knew other people's pay, I was compensated for the entirety of my skills compared to the good front end dev. We earned the same, and I was quite happy with that.
I've been a backend developer for years and at times a frontend developer.
I've applied to a few full stack positions and the amount of specific knowledge in various topics they require seems much greater than either role separately.
When hiring or interviewing we tend to build up a big list of skills so the job looks impressive and attracts talent. Don't take the requirements too seriously.
Ideally the person doing the hiring is just measuring your knowledge. But I know many interviewers just try to eliminate candidates.
This could put off anyone who thinks they could be acquired by such companies from using your software as well. How can anyone know who is going to make it onto the blacklist for the next version etc. Seems quite the can of worms.
"At some point, I bet someone in a design meeting said "Hey, I think this might compromise security, can we study that before implementing it?"
And the decision to implement it without that study, or despite it, was made."
Because we should assume all your past missteps were due to willful negligence? Yeah, let's not just start making shit up to support the group think outrage.
agree, I really doubt people were like "let's compromise security for performance". More likely it was something like:
"hey here's an idea for how we can get more performance"
"convince me it's correct"
"oh, that's cause X, Y, Z..."
and either no one thought about the security implications, or no one could come up with a security problem at design time - likely just no one thought about side channel problems.
Not so much being a bad participant, but something I've found are developers who propose a solution to a problem outside of a meeting, but when it's then thrown out to the group for suggestions they remain quiet. Hard to know what advice to give for building confidence.
