3 ms·

I have done 6+ years of practical, full stack development, and I have never had to set a bit... What? In which case? If I had learnt it 6+ years ago, I would h

I have done 6+ years of practical, full stack development, and I have never had to set a bit... What? In which case? If I had learnt it 6+ years ago, I would have forgot it by now. And I actually don't know how to do it without Googling, yet I have been able to be top performer in my current company for many years, promoting very quickly and providing tons of value. Maybe they have assessed me wrong in some way. I have never ran into such a bug, and I have never had a debugging issue that took too long to solve because of my lack of knowledge of computer science fundamentals. To clarify what full stack development has been about for me: 1) Single page apps/UIs 2) Managing hosts/containers/load balancing/scaling 3) APIs, for the UI mostly 4) CI/CD 5) Databases, querying, setting up, configuring. Basically anything you need to spin up a web app from 0 to 1. These systems have provided actual value to customers and have been performant to scale with demands. They have been providing enough actual value to justify my salary many times over which can be proven using raw numbers. I think if I ever had to set a bit, it means I have chosen bad tech/framework/wrong abstraction for what I'm trying to build, which is much, much worse than not knowing how to set a bit, in my view. If the tech I chose required setting a bit and similar other lower level things, it sounds like it would take much, much more time to actually develop it and it would be much more error prone, making it ultimately a very bad decision.

jiggawatts 5y ago
> I have never had to set a bit... What? In which case? Access modes on a file. C# enums with the [flags] attribute. Etc... It comes up. This is literally just OR-ing a value with a value. Not exactly rocket science! flag = flag | thebit; You say you have 6 years of experience, and you say you have never done that? Really?
- thomastjeffery 5y ago
  I think what GP is trying to say here is that they haven't needed to think about OR-ing in such low-level terms: they could just do it without worrying about the underlying theory and implementation.
  - mewpmewp2 5y ago
    Yeah, and I think I have never actually programmatically used this type of pattern. I have interfaced with things that do use this pattern as mentioned like file access system, which most of the changes I have done manually, understanding how single value represents various states. I'd argue if one were to do it programmatically, in most cases unless you are building the APIs for this yourself, in which case you should acquainted with the domain itself, and would learn about setting a bit during the process, you would use something like "file.setAccessMode("write", true)" etc, not only because it makes it easier to read, but because underlying implementation here shouldn't matter, since using an API like that means that setting this access mode could potentially work with any operation system etc, which might not be using the same representation of numeric value for read, write and execute. In all non low level cases you should be representing enums with strings, not with numbers like 1, 2, 4, 8, because the way I see it, it can only cause scalability, readability and maintainability issues. Just have a key value object, json or anything similar which would be structures like that const access { "write": true, "read": true, "execute": false }. And yes I have seen some legacy library code that uses 1, 2, 4, 8, but I've always thought naturally that it's unnecessarily complicated pattern, I have understood it, but I haven't known it as "setting the bit" and I don't think I have ever tweaked code like that neither created this type of code myself, so I actually may have never written a line of code to actually set a bit.
- mewpmewp2 5y ago
  I have changed file permissions using chmod, I understand how you can with a single value represent state of different flags/settings, by assigning 1, 2, 4, 8... for each flag, however I wouldn't have thought of it if someone asked me about setting a bit. It's not rocket science, I'm just not aware what the term means, nor have I ever consciously programmed something to "set a bit". I don't remember using syntax like flag = flag | thebit. And if I were to change file permissions programatically, it's very likely something like this would and should be abstracted away. And for enums/config in general I have used something on a higher level, like json/key values config or when I code programmatically, having actual string values for the enums. It seems in most cases representing a config with a single value is overkill and would only decrease code readability. And for readability/maintainability purposes it doesn't make sense to me to have arbitrary numeric values representing setting values, unless we truly have storage issues, but for web apps readability trumps at least here. Maybe I'm even now still misunderstanding why setting a bit is important.

jiggawatts 5y ago

> I have never had to set a bit... What? In which case? Access modes on a file. C# enums with the [flags] attribute. Etc... It comes up. This is literally just OR-ing a value with a value. Not exactly rocket science! flag = flag | thebit; You say you have 6 years of experience, and you say you have never done that? Really?

thomastjeffery 5y ago
I think what GP is trying to say here is that they haven't needed to think about OR-ing in such low-level terms: they could just do it without worrying about the underlying theory and implementation.
- mewpmewp2 5y ago
  Yeah, and I think I have never actually programmatically used this type of pattern. I have interfaced with things that do use this pattern as mentioned like file access system, which most of the changes I have done manually, understanding how single value represents various states. I'd argue if one were to do it programmatically, in most cases unless you are building the APIs for this yourself, in which case you should acquainted with the domain itself, and would learn about setting a bit during the process, you would use something like "file.setAccessMode("write", true)" etc, not only because it makes it easier to read, but because underlying implementation here shouldn't matter, since using an API like that means that setting this access mode could potentially work with any operation system etc, which might not be using the same representation of numeric value for read, write and execute. In all non low level cases you should be representing enums with strings, not with numbers like 1, 2, 4, 8, because the way I see it, it can only cause scalability, readability and maintainability issues. Just have a key value object, json or anything similar which would be structures like that const access { "write": true, "read": true, "execute": false }. And yes I have seen some legacy library code that uses 1, 2, 4, 8, but I've always thought naturally that it's unnecessarily complicated pattern, I have understood it, but I haven't known it as "setting the bit" and I don't think I have ever tweaked code like that neither created this type of code myself, so I actually may have never written a line of code to actually set a bit.
mewpmewp2 5y ago
I have changed file permissions using chmod, I understand how you can with a single value represent state of different flags/settings, by assigning 1, 2, 4, 8... for each flag, however I wouldn't have thought of it if someone asked me about setting a bit. It's not rocket science, I'm just not aware what the term means, nor have I ever consciously programmed something to "set a bit". I don't remember using syntax like flag = flag | thebit. And if I were to change file permissions programatically, it's very likely something like this would and should be abstracted away. And for enums/config in general I have used something on a higher level, like json/key values config or when I code programmatically, having actual string values for the enums. It seems in most cases representing a config with a single value is overkill and would only decrease code readability. And for readability/maintainability purposes it doesn't make sense to me to have arbitrary numeric values representing setting values, unless we truly have storage issues, but for web apps readability trumps at least here. Maybe I'm even now still misunderstanding why setting a bit is important.