Oct 1, 2023·edited Oct 1, 2023Liked by Sibelius Seraphini
This is happening all across th tech sector. I'm in the sysadmin field and it's happening in my industry too. Senior admins coming in without basic knowledge is very frustrating and I hesitate to teach them because they should already know these things.
I don't really agree with the mapper/packer analogy though it did reming me of the map/reduce (Hadoop) data processing algorithm. 😁
My son is in college learning to code (computer engineering) and he'll "stand in the shoulders of giants" without knowing how the bottom layers work but that's how it'll be done down the road and that's ok. He'll complete his assignments and he'll make websites and services and build stuff by looking it up on stack overflow. It's the same as us in college except we had to begrudgingly look things up in books or figure it out ourselves (which didn't always work well or wasn't very efficient when we had to re-invent stuff). 😁
The world will be fine. The younger generation doesn't need to be experts in everything unless there is an apocalypse and if that happens, we'll have bigger problems to worry about.
I also think that too many people have the "senior" title simply because of scarcity. There is no one to hire, so companies are willing to pay more. In order to avoid creating inconsistencies between salaries, they hire lower level people with the senior title.
There is also the issue of many "Senior" Developer/Software Engineer roles being posted, and they require X years of experience in Y language. This should mean nothing, because maybe the "Y language" is already obsolete or less used in companies, or even worse, the potential candidate doesn't really have knowledge on said language, but they do have a lot of experience as a whole. Unfortunately, many tech recruiters don't know any of this, and just reject many candidates who could definitely fit in that role.
Oct 11, 2023·edited Oct 11, 2023Liked by Sibelius Seraphini
First off - great article, great insight. I'm an old guy too. I miss the days of gurus on the mountain. I guess I've got my own little mound of dirt at work that I sit on when I get questions from the new guys.
To critique, (as everyone does in the comments) I don't see such a stark division of people. To use myself as an example, in my core skills, I am a stacker: I know pretty well how my stuff works and why. Meanwhile around the edges, I am a packer - I only know the pieces that I've used. However, your points are still great - I too see the industry shift away from expertise to operators of tools - wide rather than deep.
Part of is is that we're using more complex tools: an IDE instead of vi / emacs, VMware instead of 40 physical machines, SDN instead of routers and firewalls. Each is a leap forward in productivity and a massive increase in complexity. Too many details to know.
The business environment has changed - the pressure to be increasingly productive. It has left techies with less time to dig into how things work. Fix it and move on. Don't spend too much time figuring out why it broke until it breaks a second or a third time. You don't get to 'play' with new products. You just get enough time allocated to implement them.
Then there's the corporate cost-cutting trends - doing more with fewer people. Hire one 'dev-ops' person instead of two different specialists and pay them 20% more, but lose some of the depth. There's less formal in class training. Move fast, break things, ship it now - let the customer help discover the hard to find bugs ..
Some of these trends are overall good things though. Remember the Henry Ford model of efficiency? Instead of using skilled craftsmen to custom build every part of a car, have the craftsmen build a complex tool that embeds the expertise and can quickly churn out quality parts...
Similarly, system admins take time to craft a cloud image of a machine, then quickly spin up dozens of them. If one goes bad, delete it and spin up a new one rather than digging through dozens of config and log files.
But it does scare me sometimes how much invisible, unknown complexity lives beneath the surface of the tools that we use these days. I fear a large, cascading interdomain collapse or a loss of tribal knowledge about something critical. Let's hope not.
Oct 2, 2023·edited Oct 2, 2023Liked by Sibelius Seraphini
There are too many corporate "senior engineers" who are just there for the paycheck and completely lack training and curiosity. Meta hired fucking history, English, economics, biological sciences, physics, and chemistry majors as IC5-7 *senior* SWEs and PEs without any depth or breadth of programming experience. The way shit worked: the biggest asshole making bullshit arguments without listening to anyone else and greatest volume of code for new features got the "impact" credit. Anyone new was automatically disregarded and anyone there a long time was automatically respected regardless of actual experience, knowledge, or ability.
Software engineering mastery takes experience shipping, making mistakes and correcting them, excellence, curiosity, proactive pattern deduplication, anti-pattern prevention, continuous learning, organization, configuration control, minimal commits, communication of intent prior to tasks and projects, and minimal but comprehensively-exhaustive documentation.
PS: Interview questions to give candidates:
1) How do OSes typically implement virtual memory paging on the Intel CPU?
2) What are the differences between real- and protected-mode?
3) How would a kernel slab allocator be implemented?
Thank you. I like your blog and am happy I found it.
I agree that perhaps programming has lost some of the rigour it once had.
However, I disagree with this packer/mapper model a little. I think it fails to leave space for humility and the unknown. A mapper needs to be a bit of a packer when it comes to solving hard problems - playful, and not too certain. otherwise he'll be stuck in his perfect (but inevitably incomplete) map, and unable to learn.
The "seniority" level changes too much based on the company and what's expected of a developer. E.g. if you work on a software house, seniority might mean "fast prototyping" - build what the customer wants and let's not think about maintenance right now.
When it comes to things you should know, I would consider things like CPU & OSI college-level knowledge; not very applicable but good to have. I'd argue for expanding the "things you should know how they work" to tools you use on the daily. Things like git, or the browser, your compiler/interpreter, your IDE/code editor.
But then again, just knowing these doesn't make one senior. At the end is the value you deliver and not the words and techniques you know
This is happening all across th tech sector. I'm in the sysadmin field and it's happening in my industry too. Senior admins coming in without basic knowledge is very frustrating and I hesitate to teach them because they should already know these things.
I don't really agree with the mapper/packer analogy though it did reming me of the map/reduce (Hadoop) data processing algorithm. 😁
My son is in college learning to code (computer engineering) and he'll "stand in the shoulders of giants" without knowing how the bottom layers work but that's how it'll be done down the road and that's ok. He'll complete his assignments and he'll make websites and services and build stuff by looking it up on stack overflow. It's the same as us in college except we had to begrudgingly look things up in books or figure it out ourselves (which didn't always work well or wasn't very efficient when we had to re-invent stuff). 😁
The world will be fine. The younger generation doesn't need to be experts in everything unless there is an apocalypse and if that happens, we'll have bigger problems to worry about.
I also think that too many people have the "senior" title simply because of scarcity. There is no one to hire, so companies are willing to pay more. In order to avoid creating inconsistencies between salaries, they hire lower level people with the senior title.
There is also the issue of many "Senior" Developer/Software Engineer roles being posted, and they require X years of experience in Y language. This should mean nothing, because maybe the "Y language" is already obsolete or less used in companies, or even worse, the potential candidate doesn't really have knowledge on said language, but they do have a lot of experience as a whole. Unfortunately, many tech recruiters don't know any of this, and just reject many candidates who could definitely fit in that role.
First off - great article, great insight. I'm an old guy too. I miss the days of gurus on the mountain. I guess I've got my own little mound of dirt at work that I sit on when I get questions from the new guys.
To critique, (as everyone does in the comments) I don't see such a stark division of people. To use myself as an example, in my core skills, I am a stacker: I know pretty well how my stuff works and why. Meanwhile around the edges, I am a packer - I only know the pieces that I've used. However, your points are still great - I too see the industry shift away from expertise to operators of tools - wide rather than deep.
Part of is is that we're using more complex tools: an IDE instead of vi / emacs, VMware instead of 40 physical machines, SDN instead of routers and firewalls. Each is a leap forward in productivity and a massive increase in complexity. Too many details to know.
The business environment has changed - the pressure to be increasingly productive. It has left techies with less time to dig into how things work. Fix it and move on. Don't spend too much time figuring out why it broke until it breaks a second or a third time. You don't get to 'play' with new products. You just get enough time allocated to implement them.
Then there's the corporate cost-cutting trends - doing more with fewer people. Hire one 'dev-ops' person instead of two different specialists and pay them 20% more, but lose some of the depth. There's less formal in class training. Move fast, break things, ship it now - let the customer help discover the hard to find bugs ..
Some of these trends are overall good things though. Remember the Henry Ford model of efficiency? Instead of using skilled craftsmen to custom build every part of a car, have the craftsmen build a complex tool that embeds the expertise and can quickly churn out quality parts...
Similarly, system admins take time to craft a cloud image of a machine, then quickly spin up dozens of them. If one goes bad, delete it and spin up a new one rather than digging through dozens of config and log files.
But it does scare me sometimes how much invisible, unknown complexity lives beneath the surface of the tools that we use these days. I fear a large, cascading interdomain collapse or a loss of tribal knowledge about something critical. Let's hope not.
There are too many corporate "senior engineers" who are just there for the paycheck and completely lack training and curiosity. Meta hired fucking history, English, economics, biological sciences, physics, and chemistry majors as IC5-7 *senior* SWEs and PEs without any depth or breadth of programming experience. The way shit worked: the biggest asshole making bullshit arguments without listening to anyone else and greatest volume of code for new features got the "impact" credit. Anyone new was automatically disregarded and anyone there a long time was automatically respected regardless of actual experience, knowledge, or ability.
Software engineering mastery takes experience shipping, making mistakes and correcting them, excellence, curiosity, proactive pattern deduplication, anti-pattern prevention, continuous learning, organization, configuration control, minimal commits, communication of intent prior to tasks and projects, and minimal but comprehensively-exhaustive documentation.
PS: Interview questions to give candidates:
1) How do OSes typically implement virtual memory paging on the Intel CPU?
2) What are the differences between real- and protected-mode?
3) How would a kernel slab allocator be implemented?
4) How does a regex JIT matcher compiler work?
Thank you. I like your blog and am happy I found it.
I agree that perhaps programming has lost some of the rigour it once had.
However, I disagree with this packer/mapper model a little. I think it fails to leave space for humility and the unknown. A mapper needs to be a bit of a packer when it comes to solving hard problems - playful, and not too certain. otherwise he'll be stuck in his perfect (but inevitably incomplete) map, and unable to learn.
Amazing reality check. The invested companies are lowering the rule by paying a lot for "supposed Seniors". I hope the market stabilize soon.
nice text
great post!
The "seniority" level changes too much based on the company and what's expected of a developer. E.g. if you work on a software house, seniority might mean "fast prototyping" - build what the customer wants and let's not think about maintenance right now.
When it comes to things you should know, I would consider things like CPU & OSI college-level knowledge; not very applicable but good to have. I'd argue for expanding the "things you should know how they work" to tools you use on the daily. Things like git, or the browser, your compiler/interpreter, your IDE/code editor.
But then again, just knowing these doesn't make one senior. At the end is the value you deliver and not the words and techniques you know