We don't have senior engineers anymore
sibelius.substack.com
sibelius.substack.com
> Why do we need variables?
> How variables are really stored?
> The type of variables matter?
These aren’t questions that a junior engineer couldn’t answer. These are questions that somebody who has passed a single programming class ought to be able to answer.
Then they have questions about this vite platform, which I’ve never heard of, but it seems like they are asking “does software have dependencies?”
It makes me a little suspicious of the article. It looks they’ve set up a contrast: packers vs mappers, where packers are the bad result to end up aligned with (then, if you want to be a mapper, come join me!). But it seems like an over-shoot. The questions they have the packers failing seem to indicate some wild levels of incompetence.
Sorta like those online IQ tests that always tell you that you are a genius.
A computer program is a sequence of instructions for the computer to follow, to transform some input into some output. To write useful and interesting programs, it is helpful to have some way of representing quantities which might change depending on those inputs.
> Why do we need variables?
Do we even need them? You mean variables that vary? If so there are many languages that don't have them at all. Or you mean just naming values?
> How variables are really stored?
That is incredibly complicated. Variables don't exist on the executable like they do on your source code. They are just an abstraction.
> The type of variables matter?
Well, what "type" even means? There are PHD thesis written on this.
I think a more realistic description is that everyone is a mapper. There isn’t a single body of knowledge that is “software engineering” - so it’s ok to encounter something new, “pack” it, then map it if it’s valuable.
Far better to encourage mapping than create false dichotomies that can easily work their way into cultural fit interviews.
“The candidate failed to find an obscure error in the JS console… clearly a packer - no hire”.
I will say that I heard and probably paraphrased this rant before, when I was dealing with similar cookbook-style code on much simpler systems. People with deeper understanding, who can make sense of a disassembly or Wireshark output, do get called in to figure things out if another layer of copypasta isn't fixing things. But the market has shown that the packer has more fitness to the environment.
I do agree, though, that the term "senior" has become meaningless. This is true in other disciplines like veterinary medicine, where only a naive person would become a medical director.
The article talks about packers and mappers and that either is it isn't a useful distinction. I am open to either, but I wouldn't dismiss the idea because it's "splitting" by nature.
The first group has been bad at writing articles up to now. That just doesn't tell you anything about what their next article will look up.
But then I start to get it and finally do get it. The packers are now "experts" at their acquired knowledge and seem to have a hard time changing opinion where they should.
Back in school I had real problems getting good enough in subjects that required learning pieces of fact that don't quite go together or display some inherent system. My friends didn't. Things that have a system or are "logical" in the wider sense, easy peasy.
EDIT: I would call myself a decently accomplished programmer and engineer at this point after 25 years or so working with it.
It gives me a lot of anxiety to be in that trough before it clicks.
Others seem to be happy taking snippets of stuff and just applying them straight away. But equally, they have not developed a deeper understanding and they will struggle when faced with edge cases. Pros and cons I guess.
In general the bar is low, indeed, and the title tends to be quite aggrandizing.
The title that shows seniority ("been there, done that"), again in my experience, is the next one, which usually is "principal engineer".
It’s a pointless challenge to try and bucket engineers by skill levels like that. Titles are for compensation and rank, and nothing more. A senior at my company would’ve been more like a staff engineer at my last spot. Every company is different and thats okay.
The architect seemed to have a pretty good path mapped out, but it was early on in the project, and I was just an intern so I wasn’t there long enough to see the mess of reality asserting itself.
I just got hired by a company that was looking for a data product leader.
I only have 3 years of experience in data analysis, but the owner of the company thinks I am extremely capable of leading the company's data front.
Since I'm not attached to titles, concepts, and job definitions, I obviously accepted the offer because my salary doubled.
And speaking of titles, it looks like the author spent a total of one year in the workforce before going on to become a cofounder/CTO and currently claims that title at four organizations simultaneously (with under ten years of experience, not that this is an indicator of much). Wonder how he feels about the CTO bar.
I’m not very good at memorizing facts so I tend to “map” more than “pack”. I’ve worked with people who are far better packers than I am and they go from zero to shipping much faster than I do. Both skills are advantageous in the right situation.
I think this sentiment, “engineers aren’t what they used to be… they don’t understand the why as much”, is a very common sentiment today. I think there’s some truth. I know plenty of “cloud engineers” that can tell you the best practices of architecting on AWS but not the why those are best practices, not why distributed systems are hard, etc.
The reality though is that this is often fine. Most problems aren’t novel. Most people shouldn’t need to re-derive knowledge from first principles as part of the job. You learn that in school, and then you go to work and solve the problem asked of you. Not every problem is Google scale we know this, but also not every problem requires a phd and ends in patents. Sometimes it’s just a low traffic crud app with a react front end.
The CTO probably wants to be a thought leader or something. I don’t know peoples motivations. It seems like they read an article on pack/map and applied it to why their employees suck?
For me, that was a giveaway author had read a bunch of stuff but doesn't understand it (so, a "packer" in their own terms). I'd suspect that the article's author is either ignorant or tries to provoke readers.
Software engineers don't have to know about p-n junctions and what the heck an electron hole is - that's an entirely different field of science. In modern age, most people stick and try to become knowledgeable in at most one. Unless they design software for microelectronics design or physical simulations, of course.
And the Protocol Wars are long over, OSI model is dead, even though some folks still believe it's somehow applicable to modern networking. While I'm pretty sure there's a heavily smoke-stained machine still using X.25 somewhere out there, maintaining it and its software is literal necromancy (and while it is a proper subfield, it's a very niche one to require it for seniority).
I'm only here because for some insane fucked up reason, the money is at least 4x better than electrical engineering was and I really like lots of money and will quite happily sell my soul to the machine above for it.
But what I take even more issue with is the conflation of "engineer" to be not just a software developer, but a web developer. E.g., this says you should understand how CSS and DOM work under the hood. But there are lots software domains where this knowledge is completely useless.
How the computer works, from electrons to transistors, to CPU, assembly, and high-level programming languages.
How the internet/network works, how you send some information from one computer to another, all OSI 7 Layers.
Engineers who fixate on this kind of detail are useless to most businesses most of the time.
If you structure everything on reducing, and value people only on their ability to reduce, everything to first principles of how electricity works then you're wasting everyone's time.
I want senior engineers to:
Be up to date but pragmatic about patterns and solutions Be able to, within minutes of being asked, map that knowledge to new business needs, explain that thinking across non-technical stakeholders through to junior devs Be able to lead and execute a plan with a level of pragmatism that reflects the fact that businesses aren't playgrounds for indulging in their own fixations
If they're more worried about NAND gates then not only are they failing in their duties, the industry has failed in providing meaningful abstractions so that smart people aren't bogged down in cruft.
It's hard to show the thinking process to others, so the person who says an answer faster is assumed to be better/more senior.
That is the premise isn't it? Most abstractions have significant failings, and when those failings matter you need to understand what's going on a layer or two down.
Maybe that doesn't line up with the label "senior engineer" at your org, but if you don't have somebody who knows what's going on you're going to have problems. If you're lucky, they're just performance and cost issues and your business has high enough margins to not care. In my experience though, orgs are rarely that lucky. It's embarassingly easy to pick up a 100x performance win in expensive enough applications that it was worth the engineering time, and much of the time you'll knock out a swathe of correctness bugs in the process.
A brief recent example: The way some dev was calling into a given black box implied the black box had to manage arbitrary contention with low max latency and zero bugs. Most devs are bad at handling contention without bugs, most devs are bad at bounding latency, and most devs are bad at handling performance of any kind under contended loads. That's not an expectation you want to put on your black box (it _might_ be up to the task, but why chance it?), and thinking just one layer down strongly suggests you should write your application literally any other way. In practice, the other way had 10x less code, was dead simple to prove correct at the application level, and it solved the performance and correctness bugs we were previously surfacing from the black box.
Do you specifically need to know electrons, transistors, OSI 7, and all that? Eh, maybe. You'll probably need to know some particular subset that looks too low-level now though, and it can be hard to predict which subset that'll be.
This is particularly apparent in large cities, where salaries can be almost double at each end of the spectrum. From what I have seen promotion to senior or hiring inexperienced staff at senior level is the only way these companies can retain or recruit staff.
I sort of feel bad for them because without a large step down in title they’d never get another job. Perhaps that’s the trick - title inflation to mask bad pay?
How does inflating titles help to attract talent?
Do you mean this: let's say they want to hire a senior software engineer, but the salary for this level would not attract any candidates so instead they try to hire a staff engineer?
Mostly trying to understand if this is middle-managers tricking their higher ups or if it's the company trying to trick the candidates.
If the salary range for "senior" is 50-70k, this might be attractive for a customer service rep but not for a senior software developer. Thus, you'll need to inflate the title to be either a manager, director, or staff/prinicple (if HR recognizes that) to be authorized to offer market compensation for a senior software developer.
So you've gone from a group of people that got into programming because it peaked their interest and their hobby became their occupation to a group of people who look at programming as a way to make a lot of money. I'm not saying these people aren't talented and don't enjoy what they do I just think they are coming from a different angle than us grey beards. I also think the real problem is figuring something out on your own is no longer a thing, if there's a problem you go straight to google for the answer and while efficient it screws with the learning process and it reduces new and novel ideas.
This had zero impact on software developers careers or salary, except if you wish to work for the government.
A book would probably require enough self motivation that you might get a decent candidate.
These boot camps are churning out mediocre JS devs like they’re going out of style. Personally I won’t even look at the resume of a single one anymore. I’ve told our recruiter to not send me ANY resumes from boot campers.
It is a game, where workers strife to be granted higher and higher titles, just because their peers and the industry does.
There is no inherit requirements, I can start a company today and call everyone super duper staff engineer
It's hard not to agree with the general premise of the article - anyone can see the trend. But as always, there's some nuance that I think the article leaves out.
Thinking of it as "two different types of programmers" is reductive and encourages you to have a fixed mindset about people (i.e. I "am" a packer vs I "am" a mapper). Really, these are two sets of behaviors and approaches towards software engineering, and almost everyone has bits of both behaviors.
I began my tech career in web development in 2009, before all the frameworks and bootcamps and influencers. In those days there was still a massive focus on performance, and since bundlers weren't really a thing yet, a lot of the stuff was made in-house. I obsessed over fine-tuning the critical rendering paths of my websites, even hand-modifying SVGs so I could strip out unnecessary vector points. I went a little overboard at times.
I didn't use a JS framework (other than jQuery) until 2016, and since then, I have to admit that my mapper brain has atrophied into a packer brain. In my opinion, my industry has undergone two significant changes:
1. We've been under increasing pressure to ship as fast as possible, which encourages a packer mentality.
2. We've seen an explosion of VC-backed technologies that are impossible to keep up with.
Both of these things together make it very difficult to resist packer-behavior. For instance, when I first read about NextJS and the idea of "hydration", I felt this overwhelming sense of weariness. I could immediately imagine what they were doing at a high level, because I understand the fundamentals of web technology. But still, I also knew that in order to use NextJS effectively, I'd have to spend hours digging through their documentation to learn the nuances of their approach. At my age, I simply don't have the time or energy, especially if they're going to ditch that approach in their next version.
Lets take the example provided by the author about `Solving a Problem`,
It is always possible, that the engineer fixing the bug might not have a lot of time to spend on it, or the fix does not need to cover all edge cases and a quick fix is good enough based on their own mental map. But to an outsider, it might seems as if the engineer has not taken ample time to `understand the root cause of the error, and which assumptions are wrong in their mental model`, which is a valid thought, but not necessarily true.
I've been blessed to mainly work in companies that had very high engineering bars (finance, faang) but I spent two years at a scale up and the difference in engineers was crazy. Senior engineers who, when faced with an outage just threw up their hands and said "we dunno".
And this was still a place that was large enough and tried to have a bar. I can only imagine the next tiers down (eg, where do people who can't cut it at these places go?)
I don't know how much of this is 'innate' caliber vs benefit of working along others who has high expectations and taught you (vs not)
Top tier companies pick up the faang rejects. Middle tier get the top tier rejects. Bottom tier get the rejects from the middle tier.
“We get what’s left. Sometimes we get lucky and get someone who’s fallen through the cracks”
Personally I’m not a massive fan of the faang recruitment techniques and I think there’s a lot of fantastic senior engineers who want to do interesting work without jumping through ridiculous hoops. The main issue is usually just being able to pay sufficiently well to attract them in the first place. It’s a tough argument with the exec team to get a salary through that can sometimes be double or triple the companies median.
There's no obvious correlation between high pay and value delivered.
Titling nonsense aside, what passes as "senior" today would be a no-hire decision for a junior developer slot in 2005. Things have slid pretty far in my view. There aren't many "developers" out there who are willing to push as hard as you had to 2 decades ago. ChatGPT basically shoves the tutorial & job offer down your throat these days. In the 90s you had to drive to the fucking library to learn about what a computer is - If you were lucky, they'd have a box of AOL trial CDs on the checkout counter.
If you want to get as good as some of the greybeard crowd, you are going to have to invent your own hell and then practice inside of it. No one will do this for you. I feel like those of us constrained by dial-up (or worse) were actually really fortunate in some ways. This wall was a fantastic filter. It really made you think "is this interesting enough to suffer through, or should I just observe it in the news?" Imagine spending a month debugging a problem without the aid of google, stack overflow, et. al. Most "developers" today would laugh and walk away from the industry if they experienced this.
For me, front-end / back-end job duty separation is the #1 canary pointing towards a weakening of general expectations for "software people". Not saying that the developers need to know how to use photoshop to design & iterate sophisticated UI designs with the client's marketing team, but when I first started out I was expected to take a final PSD and convert it to a reasonable HTML/CSS layout - in addition to all other backend/database/hosting/infra work.
One might make accusations that someone who manages all of these things is mediocre at all of them, but I would counter that shipped products are infinitely more valuable than things that never ship. I have observed that in companies where you have to assemble the entire justice league & merge 10+ PRs to update a dropdown list's contents, things usually aren't shipping very rapidly.
Professional Engineers and Architects in non-software fields require licensing. One can't legally give yourself those titles in other fields. You have to prove you have the map nailed down in your mind. And not just your map, but enough of all related design disciplines to reason about them effectively. This is done via extensive testing. In addition, the applicant must have several years of experience - documented and signed off by a senior licensed professional - before test results hold any weight. Once you obtain a license, you must continue to submit proof of continuing education to maintain it.
The skilled trades also to rely on testing and supervised experience. Training intensity and requirements at this level do vary a bit across the US, but anyone would still have had to work their a* of f to get there
In both the skilled trades and professional design, the correlation between licensing/trade rank and minimum expected capability of any given employee are strong enough that they can be used in spreadsheets to accurately estimate delivery schedules. Those who exceed minimums can expect to be given additional responsibility and compensation. If that expectation isn't met, the professional certification holds its value and may be reliably taken elsewhere for better compensation.
What isn't solved, however, is why designers in other disciplines aren't compensated at the same rate as unlicensed software professional
> How the computer works, from electrons to transistors, to CPU, assembly, and high-level programming languages.
> How the internet/network works, how you send some information from one computer to another, all OSI 7 Layers.
> How browsers work, how DOM works, how CSS renders, how JavaScript is loaded
The fact that this article is so popular on HN is absolutely mind blowing.
I know a ton about "electrons to transistors, to CPU, assembly" but only because I wasted many years of a life in the hardware industry and a EE degree, before finally switching over to SW. I probably know more about these topics than the author does. These domain-specific trivia have provided me approximately zero value in my career as a SW developer.
I also know nothing about about any of the other stuff mentioned above. And yet, I've had a very successful career as both a principal developer and startup founder who built a complex SW product from the ground up.
Job titles are nothing more than a noisy proxy for how much value your employer thinks you are contributing to the business. Contribute enough value, and you will earn and deserve a "senior developer" title. And unlike what the zealots and fundamentalists may believe, there is no "one true way" to deliver value. It is entirely dependent on the business, team, and circumstances you are in.
If you're not sure, ask your manager or more senior developers. If they tell you that you can provide more value to the business by knowing things like network-transport protocols, do exactly that. If not, don't waste your time studying a bunch of stuff that some online blogger insists is "the one true way."
I hired a bookkeeper/comptroller/finance person for a very small startup and she was 100% a Packer. She had years of experience and interviewed very well but once she started I realized she knew all the motions of bookkeeping but she didn't actually grok what double-entry accounting was or what a balance sheet and how assets and liabilities and equity relate to each other.
So anytime we ran into a novel situation that could have been easily puzzled out by someone with a foundational understanding of accounting, she got paralyzed, made something up, and then blamed others for "not training her for this situation". Total nightmare.
In my experience, people don't learn much from reading books without being able to discuss the content of those books with other people. Indeed if you are discussing your work with your colleagues (and vice versa) — and specifically if you are asking probing questions, challenging assumptions, and asking for clarification as your own mental models fail you — you may not even need to read these books. You will be inculcating a culture that helps counteract all of the behaviors and habits being lamented in this article, and you very well may be teaching (or learning) the concepts within the books.
Regardless, if you want to learn how a computer works from first principles, starting from transistors; and also if you want to learn the OSI model, Ben Eater has amazing tutorials on both
How to build a computer: https://m.youtube.com/playlist?list=PLowKtXNTBypGqImE405J256...
How computer networking works: https://m.youtube.com/playlist?list=PLowKtXNTBypH19whXTVoG3o...
Starting in 2015:
* Intern - 7 months
* Full stack dev - 13 months
* CTO - 7 years
* CTO - 2 years
* Co-founder - 2 years
The irony of a "CTO" with not even 2 years as a developer complaining about the bar for senior developers is incredible.
You know what bar needs raising? The bar for publishing opinions. Why does a software developer feel qualified to publish their thoughts on something which is far more in the domain of psychology and social science? We barely trust those guys to get it right. Staggering amount of hubris to think that after 2 years of cutting code and starting their own side hustle, they can make blanket statements like this article does.
How you learn doesn't matter -- the results you deliver do. This should be obvious in an engineering discipline. Physicists know better than to turn their noses at mechanical engineers for not studiously considering general relativity in their day to day work. Maybe the more computer science-oriented people in software should follow that example.
Write a skills matrix for an engineering team.
That gives you an insight about what the candidate thinks seniority is, and how they are spending their efforts to move their career forward.
Or am I confusing your post for an eng manager interview and not an IC?
You should at least know what the journey is, even if you haven't made it to the end.
IMO, this is also why we have "computer science"... as if computers were found in nature and we were trying to 'reverse engineer' how they are made; which is ridiculous!
engineering, technology, computers, are not well covered by neither philosophy of arts nor sciences; if anything math's philosophy gets closer; but it's just a branch of phil. of science.
Computer Science is a branch of pure math, and arguably pure math is found in nature and we're just reverse engineering its laws.
e.g., modus ponens is real, but a Turing Machine is not. We can reason about it logically but we didn't discover it, we made it up. Maybe the same can be said about numbers.
If that's not a proof of its "realness", then I don't know what possibly could be.
In Northern and Central European countries, it is call datalogic or informatics. Your analogy holds only when you tell it in English.
also, what does informatics have to do with philosophy, andor phil. of engineering?
"computer science" does not contain the words "computer" in many languages
Actually senior engineers are out there, for sure. They are, of course, more unusual as candidates and way more expensive.
The whole mapper vs packer thing… meh.
If you wanna check all my content, check https://sibelius.github.io/zettelkasten/
Thanks for the feedback
I had in my own mind it was 10+ years.
The bar seems to have been lowered.
I've seen CFO-as-a-service but haven't seen that yet for CTO.