While you have a good point, I think the experts also branched off with some unreasonable requirements. I remember reading Yegge's blog post, years ago, saying that an engineer needed to know bitwise operators, otherwise they were not good enough.
I don't know. Curiosity, passion, focus, creative problem solving seem to me much more important criteria for an engineer to have, rather than bitwise operations. An engineer that has these will learn everything needed to get the job done.
So it seems like we all got off the main road, and started looking for shibboleths.
I have a hard time imagining someone who has "curiosity, passion, focus, creative problem solving" regarding programming and yet hasn't stumbled upon bitwise operators (and then immediately found them interesting). They're pretty fundamental to the craft.
I can see having to refresh on various bit shifting techniques for fast multiplication etc (though any serous program should at least be aware of this), but XOR is fundamental to even knowing the basics of cryptography. Bitwise AND, NOT, and OR are certainly something every serious programmer should have a very solid understanding of no?
There is a world of difference between stumbling upon, knowing about in general and being proficient with -because of using on regular basis- some tech piece.
I do know how bitwise AND, NOT, OR, XOR work but I don't solve problems on day to day basis that use those.
If you give me two bytes to do the operations manually it is going to be a piece of cake for me.
If you give me a problem where most optimal solution is using combination of those operations I most likely will use other solution that won't be optimal because on my day to day work I use totally different things.
A bit of a tangent is that is also why we have "loads of applicants willing to do tech jobs" and at the same time "skilled workers shortage" - if company needs someone who can solve optimally problems with bitwise operations "right here right now", I am not the candidate, given couple of months working on those problems I would get proficient rather fast - but no one wants to wait couple of months ;)
It's probably a matter of domain, but most backend engineers who are working in Java/Golang/Python/Ruby systems have very little use of those, and they don't come up easily. Frontend (web or mobile), it comes up even less.
Can you tell me how this knowledge makes one a serious programmer? In which moments of the development lifecycle they are crucial?
Without judgement, this feels like a switch up. It seems to me that the prior author did not suggest they were necessary, but instead ambient, available, and interesting. Indeed for many they are not useful.
At the same time, that might be a good indication of passion: a useless but foundational thing you learn despite having zero economic pressure to do so.
In the domains you have worked on, what are examples of such things?
It is not a switch up. The author said that an engineer would find these during their journey, and I am asking when. I don't have a strongly held opinion here, I literally want to know when. I am curious about it.
Personally, I think it’s possible to not encounter them. I surely avoided them for a while in my own career, finding them to be the tricks of a low-level optimization expert of which I felt little draw.
But then I started investigating type systems and proof languages and discovered them through Boolean algebras. I didn’t work in that space, it was just interesting. I later learned more practically about bits through parsing binary message fields and wonder what the deal with endianness was.
I also recall that yarn that goes around from time to time about Carmack’s fast inverse square root algorithm. Totally useless and yet I recall the first time I read about it how fun a puzzle it was to work out the details.
I’ve encountered them many times since then despite almost never actually using them. Most recently I was investigating WASM and ran across Linear Memory and once again had an opportunity to think about the specifics of memory layout and how bytes and bits are the language of that domain.
I've mostly done corporate Java stuff, so a lot of it didn't come up, as Spring was already doing it for me.
I've first got to enjoy low level programming when reading Fabien Sanglard breaking down Carmack's code. Will look into WASM, sounds like it could be a fun read too.
I found them in 2015 when I was maintaining a legacy app for a university.
The developer that implemented them could have used a few bools but decided to cram it all into one byte using bitwise operators because they were trying to seem smart/clever.
This was a web app, not a microcontroller or some other tightly constrained environment.
One should not have to worry about solar flares! Heh.
Maybe. Every time I write something I consider clever, I often regret it later.
But young people in particular tend to write code using things they don’t need because they want experience in those things. (Just look at people using kubernetes long before there is any need as an example). Where and when this is done can be good or bad, it depends.
Even in a web app, you might want to pack bools into bytes depending on what you are doing. For example, I’ve done stuff with deck.gl and moving massive amounts of data between webworkers and the size of data is material.
It did take a beat to consider an example though, so I do appreciate your point.
Coming from a double major including EE though, all I have to say is that everyone’s code everywhere is just a bunch of NOR gates. Now if you want to increase your salary, looking up why I say “everything is NOR” won’t be useful. But if you are curious, it is interesting to see how one Boolean operand can implement everything.
I can understand writing your own instance and deployment "orchestrator", but I would not consider trying k8s for fun, because it just seems like some arbitrary config you have to learn for something someone else has built.
Nobody that uses bit flags do it because they think it makes them look clever. If anything they believe it looks like using the most basic of tools.
> One should not have to worry about solar flares!
Do you legitimately believe that a bool is immune to this? Yeah, I get this a joke, but it's one told from a conceit.
This whole post comes off as condescending to cover up a failure to understand something basic.
I get it, someone called you out on it at some point in your life and you have decided to strike back, but come on... do you really think you benefit from this display?
I made a concerted effort to understand the code before I made any effort to adapt it to the repo I was working on. I'm glad I did (although honestly, it wasn't in the remotest bit necessary to solve the task at hand!)
> someone who has "curiosity, passion, focus, creative problem solving" regarding programming
would find this on their journey. Whereas you are describing someone who merely views programming as a job.
It's perfectly fine to view programming as "just work" but that's not passion. All of the truly great engineers I've worked with are obsessed with programming and comp sci topics in general. They study things in the evening for fun.
It's clear that you don't, and again, that's fine, but that's not what we're talking about.
Software for you is a job. I work in software because it's an excuse to get paid to do what I love doing. In the shadow of the dotcom bust most engineers where like this, and, they were more technical and show more expertise than most software engineers do today.
It might be an indication for passion, but not knowing them does not indicate lack of it.
The thing is there are unfathomable amount of such things to learn, and if somebody doesn't stumble upon them or won't spend time with them it doesn't indicate lack of it.
I'm sorry but bitwise operators are the most fundamental aspect of how computing works. If you don't understand these things it does indicate a lack of passion, at least in regards to programming and computation.
Bitwise operators are not a particularly complex topic and extend from the basics of how logic is implement in a computer system.
Personally I think ever one interested in programming should have, at least once, implemented a compiler (or at least interpreter). But a compiler is a substantial amount of work, so I understand that not everyone can have this opportunity. But understanding bitwise operators is requires a minimal investment of time and is essentially to really understanding the basics of computing.
Guess I have a lack of passion then, despite building countless of full stack side projects and what-not even before I knew these could make me money at my teenage years. I started out with PHP using txt files as storage in my teens so none of what you said would be relevant to what I've experienced, and that was I would say almost 20 years ago. And in my high school years I took part of coding competitions where I scored high nationally without knowing any of bitwise or otherwise things, despite deeply enjoying those things.
This weird elitism drives me mad, but maybe truly I haven't done enough to prove my worthiness in this arena. Maybe PHP or JavaScript is not true programming.
You're talking past one another. The whole point of being interested and passionate about a topic is that you want to learn stuff regardless of whether or not it's useful
I can be interested in front-end development and learn everything there is to know about templating while never knowing about bitwise operators. Point is domains are so large that even if you go beyond what is required and learn for the sake of curiosity, you can still not touch what others may consider fundamental.
Yeah, that sounds like someone claiming to be passionate about math, but who never heard of prime numbers. It's not that prime numbers are important for literally everything in math (although coincidentally they also happen to be important for cryptography), it's just that it's practically impossible to have high-school knowledge of math without hearing about them.
What other elementary topics are considered too nerdy by the cool people in IT today? Binary numbers, pixels...? What are the cool kids passionate about these days? Buzzwords, networking, social networks...?
> I remember reading Yegge's blog post, years ago, saying that an engineer needed to know bitwise operators, otherwise they were not good enough.
I think he's right, nearly every engineer needs a basic understanding IP routing more today than in the 2000's with how connected the cloud is. Few engineers do, however.
Every time you need to ask yourself, "Where is this packet going?" you're using bitwise operators.
Yegge no longer thinks knowing these kinds of details matter so much, can’t find the exact timestamp but it relates to the skills shifting to being really good at prompting and quickly learning what is relevant
This is something I have some expertise in (I run a recruiting company that uses a standardized interview, and I used to run assessments for another). It's also something I've thought a lot about.
There is absolutely truth to what you're saying. But like most obvious observations that aren't playing themselves out, there's more to it than that.
-----
One: curiosity, passion, and focus matter a lot. Every company that hires through us is looking for them in one form or another. But they still have to figure out a means by which to measure them.
One company thinks "passion" takes the form of "wanting to start a company someday", and worries that someone who isn't that ambitious won't be dedicated enough to push past the problems they run into. But another thinks that "passion" is someone who wants to tinker with optimizing some FPGA all night long because the platonic ideal of making a 15% more efficient circuit for a crypto node is what Real Technical Engineers do.
These companies are not just looking for passion in practice, but for "passion for".
And so you might say okay, screen for that. But the problem is that passion-for is easily faked - and is something you can easily fail to display if your personality skews the wrong way.
When I interviewed at my previous company many years ago, they asked me why I wanted to work there. I answered honestly: it seemed like a good job and that I'd be able to go home and sleep at night. This was a TERRIBLE answer that, had I done less well on other components of the interview or had they been interviewing me for more than a low-level job, would likely have disqualified me. It certainly would not have convinced them I had the passion to make something happen. But a few years later I was in the leadership of that company, and today I run a successor to it trying to carry the torch when they could not.
If you asked me the same question today about why I started a company, an honest answer would be similar: I do this business because I know it and because I enjoy its challenges, not because it's the Most Important Thing In The World To Me. I'm literally a startup founder, and I would not pass 90% of "see if someone's passionate enough to work at a startup" interview questions if I answered them honestly.
On the flip side, a socially-astute candidate who understands the culture of the company and the person they're interviewing with can easily fake these signals. There is a reason that energetic extraverts tend to do well in business - or rather, there are hundreds of reasons, and this is one of them. Social skills let you manipulate behavioral interviews to your advantage, and if you're an interviewer, you don't want candidates doing that.
So in effect, what you're doing here is replacing one shibboleth that has something to do with technical skill, with another that is more about your ability to read an interviewer and "play the game". Which do you think correlates better with technical excellence?
-----
And two: lots of people are curious, passionate, energetic, and not skilled.
You say that a person with those traits "will learn" everything needed. That might even be true. But "will learn" can be three years, five years, down the line.
One of the things we ask on our interview is a sort of "fizzbuzz-plus" style coding problem (you can see a similar problem - the one we send candidates to prep them - at https://www.otherbranch.com/practice-coding-problem if you want to calibrate yourself on what I'm about to say). It is not a difficult problem by any normal standard. It requires nothing more than some simple conditional logic, a class or two, and the basic syntax of the language you're using.
Many apparently-passionate, energetic, and curious engineers simply cannot do it. The example problem I linked is a bit easier than our real one, but I have reliable data on the real one, which tells me that sixty-two percent of candidates who take it do not complete even the second step.
Now, is this artificial? Yeah, but it's artificially easy. It involves little of the subtlety and complexity of real systems, by design. And yet very often we get code that (translated into the example problem I linked) is the rough equivalent of:
print("--*-")
with no underlying data structure, or
if (row == 1 && col == 3)
where the entire board becomes an immutable n^2 case statement that would have to be wholly rewritten if the candidate were to ever get to later steps of the problem.
Would you recommend someone who wrote that kind of code, no matter how apparently curious, passionate, or energetic they were?
I have failed simple coding interviews because of stress. Been coding for 2 decades or more, know I'm good at it, and have had multiple other people confirm this. But sometimes under interview stress, I can lock up. Especially if something goes fubar like their on-line editor.
If I was at work, that wouldn't be a problem, take 3 minutes and come back to it. You don't have that in an interview.
I'm thinking of the observation from the speed climbing event at the Olympics. They had set up the course wrong, and one of the holds in one of the lanes was like 2cm out of position-- and it wasn't even a hold that was used by the climbers. But that was enough that people in that lane consistently lost.
Yeah, this is one of the best arguments against timed interview problems, and I do think it's a good one. You could justifiably argue for a lot of other structures, but those structures do come with their own trade-offs (like time investment for a take-home, or "game-ability" for a behavioral interview, etc).
This has been one of the most interesting and insightful replies I've ever got in a discussion. Thank you for taking the time and explaining your points. It really resonates with what I've seen in real life.
I don't know. Curiosity, passion, focus, creative problem solving seem to me much more important criteria for an engineer to have, rather than bitwise operations. An engineer that has these will learn everything needed to get the job done.
So it seems like we all got off the main road, and started looking for shibboleths.