I don’t really get the first example.

> 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.

I respect some of what’s being said about “mappers” vs “packers” - but the article presents the idea that there are 2 kinds of programmer and you’re one or the other, largely based on growth as a “real” mapper.

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”.

Any article that splits people into two groups and says one group cannot inherently be good at something immediately puts me off, sorry.

In all the companies I work for in the last 20 years "senior engineer" effectively meant someone with about 5 years of experience.

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".

But whose fault is it?

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.

I hate these kinds of articles, which come off as "I read about a bunch of these things and if you don't know all the same stuff, how dare you call yourself senior". I typically see this in mid-level engineers who haven't gotten humbled by experience yet. The premise is bogus - most people are a mix of mappers and packers, rather than landing squarely on one end. And you can absolutely be a wonderful senior without knowing the details of the CPU architecture or definitions of OSI layers or whatever. This is literally contradicting itself - you must not memorize but understand the why, but also here's a list of whys you should have memorized. Ugh. How about we accept that titles are meaningless, that companies have different standards and incentives, and that as long as higher titles mean more money and clout, individuals will generally optimize for that.

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 sure I'll get downvoted for this one, but can we stop using the word engineer in the commercial software and startup sector entirely. It's mostly hacking, fucked up things that make you cry, turds smeared all over stuff, religious factions fighting over faith (marketing) arguments and embarrassing catwalk fashion show bullshit. None of that is engineering.

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.

Maybe I'll burn some Internet points here but

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.

You can be a junior developer with 15 years of experience, but it's quite hard to hear.

If there ever used to be "Senior Engineers", I wonder if it was because before there were so many fewer engineers and those who were engineers were the folks who were most interested in computers. Nowadays the field is lucrative and people do it for money, so the average dev is lower quality. Kind of like an eternal September situation.

This is what happens when anyone with a JS book and 6 months of time can call themselves an engineer.

Wait till they end up as staff or principal. Along with bad management they hollow out several hundred person orgs.

In my experience the software industry does not optimize engineering roles based on technical metrics. Getting promoted rarely involves demonstrating how you have grown technically. Instead it's about how well you communicate to the team and leadership, how well you organize the team around a problem, how well you put together a planned schedule. Getting estimates right and coming up with simple, effective solutions (for example), is rarely looked at for promotion. In other words, as engineers get promoted they do less engineering... and amazingly this has been literally admitted to me as if there's nothing wrong with it. It's no surprise that codebases get constantly re-written, simple features take exceedingly long to ship, and there is always a long list of bugs to fix, that often have recurring root causes that are never fixed. I think there's a need for engineers to optimize and maximize their specialty within an organization (because a lot of it is domain specific), and it would prevent a lot of the problems that plague software development, specially at enterprise levels.

[front-loading this caveat: I'm speaking from the POV of a web developer]

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.

The article misses out on the fact that, as human beings with varying tenure, exposure and interests, all mental maps are not similar. Which makes on often misjudge another engineer' skills or abilities as purely being "packers".

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 think it's pretty hard to get a sense of what is out there unless you work across a wide variety of companies.

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)

Titles have always been meaningless to me. I have seen CTOs that are amazing humans and fully capable of performing code review over their company's codebases. I have also seen CTOs who are late to meeting/no-shows, less competent than junior developers, etc.

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.

Fortunately, this is a solved problem.

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

> List of things that you should know about how it works

> 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."

In my twenty years in the field, I’ve never met a packer. Every engineer I’ve worked with, from college hires onward, is constantly building a map of the world in their head and I see it in their code. The problem is either that they don’t realize what lands exist beyond their map, or they recognize that there have to be edges of their map to be able to be an expert in something.

I hadn't heard the Packer vs. Mapper analogy before and it's good. It reminds me of an experience I had in a different domain many years ago that I haven't been able to express in such succinct terms.

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.

There's a lot I agree with here, but it's missing an important requirement when it comes to "fixing it": discussing your work with your colleagues.

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.

I don't think it's possible for a packer to become a mapper. We're talking about a strategy (being a packer) with some deep seated emotional roots. They have probably been at it since age 3. Rather than trying to turn them into a mapper, better to find what they are actually good at.

I agree with everyone saying that these expectations are pretty ridiculous to expect from every senior dev.

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...

This article is true garbage. I invite you to look the author up:

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.

The article describes two different learning styles and pronounces one as better than the other. Some people learn by trial and error (the "packers" I guess), and some people learn by stroking their neckbeards and thinking a lot (the "mappers").

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.

Senior programmers used to require 7-9 years of development. Now we have those folk called principal level. Senior is mostly used to say "not in the first year or two out of college".

A good interview question is:

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.

turns out there's no philosophy of engineering!

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.

Ah, the older you get the more you lament the youngin’s aren’t what they used to be in the good ol’ days.

This article’s title should really actually be: “my company is too cheap to hire actually senior engineers”.

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.

Author of this article here

If you wanna check all my content, check https://sibelius.github.io/zettelkasten/

Thanks for the feedback

I am told by internal recruiting that a senior developer is 5+ years of experience.

I had in my own mind it was 10+ years.

The bar seems to have been lowered.

We don't have senior salaries anymore. For the budget you have you get what you're complaining about.

We also don't have technical managers controlling engineering. Beware the directors of engineering who bullshitted their way in and code like junior developers.

Reminds me of a friend -who upon graduation- went from intern directly to "CTO" of a web agency. He was their 2nd developer and only engineer.