> Learning binary and knowing what binary is are two separate things. I don't think you need to learn binary to learn to code. Been doing this for 25 years working at some big name companies, I don't know binary other than 1 is on, 0 is off.
You're wearing your lack of CS knowledge like some kind of badge of honor. Of course you don't need deep CS knowledge to be a competent programmer. But almost undoubtedly you'll be a better programmer if you do know CS (I'm using binary here as a proxy for CS since I can't imagine having a deep knowledge of CS without knowing something fundamental like binary). How many times over those 25 years could a problem have been more efficiently solved (in programmer time or CPU time) if you had known about problem solving techniques (perhaps those related to binary knowledge for example) that you don't know from the world of CS? You'll never know... You may guess, but you'll never know what you don't know.
It's not gatekeeping to say that to give someone a complete education to be a software developer we should provide them a knowledge of binary. We can teach programming in an approachable fashion AND teach binary in an approachable fashion. We do it every day at my college.
Why are you talking about CS and nonexistent "problem solving related to binary"? By "knowing binary" we are not talking about knowing machine code instructions or the details of how they are executed, but literally knowing how to read and work with binary numbers (using bitwise operations). Which isn't necessary for problem-solving or implementing most algorithms.
(Yes, there are algorithms that use bitwise operations. They're technically expendable and it doesn't make you any less of a programmer not to know everything. Especially if you're using Python or JavaScript!)
Are you joking? Without understanding binary, you can't understand:
- Numeric types, which numbers can be represented exactly, their failure modes, etc.
- Bit-field flags, e.g. for enums
- IP address masks and other bitmasks
- Anything at all about modern cryptography
- Anything at all about data compression
- The various ways color is represented in images
- Any custom binary format, MIDI, USB, anything low-level at all
Honestly the list goes on and on. It's absolutely insane to me to hear people say that you can be a competent software engineer without understanding binary.
The average web CRUD developer never needs to touch any of this stuff.
- Numeric types? Who cares? I know min, I know max. I take number from user and insert it in database. For calculations with money, I use integer cents.
- Bit-fields? I work in Java, what are bitfields?
- IP addresses? I am web dev loper, not network engineer. I don't need to deal with netmasks.
- Cryptography? Me no understand. Me use Let's Encrypt. Is secure, no?
- Compression? Browser do gzip for me. Me no care.
- Colors? I pick the nice color from the color wheel.
- Binary? What is binary? I only use binary when I want users to upload a file. Then I put the files on S3.
Well I do embedded dev as a hobby now so I know this stuff. But for a long time I didn't know how many bits were in a byte simply because I never really needed that knowledge.
Look, it's fine if you want to be hobbyist making some personal website that doesn't store PII or take user submissions. But we're talking about career software developers here. If you want to make a career out of it, this attitude is not only harmful to your career, but dangerous to your company. Besides: do you really not want to actually be good at what you do?
My attitude is: I learn whatever I need to learn to get things done.
And for a long time, I've just never needed to learn about how many bits were in a byte.
The only time I've ever needed to deal with individual bits in Java was when I was working with flags or parsing binary formats. Both of which are extremely rare when doing generic server dev.
You can even do rudimentary binary reverse engineering without any knowledge of bits. I remember running programs through a disassembler, looking for offending JMPs and then patching them out in a hex editor with 0x90.
Not having knowledge is not a problem as long as you know that you are missing that knowledge.
You have an artificially high bar so you can gatekeep people from being smart and be the arbiter of who's smart and who's not. What you don't realize is most people don't give a crap and easily hundreds of billions worth of software is sold every year by developers who don't know about anything you mentioned.
Your attitude is also inappropriate for a place called "hacker news" where people are resourceful try to do the most with whatever they have. Maybe you want to go to /r/compsci
You don't have to be a "competent software engineer" to be a developer, and in fact, we were never talking about being a "competent software engineer".
These developers do not get jobs as "competent software engineer"s, do not train to be a "competent software engineer", and do not care about being a "competent software engineer". And yet they make things that work perfectly fine! I'm sorry that you think handling PII or having a career (ooo) has anything to do with being a "competent software engineer".
> But we're talking about career software developers here.
I don't remember the name of this fallacy but it sucks, knock it off.
It's absolutely insane to pretend most software engineers need to do any of these things. We're making billions of dollars in aggregate without knowing this stuff. Most people aren't writing their own data compression algorithms, and we sure as shit aren't writing cryptographic algorithms because we're told to leave that one to the experts (i.e., mathematicians).
I'm guessing 80% don't even know bit-field flags and never have to use them, despite them being relatively simple. It would also take someone moderately capable at understanding math less than an hour to "learn." I learned them when I was 13 because I fucked around with MUD codebases, and I don't think I am special for it.
Do you realize that once you write code to solve a problem, that exact problem never needs to be solved again? Either you're solving new problems (and "new" can be slight -- new situation, new context, new hardware, new people, new company, whatever), or you're doing the compiler's job. If most people aren't solving new problems, then their job is bullshit. I frankly don't even understand how you can be confident that code copy-pasted from Stack Overflow actually does what you need it to do without understanding the fundamentals.
> we sure as shit aren't writing cryptographic algorithms because we're told to leave that one to the experts.
Shouldn't we all be striving to be an expert in something? If you're not working your way toward expertise, what are you doing? Why are the absolute fundamental basic building blocks for understanding how computers work and what programming languages are doing something that only "they" need to bother to learn?
Most of the problems software engineers are solving today are business problems defined by stakeholders in a business.
And yes, I agree we should be an expert in something. Harping on binary seems like a waste of time, however. I would certainly like that people are interested enough in the field that they spend their time learning as much as they can about CS, but I'm under no illusion that I'm going to automatically be more productive or better as a software engineer because I know bit-fields.
We're "harping" on it because it's so basic. There are a hundred equally basic things you should also know.
> Most of the problems software engineers are solving today are business problems defined by stakeholders in a business.
Even understanding the business problems usually requires a lot of fundamental knowledge in a wide variety of subjects. Being a good software engineer is hard.
And regardless of the problem, if the solution is going to be in code, you can't get away from binary. I actually don't think most programmers should be learning assembly language, because you can actually completely abstract away from it (and you should, because you don't know which assembly language you're programming for). But you can't abstract away from addition, the alphabet, binary, strings, algorithm complexity, and other basics.
PS: I didn't downvote you. I don't downvote people for disagreeing with me. I like disagreement, and besides, it would reduce the visibility of my pithy responses! I only downvote comments that aren't even worth arguing with. So the very fact that I'm taking the time to respond means I have at least some respect for your argument.
"Knowing" binary isn't some deep, fundamental CS knowledge, it's a party trick. Knowing about different number systems in general is nice, but hardly foundational.
The actual choice of what we consider part of the "core" CS curriculum is pretty arbitrary. Why do we consider, say, binary part of that but semantics not? Would it be "gatekeeping" to say that you can't be a good programmer without a passing knowledge of, say, operational and denotational semantics? Do you really have a "complete" CS education without it?
> "Knowing" binary isn't some deep, fundamental CS knowledge, it's a party trick.
Reread my comment I never said binary in-and-of itself is "deep" knowledge. I said not knowing it is a proxy for a lack of CS knowledge more generally.
> But almost undoubtedly you'll be a better programmer if you do know CS (I'm using binary here as a proxy for CS since I can't imagine having a deep knowledge of CS without knowing something fundamental like binary). How many times over those 25 years could a problem have been more efficiently solved (in programmer time or CPU time) if you had known about problem solving techniques (perhaps those related to binary knowledge for example) that you don't know from the world of CS? You'll never know...
You're both right and wrong.
Principles are a lot of cognitive debt to take on, and not strictly necessary to be functional. Literally anybody can sit down with an IDE and write code to merge spreadsheets or whatever the actual business need is. We teach this stuff to anybody with any interest. Kids, even!
If someone thinks they want to be a plumber, they shouldn't start with a 4-year commitment to learning principles of hydraulics and mechanical engineering-- makes much more sense to apprentice, lay some pipe, and if it's the job for you, then go back and learn it at a deeper level. Doing it the other way is why college is so ridiculously expensive and most spend 5 to 6 figures on a major and then go manage at Target.
After failing discrete math three times and giving up, I managed to make it almost 20 years in this industry before needing to learn anything about binary math-- and even then, it was only so I could understand how flags in old MUD code worked, for fun. Truth tables are important, but there has never come a logic problem I couldn't solve by taking a few extra steps to be explicit where you might reduce the logic to a compact blob of symbols. I'll never optimize code as well as someone classically-taught. I don't know what Big-O is-- and outside of a botched Google interview absolutely not a single employer or client has ever given a shit. Nobody has ever been victimized by my code. The "CS" way implies the academic approach is the only way to do things. It's the textbook definition of gatekeeping. All academia did was appropriate and institutionalize experiences yahoos like myself have always learned through ingenuity and trial-and-error.
You've learned more than I do, so you have more tools in your bag. The only thing that sets us apart is that I won't be advancing the industry or publishing anything on arxiv anytime soon. Outside of that, you're going to struggle with quantifying how you're better than the self-taught without resorting to speculation or guild/union mentality (gatekeeping).
You don't know that. Actually all code that is inefficient is victimizing both the user (via performance) and the environment (unnecessary energy usage). I'm not saying you've done anything wrong, I'm just saying we all don't know what we don't know. I'm sure my inefficient code has had many users and electric bills as victims. I released software before that subsequent versions where I had better CS techniques improved 100 fold in performance. I wasted my users' time before I learned how to do it better.
> You've learned more than I do, so you have more tools in your bag. The only thing that sets us apart is that I won't be advancing the industry or publishing anything on arxiv anytime soon. Outside of that, you're going to struggle with quantifying how you're better than the self-taught without resorting to speculation or guild/union mentality (gatekeeping).
You made a lot of assumptions about me without knowing my background. I was a self-taught programmer as a child/teenager and my undergrad degree was in economics, not CS. I went back to school to get a masters in CS which was difficult coming from a self-taught background. I did programming both paid and hobbyist for over a decade before that more formal education. And I write books read largely by self-taught programmers.
Saying a full software development education includes binary and the fundamentals of CS is not gatekeeping, it's a low bar if we don't want inefficient software wasting users time and sucking energy. I'm not saying you have to start there, I'm saying it should be part of your education as a programmer whether self-taught or formally taught.
You're wearing your lack of CS knowledge like some kind of badge of honor. Of course you don't need deep CS knowledge to be a competent programmer. But almost undoubtedly you'll be a better programmer if you do know CS (I'm using binary here as a proxy for CS since I can't imagine having a deep knowledge of CS without knowing something fundamental like binary). How many times over those 25 years could a problem have been more efficiently solved (in programmer time or CPU time) if you had known about problem solving techniques (perhaps those related to binary knowledge for example) that you don't know from the world of CS? You'll never know... You may guess, but you'll never know what you don't know.
It's not gatekeeping to say that to give someone a complete education to be a software developer we should provide them a knowledge of binary. We can teach programming in an approachable fashion AND teach binary in an approachable fashion. We do it every day at my college.