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 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”.
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.
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 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.
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.
"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.'"
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)
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.
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.
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.
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....
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.
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.
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.
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).
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.
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.
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.
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.
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 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.
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.
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 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.
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.
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.
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.
"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.
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.
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.
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)
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.
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.
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
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".
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?
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
We also don't have technical managers controlling engineering. Beware the directors of engineering who bullshitted their way in and code like junior developers.
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.
> 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.