It’s a bit of a shame that senior titles are being tossed out like candy now, while I had to work my ass off to get there. It took me 16 years, which feels about right to me. I switched my career from systems engineering to network engineering in 2010 so I might have gotten there sooner. (IT jobs for college grads in 2004 were few and far in between in my area and I had to take what I could get.)
I had the same title for 20 year Technical Consultant 3 and then I made the massive jump to TC4, every idiot that can log into Azure is now a Senior Sysadmin and if they can fumble their way through a Linux install they are the IT director (with 2 years of experience total). Titles in our industry aren't worth anything, I equate it to the startup with three employees and their titles are CEO, COO and COT....
But now you’re just moving the goalposts and inevitably someone else will make the same declaration about principal engineers and will instead insist that only Chief Architects (or whatever next step up the corporate ladder of madness is) are the really truly experienced class of engineers.
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.
When I worked on a project that had a dedicated architect, they really seemed like they were the only one doing engineering work (design). The rest of us were assembling their design, like technicians do.
If drawing over-simplified block diagrams of software components is "engineering", we'd be better off just letting the technicians follow their intution. My experience with principals engaging in this sort of naval gazing is they just fuck everything up. The project was in much better shape before they came along with their fancy engineering ideas.
IDK, I’m a grad student, so most of my programming does not really need engineering, in the same way that carpenters and machinists don’t generally need mechanical engineers to go over their side projects, sheds, and home-made shop tools.
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.
people aren't going to be happy if they don't get a promotion or continuous raises though after 5 years though. what else are you going to call them? have 4 different types of mid level because they can't be 'senior' until they reached 15 yoe? Really after 5 years in the same company, more so in software, you probably are actually one of the more experienced people in the company. idk what you are doing if you dont have senior level domain expertise.
They're not meaningless. Someone can get a line management role and be terrible technically. In fact that's a good thing to do with someone who's not good technically.
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.
Perhaps the fundamental logic behind pure math is "real" in the sense that it's "found in nature" (whatever that means, I don't see how we would prove that), and we're only applying this real thing to models that we've completely made up.
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.
> 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!
"computer science" does not contain the words "computer" in many languages
Tell that to my previous employer. There, software engineers turned "senior" after 2 years. Then principal after 3 more. It was a scheduled activity to "upgrade". Only X people could turn senior every year because the title changed triggered a salary raise and they could only afford that for X people. I left when I got approval to hire 3 senior software engineers to my team but the salary level was only attractive to the people with zero experience, if that.
I think this is common in companies with a lower salary range, no stock options, bonuses etc.
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 keep seeing this (anecdotally) out if the Midwest. Folks with 4 years experience doing mostly front end work who’ve never deployed anything with the title “staff engineer”.
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?
That's exactly what it is. Many organizations have strict pay bands and cannot attract talent without overly inflated titles; cue dozens of "directors" with no reports, and people with < 5 years experience being hired as "Staff Engineers" to build web apps.
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.
It's the former. Larger companies tend to have strict pay bands relative to the seniority and responsibility of a position. Let's say intern>junior>senior>manager>director>vp.
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.
A one-person housecleaning startup has a CEO if they incorporate. But it says something about a company if their chief is just out of school, and it usually says the company is new and small. It might be the next Facebook, or it could more likely be just another new company with young founders.
I've seen CFO-as-a-service but haven't seen that yet for CTO.
That's basically it. With the 2018-2022 boom of hirings, many companies just offered senior position for anyone that showed minimal experience, or promoted their juniors in an attempt to reduce turnover. Then we get here.
"Engineer" is a similarly protected title where I live as well. In my experience, software engineers and software developers without the engineer title seem to do exactly the same kind of work.
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.
We also don't have technical managers controlling engineering. Beware the directors of engineering who bullshitted their way in and code like junior developers.
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.
I think you are on to something. When I started coding in 1980 you really had to figure things out and what you coded was your code, you wrote every bit of it. Why, because we didn't have Stackoverflow, Github or Google to help us out t best we had a friend who also liked to code and they might help you but it was still all you. Now coding seems a lot more like cutting and pasting of someone else's code and making it work for you, so much of the heavy lifting has been done by someone els, the equivalent of knowing how to drive vs knowing how to build the car that you are driving. As you said now being a programmer is where the money is, I can assure you that making big dollars was on nobodies mind in the '80's. If anything being a programmer back then was anti-social, something that people would make fun of you over not something that was praised now every unemployed idiot is encouraged to "learn to program". You did it because it was something that interested you, you enjoyed it and to be quiet frank unless you wanted to be a Cobal or PL1 programmer there weren't a lot of jobs out there certainly not for the PC.
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.
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.
This is the flaw in having an entirely hateful view of splitting, that view is itself an example of splitting. You have to instead believe that there is a time where it is appropriate and useful to split (e.g, war) and times where it isn’t (general thinking)
There's so just room for some sort of splitting to represent truth.
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.
I get that splitting can be useful and logical in many particular situations. But when we talk about very general case like being a good engineer, it is definitely not a good way to reason.
So you're saying that the splitters are split into two groups? One group which knows when it's a good time to split, and the other group which doesn't?,
This feels like a false equivalence. Splitting articles try to make broad generalizations about human behavior, but, as any social scientist knows, human behavior is extremely complicated and multidimensional. A critique of these articles is about falsity, which is binary.
"Someone wise once wrote 'Our world's divided into two types of folk. Now, theres the type of people who divide the world into different types of people, and then there's the type who don't.'"
Presumably authors of articles holding such a view/opinion as to split people into two groups do not hold such a view/opinion as an inherent characteristic of their being.
I can definitely say that I am a mapper and not a packer. But I can also say that I am pretty much _all_ mapper and no packer. This means that it takes me forever to understand a lot of things that presumed packers (or more balanced individuals) would get in a jiffy. This is not intended as a humble brag! For the longest time on some projects I just don't f**ing get it, I start to feel dumb and in way: out of place. The imposter syndrome makes itself heard. It's genuinely uncomfortable.
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.
Very much so. I've gotten better at simply dealing with the fact that I don't undertand wtf I'm doing, and to just accept that at the outset. Now, this is in no way unique and I'm no snowflake. But there's a definite cost.
I'm similar. It takes me longer to get comfortable than others because it has to join up for me. It has been observed by many that I seem slow to get started on things.
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.
For me, it's very much about finding the right level of abstraction. And sometimes things take a lot longer to understand because pieces of the code focus on the wrong abstractions to see how it all fits together. You see that a lot in large orgs with teams with their own coding styles/conventions, focused on their own assigned goals.
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”.
yes the article creates a tik tok level dichotomy between two things that everyone with any amount of experience is obviously both to a pretty advanced degree
I think it's hard to develop a deep understanding of what's behind all the interfaces that are used now in software development. When I was starting out, if you wanted operational complexity you went the mainframe route, and most of us would instead have been working on a deep understanding of Turbo Pascal/DOS or Mac Toolbox or something of that nature. Things change and now we can call forth powerful distributed networks in seconds, run them for minutes to years, and tear them down instantly. Instead of running a main application and a few things on the side, the majority of the runtime of common systems is pre-fab with a veneer of glue that is supplied by the programmer. It's great, but it forces a different skill set. People with my personality could spend 6 months reading, tinkering with, and understanding Docker before becoming as minimally productive as a person who would be described as a "Packer" in this essay would in a couple days. While they might plateau and be unable to fix a problem, the "Just Mapper" might not be gainfully employed in that niche anymore.
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.
Is this an interview question for the candidate, or a question for the employer? Why should the candidate be writing a skills matrix for an engineering team if that's sounding an awful lot like a management task?
Or am I confusing your post for an eng manager interview and not an IC?
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)
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.
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.
It's just a label at this point, and it really means technical product owner. I'd be ok with an engineering license, because maybe then it would be clear what kind of tasks engineers should be engaging in.
Yeah software engineering has even less rigor than the social sciences. The field is filled with cargo culted best practices which are supported by zero hard evidence. Software "engineering" is really closer to primitive superstition than science.
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.
If you can make a plan to solve a technical problem and execute on it in a successful way you're an engineer. There may be differing levels of expertise and "rigor" but we should be more generous with the title if anything. There are a lot of extremely talented "non-technical" people out there building wild solutions with excel/zapier/etc... that deliver value and contain a ton of technical complexity but are very hacky and brittle, but at the end of the day it's still engineering.
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.
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.
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.
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.
Thank you for saying this, I've had a similar experience to yours and the constant churn of JS technologies and employers' expectations around what it means to be "qualified" has really messed with me the past couple years.
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 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.
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?
> 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).
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 very easy to spot those who are intuitively correct based on past experience, even if they can't necessarily explain. Those people are clearly very senior, and are the folks you want around providing feedback on technical decisions.
If we are going to learn everything from the ground up, then I'm going to nitpick and say computers these days run the IETF network stack, not the OSI one. There are not, in fact, exactly 7 layers.
> 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.
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.
126 comments
[ 2.0 ms ] story [ 236 ms ] threadIn 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.
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
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
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.
I've seen CFO-as-a-service but haven't seen that yet for CTO.
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.
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.
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.
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.
https://youtube.com/watch?v=ntIkCITF188&t=1m6s
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.
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.
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.
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.
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.
> 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 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.
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.
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).
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.