[romanhn]

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.

[vineyardmike]

The article is pretty bad, I agree. Everything you said, I agree.

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?

[drdaeman]

> And you can absolutely be a wonderful senior without knowing the details of the CPU architecture or definitions of OSI layers or whatever.

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

[jnovek]

I think “packing” and “mapping” describe real things that people do and I think it’s possible to lean in one direction or the other but the conclusion — that one is better than the other — doesn’t really follow for me.

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.