by gosenx on 10/1/23, 3:03 PM with 122 comments
by bee_rider on 10/1/23, 4:11 PM
> 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.
by Selfcommit on 10/1/23, 4:02 PM
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”.
by boo-ga-ga on 10/1/23, 3:59 PM
by mytailorisrich on 10/1/23, 3:16 PM
In general the bar is low, indeed, and the title tends to be quite aggrandizing.
The title that shows seniority ("been there, done that"), again in my experience, is the next one, which usually is "principal engineer".
by boredemployee on 10/1/23, 3:53 PM
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.
by romanhn on 10/1/23, 4:18 PM
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.
by baz00 on 10/1/23, 4:09 PM
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.
by weego on 10/1/23, 4:20 PM
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.
by ZeWaren on 10/1/23, 3:52 PM
by twelfthnight on 10/1/23, 3:57 PM
by tekla on 10/1/23, 3:55 PM
by arielweisberg on 10/1/23, 3:47 PM
by proc0 on 10/1/23, 4:14 PM
by danielvaughn on 10/1/23, 4:16 PM
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.
by throwaway4233 on 10/1/23, 4:21 PM
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.
by xyzelement on 10/1/23, 4:04 PM
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)
by bob1029 on 10/1/23, 4:43 PM
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.
by PTOB on 10/1/23, 4:50 PM
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
by whack on 10/1/23, 5:13 PM
> 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."
by teucris on 10/1/23, 4:09 PM
by nlh on 10/1/23, 4:13 PM
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.
by amazingman on 10/2/23, 4:06 AM
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.
by mathgenius on 10/1/23, 3:58 PM
by idrios on 10/1/23, 5:33 PM
Regardless, if you want to learn how a computer works from first principles, starting from transistors; and also if you want to learn the OSI model, Ben Eater has amazing tutorials on both
How to build a computer: https://m.youtube.com/playlist?list=PLowKtXNTBypGqImE405J256...
How computer networking works: https://m.youtube.com/playlist?list=PLowKtXNTBypH19whXTVoG3o...
by 000ooo000 on 10/2/23, 1:07 AM
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.
by EPWN3D on 10/1/23, 4:20 PM
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.
by sys_64738 on 10/1/23, 4:56 PM
by 29athrowaway on 10/1/23, 4:02 PM
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.
by garba_dlm on 10/1/23, 3:52 PM
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.
by whoopsie on 10/1/23, 4:04 PM
by znpy on 10/1/23, 10:47 PM
Actually senior engineers are out there, for sure. They are, of course, more unusual as candidates and way more expensive.
The whole mapper vs packer thing… meh.
by sseraphini on 10/2/23, 12:43 PM
If you wanna check all my content, check https://sibelius.github.io/zettelkasten/
Thanks for the feedback
by tmaly on 10/2/23, 1:54 AM
I had in my own mind it was 10+ years.
The bar seems to have been lowered.
by expertentipp on 10/1/23, 4:07 PM
by say_it_as_it_is on 10/1/23, 3:55 PM
by Raed667 on 10/1/23, 3:52 PM