Would you say that if you program computers for a living you should always know there are (usually) 8 bits in a byte? Or is it perfectly fine not to know that / can it be considered specialized knowledge if you only program high level software, e.g. front-end web or CRUD business applications?
Even if someone doesn't need to work at a sufficiently low level as to need that information regularly, not knowing that suggests a severe lack of fundamentals and hints at trouble on the horizon. Someone could play at chemist and work with raw materials and follow recipes without knowing about electron orbitals, but without that understanding they may make disastrous choices if given insufficient oversight and their capacity for problem solving is limited.
> not knowing that suggests a severe lack of fundamentals and hints at trouble on the horizon
Exactly this. Strictly speaking you really don't need to know how many bits are in a byte, but it'd be difficult not to have picked up this kind of information having spent any time in the field. The absence of this knowledge is a strong indicator of shallow expertise.
I knew the answer, but that's because I learned it as a kid. I've never seen bits or bytes mentioned in resources for learning high level languages, nor has the topic ever come up in a professional setting.
For a professional dev in a high level language, this basically is a useless piece of trivia. It doesn't hint at trouble, because my code runs on machines that measure memory in gigabytes or at least hundreds of megabytes. Gatekeeping.
I'm sorry to disappoint you, but the so called high level languages like Python or Java are perfectly capable of working with bits and bytes, and countless developers have done so.
The gatekeeping card won't fly here. This is not some obscure implementation detail of C/C++.
I know they can work with bits and bytes, but your average web dev often doesn't get into that kind of stuff. I don't need the bitshift operator to put a button on a webpage or expose an endpoint.
Why is so fundamental about the fact that a byte is 8 bits? The fact that a byte is 8 bits is more for historical reasons. Likewise, an int is traditionally 32 bits, but Javascript and Python programmers don't need to worry about that. If a programmer doesn't know that a byte is 8 bits, they probably just forgot it since it wasn't necessary for them to know.
I have known what a byte was for, um, let's see, about 46 years now.
In the days when I learned what it was, it was fairly common for machines to have addressable units larger than a byte. We said that these machines "did not address to the byte". That is literally something you would say. Because a BYTE WAS NOT THE SAME THING AS AN ADDRESSABLE UNIT.
A word isn't the same thing as an addressable unit, either; your machine's word size is the number of bits it transfers over its main bus at one time and/or the number of bits it can work on in one operation. Which is maybe a bit fuzzy nowadays.
If I recall correctly, I read somewhere, back in the 1970s, that the word "byte" was originally used to mean the size of a text character. But in any common usage, even by the time I learned about it, it had settled down to just meaning 8 bits, period.
There's historically been sloppy overlap between "byte" and "word", even today formal documentation doesn't clarify a difference.
This stems from architectures that had both a both a minimal and maximal addressable "atomic chunk" via segmented architecture.
Conversations about this varied between Intel, Motorola, TI chipset users, PDP v Cyber programmers, etc.
From a Standard C Programming (as portable assembly) viewpoint Char and Byte are interchangable and are the smallest atomic type .. with the number of bits defined by a header constant.
No, a word is data size they work with as a unit. Modern 64-bit computers have 64-bit words, but they're still 8-bit addressable, so they have 8-bit bytes.
It's my understanding that the word byte is a contraction of the two words:by eight. Also (fun fact) a half a byte, 4 bits, is called a nibble. May be I'm out of touch but I have never seen a word referred to as a byte outside of an 8 bit processor, words are composed of bytes.
But I've seen "byte" used to refer to other numbers of bits lots of times, although primarily in the old days. Not so much anymore. I think the meaning has changed with time and has become fixed on "8 bits", but it was not always so.
In theory bytes can be a different size, and 8 bits is an octet. But any modern computer, at least those most people will ever come into contact with or hear of, have 8-bit bytes. So while 8 bits = 1 byte should be common knowledge, knowing about other byte sizes is esoteric knowledge.
The Texas Instrument TMS DSP family from 1980 through until today all have large bytes and lack octet addressing (and bit masking and such).
They are fiends for pipelined throughput and have low level ASM statements that modular index through vector calculations per clock cycle (increment pointers, multiply and add arguments, store results, etc) but are built for the float | double numerical domain grunt work with no ground given for bithack twiddling.
You're confusing a byte (8 bits) with a C `char` (the smallest addressable unit of memory that's at least 8 bits). Usually the smallest addressable unit regardless of size is a "word", some early machines had 6-bit words.
This is surprising to me. We measure bandwidth in bytes per second, and I'm not aware of that measurement being qualified by architecture. Are talking about the same "byte"?
Au contraire, mon ami... We measure bandwidth in bits per second, we say 100 Mbps or 1 Gbps, if you want to know the bytes per second you have to divide by 8, to know MBps or GBps
A software engineer that forgets that there are 8 bits in a byte is like a surgeon that forgets where the heart is in an human being, in my view... One might argue that it would be fine because as an orthopaedic surgeon specialised in hands they didn't need to care about the heart area but really you wouldn't let them near a patient because it's such basic knowledge that not knowing raises a massive red flag and the basic competency of the person is called into question.
Well, I would be slightly worried if a carpenter forgot how many centimeters go into a meter. (Or how many feet go into a yard?).
"Sure", you say, "but they don't need to know it by heart. The carpenter can always look that up if they really need it."
This is true. You are 100% correct.
But think of this:
Said conversion is pretty common in Carpentry, so each time our Carpenter forgets, they're going to end up looking it up again really quickly.
You would think that after having looked it up umpteen times, the Carpenter would effectively end up memorizing the conversion by accident. Right?
So while I suppose it's not strictly necessary, it would definitely be a bit funny to encounter a Professional Carpenter who doesn't have centimeters<->meters memorized.
This analogy assumes that JS/Python devs work with byte-level measurements all the time like how carpenters work with measurements centimeter-level measurements, which is very debatable.
JavaScript and Python need to calculate filesysizes, measure network bandwidth and track memory usage just like every one else. There's also of course bit shift operations and byte arrays. Heck byte size is relevant to floating point even.
As the saying goes: if all you have is a hammer, every problem resembles a nail. You can validly say "I've never actually needed a screwdriver", even if the screwdriver might have been more useful for the job at hand.
It also depends on what domain you're working in. I just happen to have been working on a Python/JS GUI to operate a Robot this past month. Interfacing with the Robot did require use of bits and bytes. Fortunately both Python and Javascript do support those operations for just those kinds of situations.
So while I do agree that some jobs can be done in javascript and python where you can avoid needing bits and bytes, that's my two answers:
1) Bits and bytes sure can come in handy at times. They might be the best tool for some jobs.
and
2) For some jobs you really do need to manipulate bits and bytes. You can't avoid them forever.
So if you like writing a lot of different kinds of programs for a lot of different kinds of things, you're almost certain to end up using bits and bytes sooner or later. Do that often enough and it does tend to stick. That includes Python and Javascript.
I could say the same about CSS though. Eventually, many developers end up working with CSS some way or another. But I still wouldn't consider flexbox a CS fundamental
Javascript is currently the most popular language, and many developers get exposed to it sooner or later. Should we be regarding it as part of "CS fundamentals" now? We didn't even learn it in my school.
Point being, the stack has grown larger, and just like we don't expect programmers to know electrical engineering, I don't think we should require front-end devs to know low-level knowledge (just like I wouldn't require backend devs to know CSS)
Emotionally, I want to say yes, they should know how many bits are in a byte, how many bytes are in a kilobyte (1000) and in a kibibyte (1024) and what big and little endianness is, and at least some part of the computing history that had led us to where we are now..
But rationally, I know that a lot of programmers don't care about computers, or even about programming and to them it's just a job.. And I guess I have no right to judge that..
For many of us a kilobyte will always be 1024 bytes despite the newfangled fashion for “kibi” this and “gibi” that.
Fortunately the people who adhere to the “ibi” cult are usually sticklers for compliant capitalization, so when I see “kB” I know it Must Be One Of Them.
I did pleasure in "no ackthually! it's 1024" before it got its own name, but something in my mind also finds it satisfactory that we're no longer hiding two values under the same name :)
> For many of us a kilobyte will always be 1024 bytes
Will it? In my memory, and I think that’s common for old hands, it always has been context-dependent. A kilobyte of RAM is 1,024 bytes, a megabyte of RAM 1,048,576 bytes, but a kilobyte of disk space is 1,000 bytes, a megabyte of disk space 1,000,000 bytes.
I think USB sticks and SSDs follow the hard disk convention of decimal kilobytes, but wouldn’t know for sure. Smartphones with a flash ‘disk’ use binary ones, though.
Nope, storage space was always measured in binary as well, except in ads. It's network stuff that's consistently decimal.
Windows, in particular, still uses binary units for file and disk sizes pretty much everywhere (Explorer, Disk Management, all command-line tools etc). MacOS uses decimal, but it only switched sometime around 2015. I'm not sure what the story is with Linux DEs, but CLI tools usually default to binary.
I'm more in the 1024 camp because that's what I grew up with but K is kelvin degrees and k is kilo. I can forgive everybody living in a non metric country but not someone living in a metric one.
And I don’t mind counting in 1000s or in 1024s depending on situation, but that -bi- just sounds so stupid. Kibi, mebi, gibi, tebi, pebi… bruh. Like childish mockery.
Yes, you're exactly right, in the same way as kilometer is 1024 meters and the other one is just car-manufacturer-distance-per-fuel-unit-marketing-speak-kilometer..
Kilo means 1000, and meant it before computers were a thing.. We retrofitted 1024 onto it literally hundreds of years later.. because it was close enough, it got annoying to deal with, we fixed it, if only recently in 2008, but better late than never..
Well, you published a standard for it, but as long as the new words use Teletubby speak to try and prevent people from using them, since nobody is going to say “gibibibitibi” out loud on purpose and the standardizers surely knew this, you’re gonna just have to keep living with the ambiguity.
When I see this come up, I always associate it with hard drives sold by marketing folks who just couldn't let a Megabyte equal the traditional value of 1,048,576 bytes... they had to sell that extra 4% by changing the meaning of a word.
I wouldn't call someone not knowing basics "a professional". And this is a basic knowledge not only for programming but networking, too.
This theoretical person from the title does use internet and would like to know how many megabytes per second can be pushed through their n megabits link, no?
What I have observed, as more and more people from a wider background enter into computer science and software engineering, is that it's not so much what they know or don't know that matters, but rather, what is their attitude towards learning something they don't already know.
If they embrace new knowledge and appreciate those who bring it to them, then I couldn't think of someone better for this art. If, on the other hand, they dismiss anything that they don't immediately see the value to, even at the behest of someone either more senior or experienced, then I would say, that is the red flag.
Absolutely they should know. This comes up so many times even in high-level programming that anyone who’s doing anything beyond very trivial student applications should know this stuff.
I think any person remotely interested in computers or programming can and should "know" that a byte is 8 bits.
But... does it matter?
Unless you are working with hardware or in embedded systems more directly, it ABSOLUTELY does not matter at all.
What matters is to have a critical eye for numbers when they matter and/or are "off". That is much more valuable for the day-to-day work.
"Damn, before we could easily hit this endpoint X times per second and after that refactor and library change it's down to X/5? We need to have a look".
Sizes of DB tables, latency of endpoints and being able to properly read stacktraces or logs from a third-party service is much more valuable.
PS: people writing in the comments about not knowing how text encoding works, about sending data trough sockets, etc... Folks, you know how to do these things because they are required from you at your day job, you probably had exposure to proper patterns and got help from experienced people within that particular niche at your company. That's all. Knowing 1 byte is 8 bits is absolutely meaningless knowledge on its own.
I needed to know these "standard sizes" for my CS degreee,sure. Do they matter for my day-to-day work? Not in the slightest.
Interviewing? Sure. Those LeetCode algorithmic problems have a tendency to sometimes touch upon these well-established values of the underlying architecture of bytes/bits and how memory pages are structured, etc.
The thing is: Working with Java and Python in your classical corporate job maintaining a DB schema, creating and/or optimizing endpoints with Flask and/or Springboot, most of these underlying concepts will be shielded from you entirely.
Again, in Java, you can specify the load factor for a HashMap when you create it... I bet you 99% of the developers working with Java have never needed to do it or might not even know what it is or how it works under the hood.
Maybe they don't even know that internally the hashtable size is managed in powers of two... but again, I don't truly believe this matters for 99% of the work you'll be doing.
It's either something that you need to use or fully understand, or something that will always be abstracted away from you.
8 or 2^8 or 2^8-1 are just numbers basically.... It's good to know a bit their intrinsic meaning or why they are relevant just as a general knowledge, but, unless you are doing C programming at a very low level, embedded systems, microcontrollers, etc, this is just knowledge that will _never_ be used.
The approx. two decades of my career have been in what an embedded systems programmer would call "basic CRUD apps". From my perspective it's quite a bit deeper than that, as most of that time has been spent doing mostly what would be termed an SRE these days, but still - at the end of the day I've been responsible for increasingly complex frontends for databases.
The numbers 2^8 and 2^(8-1) come up all over the place.
Can you provide some examples and a bit more context? I'm genuinely interested in knowing more! I spend my time writing APIs and optimizing the DB layer all in postgres and springboot and I sincerely need to "squint" to come across those values in a way that directly affects my work so I'm genuinely curious :)
This may be an outdated opinion based on the people I'm seeing leave bootcamps. I think that underlying architecture is so heavily abstracted these days that you do not need to really know _how_ a computer works in order to make something functional.
You can definitely make something functional without knowing how it works. But it will only work until it doesn't, then you won't be able to debug it. Coding javascript for example is removed enough from the internal working of the processor that a lot of details don't matter. But should you need to send a binary data packet somewhere through a websocket...
Don't get me wrong, I agree. I just see a lot of people bypass the basics.
I think that this kind of thing will become too low level for most developers and it'll become speciality knowledge. I'd say that most developers I've met have been content to sit and plug one package into another, without too much care about how they work.
Once you encounter the problem of sending binary data somewhere, presumably you will look up how to do that and find out all you need to know about bits and bytes.
I'm sure that people can get paid to code simple, well defined stuff in a very high-level language/script without formal training but "professional software dev" implies a level of knowledge and competency that is far beyond knowing how many bits are in a byte, which frankly is "teenager interested in computers" level of basic knowledge.
In fact, IMHO a professional software dev will be reasonably proficient in binary and powers of two in general as a matter of basic knowledge.
This is the strongest point that comes to my mind. I feel that most consumers are completely unaware that their perception of transfer speeds and file size differ by almost an order of magnitude. I absolutely hate how marketing takes advantage of this. Imagine the frustration after thinking that your 10 Mbit/s connection can download a 6 GB game in just ten minutes.
Many internet operators advertise speeds as "1Gb/s" or even "100M". Add in the confusion between 5G and 5 Ghz WiFi.
Considering ACKs traffic when doing back of the envelope estimates I divide by 10: 100 Mb/s = 10 MB/s (on Ethernet, Wi-Fi who knows.) But that introduces a new problem: how many developers have an idea of how networking works? A smart developer I worked with once told me that he only knows how to turn Wi-Fi on and off.
Yes, regardless of how much these are abstracted in modern software development. Size is an important aspect of many things in a computer. It impacts:
- storage capacity
- speed of communication
- speed of computation
- representation of numeric values
- encoding of strings
Bits and Bytes are the fundamental units of size and representation, and knowing them is critical to understanding most other things that build on top of them.
For high level software, you see this come up in:
- integer limitations (e.g. database identifiers)
- internationalization of user interfaces
- floating point numeric comparison and other mathematical operations
- communications over various transport layers
- speed of various abstractions that are used to make the higher level software fast / good
This is basic knowledge. Of course one should know how many bits go in a byte. It's like asking if one should know how to replace a bulb. Not a software developer, every person should know that. It's like knowing that there're 1024 bytes in kibibyte or 1000 meters in kilometer.
These days one should even know how exactly double is represented in hardware as it's the main type in JS and one should clearly understand bounds of integer numbers which could be represented in double without precision lost.
Should a programmer also know about FS block sizes? About ethernet size? About Multithreading? Memory access bandwidth? CPU architecture? Stored procedures in a DB? Current encryption schemes?
I would say it depends totally on the tasks of the coder. If you fiddle around with some ASP: NO. If you are squeezing every last bit for Netflix performance: YES.
Our domain is so incredibly huge, deep, wide & divers that I do not expect regular coders to be familiar with most details.
The only thing i'm not opiniated on is block size because while this is interesting, this isn't usefull for debugging or optimizing. All the rest any dev should have an idea of what it is and seek further knowledge when needed. Even if he is a frontend dev.
Yes. Try adding 1 to a number which is already (in binary) all '1's. If you don't know the size of a byte, or an 'int' or a 'long int' etc for the language you are using you will be mystified why it is now 0, or maybe some other number your language decided was sensible to use (signed vs. unsigned etc). Then extrapolate that times 100 when dealing with floating point etc and presenting a sensible total in your shopping cart web app. If you don't know this stuff learn it or stay away from programming.
I don't think it's required to work as an average professional web dev. If you want to be a good developer and keep getting better, understanding the fundamentals of computer science is very important (and makes the job more interesting, in my mind).
People say you should know something about the lower-level programming and they are right IMHO.
Even as computer user: Internet speeds are regularly given as megabits per seconds. How do you estimate how long will a 5GB file upload without knowing it's 8b/B ?
Of course people should know some of the basics of hardware and software development. Not knowing the basics or the chain of steps a framework or a protocol takes means you might oversee optimisation or pain points in a certain workflow.
But then again knowing how many bits go in a byte it's not needed to be productive in 99% of the cases.
Then again when a professional software developer can't tell me how many bits go in a byte or cant at least explain to me how to read/use call stack/stack frame in a IDE or terminal etc. I really start to wonder how experienced and professional that developer really is.
Yes. This comes up even in the highest level and most trivial work.
And not just “should be able to look it up”, but should know it in their sleep.
Should also know other esoterica like e.g how a string could be zero terminated in one case but length prefixed in others, Joe they could be one, two, four, or variable numbers of bytes per character/glyph in a string and so on. Not because one needs this every day but a) because doing work adjacent to it means you eventually shoot yourself in the foot and b) doing any amount of work will expose you to this and not having picked up on it means you aren’t picking up things.
Yes, probably any software developer should know the trivial fact, that a byte consists of 8 bits (nowadays) - even if the developer is not involved with bit operations.
Much more important, in my eyes, and more sophisticated, is the concept of the computer "word": a professional software dev should know how many bytes go in a word, how word length corresponds with bus width, memory organisation and how types depend on word length.
And in my humble opinion, Unicode encoding is such a basic concept, that every dev should understand it on a bit level.
If you can't do napkin math with bits and bytes to calculate capacities, bandwidths, flows etc. you are lacking one of the most essential skills there are, and need to pick up the slack ASAP.
Probably not, it's something you can look up, and the 1000 vs 1024 naming distinction (e.g. kibi vs kilo) continues to be something that most developers I encounter aren't up to speed on. I use libraries with classes modelling such units in them if I need to do arithmetic with them, at the very least to offer security for others when they look at my code.
I think what matters is that you're reasoning about things and being thorough and careful. Broadly, I haven't yet had someone give me a pop quiz at my job yet.
I was about to say "no", until I realized just how much I internalized this knowledge.
In front-end you may be able to write decent applications without knowing that, but for CRUD apps it would say it is impossible to avoid.
I mean, it's something you will inevitably stumble upon. I'd say that even if you actively try to avoid learning how many bits go in a byte you will one day wake up screaming "Fuuuuuuck, I never wanted to know that there are 8 bits in a byte!!!!!"
There, now you know, too!
Based on my 25years experience with that line of work, this knowledge is not required at all and won't make you write better code. Some coworkers will question your competence, which is a disadvantage.
Hiring wise, if you've spent a few years programming without ever learning about "that bits&bytes thing", an employer is tempted to doubt your education, level of curiosity and/or general interest in your field.
To me, knowing how computers work is just something I thought every programmer would just know as fundamental knowledge (note bytes don't always have 8 bits, but it's the most common).
I guess there is not an absolute need to know this if it doesn't affect business logic type programming or UIs, although I think I might think a person was not very well educated or curious if they didn't know that.
There's a surprising number of programmers who can't count in binary, or who can't do bitwise operations , or ... any number of things.
It's surprising how far some people can get with their hands tied behind their backs.
I wouldn't recommend it of course. Also it might possibly be a kind of warning flag: how can someone constantly be exposed to this stuff and never pick it up? But somehow it does sometimes happen!
[ For folks wondering why I'm talking about counting: Bits and bytes is all about learning to count with just 1 finger: 1, 10, 11, 100, 101, 110, 111, 1000, ... And the largest number you can count up to in a byte is 1111 1111 of course (A byte has 8 Binary digITs, and the highest number you can count to in a byte is having all those digits be 1s. In decimal this is the number 255. If you use a computer a lot, you might have run into 255 more often ). ]
My first tech question I got asked at an interview 20 years ago was:
> Is this number positive or negative?
> 0101 0101
They expected me to ask about things like endianness and to know the least significant bit is the only one we are about to answer that question.
While bits in a byte "is" a "low level" topic. It is one of the more useful ones even for CRUD.
My instinct is that "yes"... basic knowledge like this is important. After all, even as an API developer I have often had to know things like how many bytes an int is on my machine, how bitwise operators work, whether the system is little endian or big endian, etc.
Also, how do you understand Unicode (something very important for i18n) if you don't know the answer to this question?
But then I had to go back and second guess myself. Most of this stuff is abstracted out now.
I would say it comes down to what type of data you are dealing with. If you're dealing with files in binary formats, compilers, etc. Then yes, you need that stuff. And yes, a simple CRUD app does sometimes need to deal with that stuff. But if not? I guess it's fine not to know.
I would argue the subset of software engineering that does not require this type of knowledge is a far, far smaller portion than that does. Maybe if you're only dealing with the simplest of CRUD + web stuff. Looking back on my own career, which started in corpo CRUD hell, it was still relevant knowledge a number of times.
My answer to the question of whether should X know Y is yes if this is what you do on daily basis. If this is relevant but needed only occasionally, then just having a vague awareness of it existing and being able to find exact information when needed is enough. In my opinion, a professional is not somebody who knows absolutely everything there is to know in the field, but someone who firstly has a lot of hands-on experience and somebody who can quickly fill in the gaps in the knowledge when necessary.
A "professional software dev" is a very broad category. In most of web development, you can get away just fine without knowing how many bits are in a byte. On the other hand, in Arduino you'd encounter bits and bytes on a regular basis.
As for me, if somebody was to ask me this question during an interview, I would assume that it's a trick question. There were some old exotic architectures in the past such as IBM that stored data in 6bits.
20 years ago? Definitely. Today things are a little different. So much abstraction makes it possible to plug programs together without knowing such things.
If I were hiring a generalist hacker type, they'd better know the answer. I expect a generalist to be able to do all kinds of tasks. But a specialist on something high level might get a pass.
That’s a strange question. If by professional you mean by trade, then yes, many programmers don’t work with bits or type limits directly and could do fine without that knowledge.
If by some sort of baseline certification (school, degree, etc) it’s hard to imagine that it’s not in an educational program, e.g. UTF-8 hints at it directly it the name. Can a programmer read a text file without knowing about UTF-8, at least as an enum-like parameter? Or know floating-point limitations, which every programmer should know, and not notice that float32 is 4 bytes wide? Or choose #rrggbb color never realizing that each 00..FF part stands for 2 hex / 8 bits?
I think in reality it’s either a sign of a very narrow specialization, very low experience or just a complete lack of awareness. It’s like going through a forest for months and never noticing a fallen tree.
It's almost like a journalist or novelist not knowing there are 26 letters in the alphabet.
Sure you might not actually need to know it to do your job, at least most of the time. But sometimes you will, and honestly it's a bit ridiculous not to know it.
They need not know by heart, but they should be able to find out if necessary.
Reminder that 8 bit bytes were standardized in 1993 (ISO/IEC 2382-1:1993 according to Wiki), and before that it was common to have bytes be 6, 8 or 9 bits.
Any C | C++ compiler targeting that GPU will call that 32bit blob a CHAR and will have the constant CHAR_BIT sety to 32 in (c)limits.h
Within the low level standard C programming commmunity the terms Byte and Char are interchangable and vary by architecture or domain (8 bits in a networking application domain, potentially more bits on various target architectures).
In a somewhat qualified and frequently struck through manner if you parse the entire document.
> OpenCL (Open Computing Language) is a framework for writing programs that execute across heterogeneous platforms consisting of central processing units (CPUs), graphics processing units (GPUs), digital signal processors (DSPs), field-programmable gate arrays (FPGAs) and other processors or hardware accelerators.
Here's the thing, any processing done on 32 bit | 64 bit RISC like DSP chips can talk about having an 8 bit char .. but these will be embedded within a 64 bit "smallest addressable unit" as the hardware pointers iterate from one 64 bit (or 32 bit) chunk to the next.
There are also (within the DSP components) restrictions on masking out 8 bit segments of a 64 bit "smallest addressable chunk" as the hardware is optimised for integer and float operations w/out a care for delicate little 8 bit operations.
In other words, in a hybrid Franken-beast creating "images" from convolutions and signal operations, the hardware that writes packed image formats with OpenCL char types will not (can not) be DSP type hardware that convolves and fouriers the computations that create the "now package me" pre-final image sets.
Returning to the base point, the mere fact that sometime a char is 8 bits ion no way requires a char to always be 8 bits .. if you read about it is most generally defined as "at least 8 bits".
The infestation of the workforce by the bootcamped parrots that puke out memoized nonsense and call themselves a professional programmer is going to further degrade the quality of code everywhere
I didn't appreciate this comment at all. I have worked with folks from non-computer science backgrounds that only picked-up programming from a bootcamp and they were fine programmers for their level. I would gladly have them on my team over others that bring with them a bad attitude or cannot work well with others.
There's more to a successful team than top-quality code on the first try. Very few people can do that, even among experienced developers.
Bad code is due, in large part (in my experience) due to a lack of any kind of technical leadership. Put a competent tech lead or manager (i.e., one that can code/was a senior dev before) over even mediocre developers and you come come-up with decent code. Surely there are folks better than others, but bootcamp graduates aren't all bad and not the only source of bad programmers. It's more about attitude and willingness to learn than out-the-door abilities, in my opinion, as I stated elsewhere in the comments.
The problem with purely learning things on a need to know basis is that every debug task that goes outside of the programming knowledge of the dev becomes an incredible scavenger hunt.
Hmmm this is interesting, my background is industrial automation, where every day I would work with bits and bytes. But today and the last 10 or so years I have been building higher level software, machine data collection, web, db etc. I can honestly say not once have I had to deal with bits or bytes, I cannot think of an instance here I have needed the knowledge either. So I guess it’s not a requirement for software development today. But I still feel it’s important knowledge but can qualify why.
I guess you could develop in a high level language and don't know about it. But I guess at some point you would come in contact with that knowledge.
It is quite useful knowledge though, at least in some applications. I do embedded systems where I use bit operations regularly. I also do visualizations in the browser with JS mostly and I cannot remember ever needing to know that a byte is 8 bit (usually). Thinking about it I don't know the exact size of the datatypes I often use either...
Functionally, you don't usually need to know this kind of thing. But it's something that is taught in CS 101, pretty close to day 1. Yes, you should know stuff that basic!
A better fit for your question would be, should a dev know the difference between big endian and little endian? (Hint: Yes)
When you are working as backend developer and your clients are mobile devices, is your message 8 times smaller or bigger is difference between up-and-running and outage.
At that point you also won't know how text encoding works, or why integers only store numbers up to a certain limit, which are problems that you encounter in high level software as well.
Bytes/bits are themselves an abstraction. If you dont work with this representation directly, then this trivia can be added with others in the list of things you dont know.
