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.
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.
The gatekeeping card won't fly here. This is not some obscure implementation detail of C/C++.
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)
"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.
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
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.
Depending on the hardware that byte can be 8, 12, 24, 32, or 64 bits (in my own experience over the years).
It's sad so many here are claiming that there are always and only 8 bits to a byte.
I've already replied to one person who quoted an ISO standard, that they clearly had not read, in support of this misconception.
That’s normally called a word. I’ve seen casual usage of “byte” in that context but formal documentation has always used word.
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.
[1] https://www.iso.org/obp/ui/#iso:std:iso-iec:2382:ed-1:v1:en
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.
So no, it's not a contraction of "by eight". It's just a different spelling for "bite", as a pun on "a bite of bits".
What systems are there with such large bytes?
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.
There are other examples but that should suffice.
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.
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..
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.
Now get off my lawn, all 1000 of you!
Binary kilobyte could be fine.
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.
Fixed, it ain’t.
When I see "KiB" or "kB", I just assume that the distinction matters.
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.
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.
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?
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.
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.
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.
Someone who has only attended a bootcamp cannot really be considered a 'professional software dev'...
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.
https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
Just to confirm: I believe people should know how computers work from an architectural stand point.
It has no bearing on actually doing the job, but how on earth did you manage to learn the necessary skills without learning that?
Many internet operators advertise speeds as "1Gb/s" or even "100M". Add in the confusion between 5G and 5 Ghz WiFi.
- 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
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.
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.
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 ?
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.
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.
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.
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 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!
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.
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!
(see also eg. : https://news.ycombinator.com/item?id=32216904 Experienced C programmer who can't fizzbuzz?)
[ 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 ). ]
> 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.
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.
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.
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.
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.
So as always: it depends. A front-end dev: nope, don't think so. Embedded software dev: you don't become one without knowing.
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.
From (the latest version of the standard you gave)
> byte
> string that consists of a number of bits, treated as a unit, and usually representing a character or a part of a character
> Note 1 to entry: The number of bits in a byte is fixed for a given data processing system.
> Note 2 to entry: The number of bits in a byte is usually 8.
Note Carefully: "usually"
ie. Just as it has always been - 16bits in a byte for any CPU with a smallest addresable unit being 16 bits, or 32, or 12, or 24.
As a C programmer I've worked with bytes of many different bit numbers, hence the need for a C compiler constant to define such things.
Today it is typical for 32 and 64 bit DSP processing chips (eg the TI DSP families) to have 32 | 64 bits per byte.
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).
https://registry.khronos.org/OpenCL/specs/2.2/html/OpenCL_C....
> 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".
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.
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...
A better fit for your question would be, should a dev know the difference between big endian and little endian? (Hint: Yes)
I would internally question the knowledge of someone claiming to be a professional in this field if they didn't know this fact.
Though that doesn't mean they couldn't be proficient and able to do their job.
If they've learned enough to market themselves as a software person, then they should have learned about bytes.
Bits, bytes, words, doubles, floats, ints... This information is everywhere. Every coding book starts with this.
Should devs also know economics and philosophy and English literature?
I don't think so.