I have literally never seen or thought of this as “senior” thing. if anyone on the team regardless of their seniority does not operate this way they will see a quick exit to some other place
every parent that is “pro” book banning is a shitty parent, period. I am kind of glad this book banning has spread as it helped me weed out some people from my life. life is to short to spend around shitty parents. I can pretty much live with any flaw (I have 100’s) but being a shitty parent is not one I am willing to be around
it is possible through legislation. slap them with the fine equal to their two previous years ebita combined and all this stops within an hour. of course not like people that need to pass a legislation aren’t bought for a fraction of that.
these things are why frequent comments on HN that go “this company is not using our data for training, it is in ToS etc…” makes me literally LOL.
what is a larger issue? lacking domain knowledge? or lacking deeper understanding of years of shit in the codebase that seniors may have better understanding? where I work, there is no issue that it "too large" for a junior to take on, it is the only way that "junior" becomes "non-junior" - by doing, not by delegating to so-called seniors (I am one of them)
"Larger issue" is overall technical direction and architecture, making decisions that don't paint you into a corner, establishing maintainability as a practice, designing work around an organization's structure and habit and so on.
But these are the things people learn through experience and exposure, and I still think AI can help by at least condensing the numerous books out there around technology leadership into some useful summaries.
Just curious, are you mostly FE? I could see this there (but there is still a lot of browser esoteria, etc)
Doing backend and large distributed systems it (seems to me), much deeper. Types of consistency and their tradeoffs in practice, details like implementing and correctly using lamport clocks, good API design, endless details about reworking, on and on.
And then for both, a learned sense of what approaches to system organization will work in the long run (how to avoid needing to stage a re-write every 5 years).
I still agree more or less that the best way for a junior to succeed is to jump in the deep end, not without guidance though. Mentorship is really important in distributed systems where the inner machinations can be quite obtuse. But I find you can't just explain it all and expect it to stick, mentoring someone through a task is the best way.
Not at all. Just trying to understand a POV I think I see here, and in other discussions that I can't quite place / relate to.
The person I replied to seemed to be saying that there is no role for experience, beyond knowing the language, tools, and the codebase. There is no real difference between someone with 5 years of experience and 15 years. This may not be what the think, or meant to say, I'm extrapolating a bit (which is why I asked for clarification)
That attitude (which I have run into in other places) seems totally alien to me, my experience, and that of my friends and colleagues. So, I think there must be some aspect that I'm missing or not understanding.
You can't give a junior tasks that require experience and nuance that have been acquired over years of development. If you babysit them, then perhaps but then what is the point? By it's nature "nuance" is something hard to describe concretely but as someone who has mentored a fair few juniors most of them don't have it. AI generally doesn't have it either. Juniors need tasks at the boundary of their capability, but not far beyond to be able to progress. Simply allowing them to make a mess of a difficult project is not a good way to get there.
There is such a thing as software engineering skill and it is not domain knowledge, nor knowledge of a specific codebase. It is good taste, an abstract ability to create/identify good solutions to a difficult problem.
> If you babysit them, then perhaps but then what is the point
In a long term enterprise the point is building up a long term skillset into the community. Bolstering your teams hive mind on a smaller scale also.
But work has evolved and the economy has become increasingly hostile to long term building, making it difficult to get buy in for efforts that don't immediately get work done or make money.
Perhaps, I don't consider them shitty myself but palates differ. Is engineering nirvana a place where tasks are such that any can been done by a junior engineer, and the concept of engineering skill developed through experience is non-existent?
> Is engineering nirvana a place where tasks are such that any can been done by a junior engineer, and the concept of engineering skill developed through experience is non-existent?
how does one junior acquire engineering skills except through experience as you said?
Unnecessary complexity, completely arbitrary one off designs, over emphasis on one part of the behavior while ignoring others. Using design patterns where they shouldn't be used, code once and forget operations exist, using languages and framework that are familiar but unfit for that purpose. The list goes on and I see it happen all the time, AI only makes it worse because it tend to verify all of these with "You're absolutely correct!".
Every team has incompetence at some level. If every team was perfect, there would be no more work left to do, because they would always get the right product built correctly the first time. No bug fix releases, no feature refreshes, no version 2.
been hacking 31 years with the same ego but you never know. and if I learned anything in these years is to get out the heck out of any place that treats people not by their skills but by how long ago their Mom gave them birth
reply