Ask HN: Should a professional software dev know how many bits go in a byte?
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?
126 comments
[ 4.5 ms ] story [ 185 ms ] threadI 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.
Many internet operators advertise speeds as "1Gb/s" or even "100M". Add in the confusion between 5G and 5 Ghz WiFi.
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.
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.
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.
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...
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?
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.
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.
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.
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.
I don't think so.
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.
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.
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".
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.
- 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