6 ms·

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

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.

crystal_revenge 2y ago
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?
- bluepizza 2y ago
  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?
  - tel 2y ago
    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?
    - bluepizza 2y ago
      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.
      - valicord 2y ago
        Bitmasks, enumerating combinations (subsets), parsing binary data, ...
        jfyi 2y ago
        Cryptography, parity checking, sorting, image processing, optimization...
      - krisoft 2y ago
        > I literally want to know when When the curious engineer is reading a book about their choosen programing language. Most likely in the part which describes operators. Or when they parse something stored in binary.
      - tel 2y ago
        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.
  - usrnm 2y ago
    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
    - BadHumans 2y ago
      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.
    - mewpmewp2 2y ago
      What if I am passionate about stuff that is useful and helps me build more?
- Viliam1234 2y ago
  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...?
- ozim 2y ago
  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 ;)
  - mgkimsal 2y ago
    > given couple of months working on those problems I would get proficient rather fast - but no one wants to wait couple of months ;) yet they'll take a couple of months interviewing folks, and generally not find the unicorn they're after.
krosaen 2y ago
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 https://youtu.be/dTVXTo6Umfg?si=bBBwSutb6ned7o-X https://youtu.be/dTVXTo6Umfg?si=bBBwSutb6ned7o-X
rachofsunshine 2y ago
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 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?
MrDarcy 2y ago
> 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.

crystal_revenge 2y ago

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?

bluepizza 2y ago
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?
- tel 2y ago
  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?
  - bluepizza 2y ago
    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.
    - valicord 2y ago
      Bitmasks, enumerating combinations (subsets), parsing binary data, ...
      - jfyi 2y ago
        Cryptography, parity checking, sorting, image processing, optimization...
    - krisoft 2y ago
      > I literally want to know when When the curious engineer is reading a book about their choosen programing language. Most likely in the part which describes operators. Or when they parse something stored in binary.
    - tel 2y ago
      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.
- usrnm 2y ago
  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
  - BadHumans 2y ago
    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.
  - mewpmewp2 2y ago
    What if I am passionate about stuff that is useful and helps me build more?
Viliam1234 2y ago
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...?
ozim 2y ago
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 ;)
- mgkimsal 2y ago
  > given couple of months working on those problems I would get proficient rather fast - but no one wants to wait couple of months ;) yet they'll take a couple of months interviewing folks, and generally not find the unicorn they're after.

krosaen 2y ago

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 https://youtu.be/dTVXTo6Umfg?si=bBBwSutb6ned7o-X https://youtu.be/dTVXTo6Umfg?si=bBBwSutb6ned7o-X

rachofsunshine 2y ago

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 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?

MrDarcy 2y ago

> 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.