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 wonder if your tone and advice still make sense in these similar scenarios:
1. You have a large number of peers who start chat conversations with “Hi, are you busy?” That question is begged with just “hi” and implies a forced urgency.
2. All your coworkers start email threads with “hi” and wait for peers to respond before continuing. If that seems ridiculous, you now have an idea what “hi” is like for remote workers.
> If that seems ridiculous, you now have an idea what “hi” is like for remote workers.
I've been remote for 10+ years. I've never once had a problem telling someone "hi", even on large teams. I do find that the people concerned about these type of "micro productivity" issues tend to make for un-harmonious team members and ultimately drag down the productivity of the team, often to the point of chasing out good employees with their toxic attitudes.
I've never had anyone ask me such a strange question. I think most humans know that when someone says "hi" you say "hi" back, I don't see how that could be confusing to new team members.
If I've already emailed someone and they haven't responded in 48 hours, can I send a message that just says "Hi" or is "Hi, respond to your email" more appropriate?
It’s as simple as “Hey gAI, I sent an email about xyz the other day, have you had a chance to look at it?” No need to say nothing but hi or be indirect.
If someone's not responding to their emails, they've already failed to meet me halfway in communication. It's not my responsibility to go even further before they make a first attempt.
What a weird take. Unless you have immaculate email filtering or receive very few emails, it’s not hard for emails to slip through the cracks. You can complain about someone “not meeting half way” in a phone call or IM with read receipts, but email is one way communication until you actually get a response.
> they've already failed to meet me halfway in communication
This hypothetical doesn’t seem to make sense (maybe I’m missing something). If the person is communicating ineffectively in email, what does it solve to send them a Slack (or whatever) message that simply reads, “hi”?
I had my “first Joel review” while applying to work at Stack.
Joel still did the final interviews for all applicants back then.
After 4-5 back to back on site interviews, I was spent. Somehow we ended up talking about old AutoIT scripts I’d written - many of which include apologies to future readers in the comments.
Joel was a great interviewer… that conversation turned into a game as Joel picked apart various ways he over compromise the script and asked how I’d respond in the next iteration.
So the overhead to begin a video stream is due to the size of video data? Would video behave generally more like audio data (could stream immidiately) if the typical user bandwidth was larger?
In reality it's the size yes, but there is an inherent delay because of the way B-frames work. You'll need to buffer 2-3 frames worth 33ms each (for NTSC), so 66-99ms delay regardless of throughput.
Audio doesn't have such a concept, you get 33ms worth of audio, you can play it right away.
Of course, you can opt to not have b-frames and negate that issue.
That last line gave me a chuckle… the most positive feedback Bartik could provide, which somehow hurt more for the writing.