As someone who spends time programming, I of course find myself in conversations with people who aren’t as familiar with it. It doesn’t happen all the time, but these discussions can lead to people coming up with some pretty wild misconceptions about what programming is and what programmers do.
I’m sure many of you have had similar experiences. So, I thought it would be interesting to ask.
I get that from our product owners a lot, and I usually say “yes!”, followed by an explanation of how much time it will take and why it’s not the path we want to take. People respond well to you agreeing with them, and then explaining why it’s probably not the best approach.
I would have written that comment if you hadn’t already done it.
I don’t know exactly why people think that we can “just” do whatever they ask for.
Maybe it has something to do with how invisible software is to the tech-illiterate person but I’m not convinced.
I’m sure there are other professions that get similar treatment.
I know you built the bridge to support 40 ton vehicles, but I think if we just add a beam across the middle here, we should be able to get 200 tons across this no problem? Seems simple, please have it done by Monday!
I once watched a video lecture from the guy that implemented lambdas in the JVM and he was giving community feedback that he received. He said, “Obvious but wrong answers have the word ‘just’.”
We have a half finished skyscraper, and you’re asking me to Just add a new basement between the second and third floor. Do you see how that might be difficult? If we want to do it, we have to tear down the entire building floor by floor, then build up again from the second floor. Are you prepared to spend the money and push back the release date for that new feature?
“Just” is a keyword that I’m going to triple my estimates. “Just” signifies the product owner has no idea what they are requesting, and it always becomes a dance of explaining why they are wrong.
I worked in a post office once. I once had a customer demand some package delivery option, if I remember correctly. He was adamant that it was “only a few lines of code”, that I was difficult for not obliging, and that anyone in the postal service should make code changes like that on the whims of customers. It felt like I could have more luck explaining “wallpaper” to the currents in the ocean…
I used to work on printer firmware; we were implementing a feature for a text box for if you scanned a certain number of pages on a collated, multi-page copy job. The text box told you it would print the pages it had stored to free up memory for more pages; after those pages had printed, another text box would come up asking if you wanted to keep scanning pages, or just finish the job.
The consensus was that it would be a relatively simple change; 3 months and 80 files changed — with somewhere in the ballpark of 10000-20000 lines changed, — proved that wrong.
Just what was in the main repo (at least one other repo was used for the more secure parts of the code) was a little over 4 million lines. But yeah there’s a lot of complexity behind printers that I didn’t think about until I had worked on them. Of course that doesn’t mean they have to be terrible, it’s just easier to fall into without a good plan (spoiler alert: the specific firmware I was working in didn’t have a good plan)
A lot of the complexity came from around various scenarios you could be in; my goto whenever people would ask me “Why can’t someone just make printer firmware simple?” is that you could, if you only wanted to copy in one size with one paper type, no margin changes, and never do anything else.
There’s just so many different control paths that need to act differently; many of the bugs I worked on involved scaling and margins. Trying to make sure the image ended up in a proper form before it made it to hardware (which as more complexity, ran on a different processor and OS than the backend so that it could run realtime) when dealing with different input types (flatbed scanner vs a document feeder, which could be a everyday size, or like 3 feet long) different paper sizes, scaling, and output paper. I mainly worked on the copy pipeline, but that also was very complex, involving up to, something like, 7 different pieces in the pipe to transform the image.
Each piece in the pipeline was decently complex, with a few having their own team dedicated to them. In theory, any piece that wasn’t an image provider or consumer could go in any order — although in practice that didn’t happen — so it had to be designed around different types of image containers that could come in.
All of that was also working alongside the job framework, which communicated with the hardware, and made sure what state jobs were in, when different pieces of the pipeline could be available to different jobs, locking out jobs when someone is using the UI in certain states so that they don’t think what’s printing is their job, and handling jobs through any of other interface (like network or web.)
That’s the big stuff that I touched; but there was also localization; the UI and web interfaces as a whole; the more OS side of the printer like logging in, networking, or configuration; and internal pages — any page that the printer generates itself, like a report or test page. I’m sure there’s a lot more than that, and this is just what I’m aware of.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
“Just”
That one word has done a fuck ton of lifting over my career.
“Can’t you just make it do this”
I can’t “just” do anything you fuck head! It takes time and lots of effort!
I get that from our product owners a lot, and I usually say “yes!”, followed by an explanation of how much time it will take and why it’s not the path we want to take. People respond well to you agreeing with them, and then explaining why it’s probably not the best approach.
I would have written that comment if you hadn’t already done it.
I don’t know exactly why people think that we can “just” do whatever they ask for.
Maybe it has something to do with how invisible software is to the tech-illiterate person but I’m not convinced. I’m sure there are other professions that get similar treatment.
I know you built the bridge to support 40 ton vehicles, but I think if we just add a beam across the middle here, we should be able to get 200 tons across this no problem? Seems simple, please have it done by Monday!
I once watched a video lecture from the guy that implemented lambdas in the JVM and he was giving community feedback that he received. He said, “Obvious but wrong answers have the word ‘just’.”
I like to say:
“Just” is a keyword that I’m going to triple my estimates. “Just” signifies the product owner has no idea what they are requesting, and it always becomes a dance of explaining why they are wrong.
Also “simple”. “It’s a simple feature.”
It’s like, gotta be just one line of code, right?
I worked in a post office once. I once had a customer demand some package delivery option, if I remember correctly. He was adamant that it was “only a few lines of code”, that I was difficult for not obliging, and that anyone in the postal service should make code changes like that on the whims of customers. It felt like I could have more luck explaining “wallpaper” to the currents in the ocean…
If this isn’t just a saying I haven’t heard of, I’m doing my best to make it a common place phrase, absolutely perfect in this context!
Thank you so kindly :) It’s not a saying, as far as I know.
Anything can fit in one line of you are brave enough.
I’m pretty sure that’s a breach of style guide in at least three different languages
but probably not C++
Everything is one line of code in a turing machine.
I used to work on printer firmware; we were implementing a feature for a text box for if you scanned a certain number of pages on a collated, multi-page copy job. The text box told you it would print the pages it had stored to free up memory for more pages; after those pages had printed, another text box would come up asking if you wanted to keep scanning pages, or just finish the job.
The consensus was that it would be a relatively simple change; 3 months and 80 files changed — with somewhere in the ballpark of 10000-20000 lines changed, — proved that wrong.
I’m starting to understand why printers are so horrible
Just what was in the main repo (at least one other repo was used for the more secure parts of the code) was a little over 4 million lines. But yeah there’s a lot of complexity behind printers that I didn’t think about until I had worked on them. Of course that doesn’t mean they have to be terrible, it’s just easier to fall into without a good plan (spoiler alert: the specific firmware I was working in didn’t have a good plan)
Out of curiosity do you have any good examples of this hidden complexity? I’ve always kinda wondered how printers work behind the scenes.
A lot of the complexity came from around various scenarios you could be in; my goto whenever people would ask me “Why can’t someone just make printer firmware simple?” is that you could, if you only wanted to copy in one size with one paper type, no margin changes, and never do anything else.
There’s just so many different control paths that need to act differently; many of the bugs I worked on involved scaling and margins. Trying to make sure the image ended up in a proper form before it made it to hardware (which as more complexity, ran on a different processor and OS than the backend so that it could run realtime) when dealing with different input types (flatbed scanner vs a document feeder, which could be a everyday size, or like 3 feet long) different paper sizes, scaling, and output paper. I mainly worked on the copy pipeline, but that also was very complex, involving up to, something like, 7 different pieces in the pipe to transform the image.
Each piece in the pipeline was decently complex, with a few having their own team dedicated to them. In theory, any piece that wasn’t an image provider or consumer could go in any order — although in practice that didn’t happen — so it had to be designed around different types of image containers that could come in.
All of that was also working alongside the job framework, which communicated with the hardware, and made sure what state jobs were in, when different pieces of the pipeline could be available to different jobs, locking out jobs when someone is using the UI in certain states so that they don’t think what’s printing is their job, and handling jobs through any of other interface (like network or web.)
That’s the big stuff that I touched; but there was also localization; the UI and web interfaces as a whole; the more OS side of the printer like logging in, networking, or configuration; and internal pages — any page that the printer generates itself, like a report or test page. I’m sure there’s a lot more than that, and this is just what I’m aware of.
Wow, thank you
Simple features are often complex to make, and complex features are often way too simple to make.
I believe that it’s not for nothing that simplicity is considered more sophisticated. Many, many cycles of refinement.
It’s a meme to say “can’t you just” at my workplace
“Would you kindly”…