4 ms·

I notice a lot of devs try to deny the chaos of the world. It's almost like the code is where they go to hide from things that can't be cleanly and unambiguousl

by ziml77 2y ago

I notice a lot of devs try to deny the chaos of the world. It's almost like the code is where they go to hide from things that can't be cleanly and unambiguously expressed. I don't know how they get away with that though. In the coding work that I do, I'm constantly dealing with rules that have exceptions on top of exceptions. I just need to special-case some things, because the alternative is not delivering what the business needs.

jbverschoor 2y ago
And this is exactly the problem when these devs are in charge of creating systems that actually do matter. They will not support edge cases, problems in a process, etc.
- vharish 2y ago
  I mean.. can you show anyone piece of software or hardware or for that matter any man made creation that solves for all edge cases?
  - jbverschoor 2y ago
    But it’s just simple things, like allowing an override of a status field. Or using a status field to check something is ok or not, instead of always checking the data itself. People make wrong assumptions, and requirements change. Don’t make it all rigid that you always need to implement every case
    - borski 2y ago
      Everything is a “simple thing” unless you’re the one implementing it. Things that seem simple on the surface rarely are, especially long-term.
      - jbverschoor 2y ago
        I’d say it has to do with not willing to duplicate data. On paper forms, it is simple. Why can’t it be in a digital form?
        borski 2y ago
        https://www.quora.com/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3/answer/Michael-Wolfe https://www.quora.com/Why-are-software-development-task-esti...
        jbverschoor 2y ago
        That article means: inexperience and unprofessional. Sounds about right.
        borski 2y ago
        If you’ve never written software that needed to be used by tens of thousands or hundreds of thousands of people, then sure, it could seem that way.
zerkten 2y ago
When I was hired for my first real programming job, my future manager spent a lot of time asking me questions about how I deal with ambiguity. This stuck with me as a really important element to consider in people, but that doesn't seem universal, especially in tech circles.
vharish 2y ago
This is a very broad generalization and not a good one either. Particularly in this context. It's obviously not possible to do it for all video formats in a consistent way. I haven't read through all of it yet I could tell all the proposed solutions are hacky ones. Your scenario doesn't apply here. Businesses are different. This is on open source project. Anyone can work on it. What are you even saying about the choas of the world?! Every dev knows how work is. You are just describing every other software job. Somehow it sounds like you are boasting how matured you are just because you do what your client asks/needs. Even then, many business/software make a concious choice to support or not support something based on some guidance. The guidance could be some core principles or just some product managers whim. It's highly likely that VLC developers chose not to support the feature for the very reason(s) that's described in the post. It's a concious choice they made. I don't see anything wrong in that. They definitely are not some school kids with some daddy issues to hide behind some code. They clearly have answered all the questions from a technical stand point.
- ziml77 2y ago
  But the hacky solutions actually get done what people want the software to do. The point between me and the parent poster is that a solution necessarily being hacky is not a good reason to not implement a feature. And TBH the VLC example hardly even seems hacky. If you have a stream that can be seeked backwards in, then find the previous I-frame and internally run the video forward to the frame the user wants to see. That is exactly what the user is forced to do manually anyway. As far as it sounding like I'm boasting, all I can really do is assure you that was not the point. I was contrasting my experiences with how people tend to write about software development in blog posts and in comments on places like here. I do not think I'm better than them simply because I am ok with implementing hacky solutions where I think they make sense. But I am annoyed when useful features are denied because it would require a hacky solution. For FOSS, it's entirely within the devs rights to operate that way, but to me that's one way FOSS software can sometimes fall short of commercial software.
admdly 2y ago
Outside of those contributing to open source projects professionally, the vast majority of contributors will (naturally) be those with greater technical abilities, which unfortunately impacts the general UX of free/OSS overall in my opinion.
marcus_holmes 2y ago
Because it's an open-source project, not commercial software. In your job, you have to special-case some things because the alternative is not delivering what the boss wants. Regardless of the problems this may cause, or how much tech debt it generates - those are (in the end) business decisions, and while you can make a case to the boss that implementing the special case feature is going to cause huge problems, it's the boss's call as to whether it gets implemented. In an open-source project the maintainer is the boss. If the maintainer thinks that the feature is going to cause problems, they're totally free to say "no, I'm not going to implement that feature". And, ofc, because it's FOSS, the user is totally free to fork it, or submit a PR for the feature, or whatever. > just got here from a Google search. I gotta say the replies from Remi sound defensively toxic. I'm not here to program the app, I'm just here to find a simple feature and/or request it. I think Remi sounds curt rather than toxic. There's no automatic right for anyone to go to a FOSS project and request a feature and have it implemented. The maintainer is perfectly within their rights to just say "no". It's their project, their code, their time, and they're free to do/not do anything they like with it.
- somnic 2y ago
  If you say "no, we're not pursuing this feature because it's impossible" and users have used other software that implements the feature to a reasonable degree of functionality, you're not doing yourself any favours in terms of shutting down demands. You'd be better off either not giving a reason at all, or giving reasons that are clearer to people who aren't as knowledgable.
  - tuxone 2y ago
    Reasons are actually stated, they explained it is not feasible for the general case. Once the devs have made clear they don’t plan to do exceptions (as other softwares do) then users should accept it and move on instead of keep harassing volunteers.
    - account42 2y ago
      ... except VLC implements time-based seeking which has pretty much the same requirements and is consequently not possible with literally all files either. But both are possible with 99.99% of video files you will come accross. VLC developers are of course free to reject any feature request but if they do it by bullshitting their users (and that includes tacking on additional requirements that no user actually needs like perfect support for all formats under the sun) then they will be rightfully called out for it. Then throwing a tantrum and citing CoC violations is not going to improve things. It's their project so ultimately they get to choose to run it into the ground but this kind of behavior is not something I want to support as a user os I will stay away from VLC which includes not making helpful bug reports and not donating.

by ziml77 2y ago

jbverschoor 2y ago

And this is exactly the problem when these devs are in charge of creating systems that actually do matter. They will not support edge cases, problems in a process, etc.

vharish 2y ago
I mean.. can you show anyone piece of software or hardware or for that matter any man made creation that solves for all edge cases?
- jbverschoor 2y ago
  But it’s just simple things, like allowing an override of a status field. Or using a status field to check something is ok or not, instead of always checking the data itself. People make wrong assumptions, and requirements change. Don’t make it all rigid that you always need to implement every case
  - borski 2y ago
    Everything is a “simple thing” unless you’re the one implementing it. Things that seem simple on the surface rarely are, especially long-term.
    - jbverschoor 2y ago
      I’d say it has to do with not willing to duplicate data. On paper forms, it is simple. Why can’t it be in a digital form?
      - borski 2y ago
        https://www.quora.com/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3/answer/Michael-Wolfe https://www.quora.com/Why-are-software-development-task-esti...
        jbverschoor 2y ago
        That article means: inexperience and unprofessional. Sounds about right.
        borski 2y ago
        If you’ve never written software that needed to be used by tens of thousands or hundreds of thousands of people, then sure, it could seem that way.

zerkten 2y ago

When I was hired for my first real programming job, my future manager spent a lot of time asking me questions about how I deal with ambiguity. This stuck with me as a really important element to consider in people, but that doesn't seem universal, especially in tech circles.

vharish 2y ago

This is a very broad generalization and not a good one either. Particularly in this context. It's obviously not possible to do it for all video formats in a consistent way. I haven't read through all of it yet I could tell all the proposed solutions are hacky ones. Your scenario doesn't apply here. Businesses are different. This is on open source project. Anyone can work on it. What are you even saying about the choas of the world?! Every dev knows how work is. You are just describing every other software job. Somehow it sounds like you are boasting how matured you are just because you do what your client asks/needs. Even then, many business/software make a concious choice to support or not support something based on some guidance. The guidance could be some core principles or just some product managers whim. It's highly likely that VLC developers chose not to support the feature for the very reason(s) that's described in the post. It's a concious choice they made. I don't see anything wrong in that. They definitely are not some school kids with some daddy issues to hide behind some code. They clearly have answered all the questions from a technical stand point.

ziml77 2y ago
But the hacky solutions actually get done what people want the software to do. The point between me and the parent poster is that a solution necessarily being hacky is not a good reason to not implement a feature. And TBH the VLC example hardly even seems hacky. If you have a stream that can be seeked backwards in, then find the previous I-frame and internally run the video forward to the frame the user wants to see. That is exactly what the user is forced to do manually anyway. As far as it sounding like I'm boasting, all I can really do is assure you that was not the point. I was contrasting my experiences with how people tend to write about software development in blog posts and in comments on places like here. I do not think I'm better than them simply because I am ok with implementing hacky solutions where I think they make sense. But I am annoyed when useful features are denied because it would require a hacky solution. For FOSS, it's entirely within the devs rights to operate that way, but to me that's one way FOSS software can sometimes fall short of commercial software.

admdly 2y ago

Outside of those contributing to open source projects professionally, the vast majority of contributors will (naturally) be those with greater technical abilities, which unfortunately impacts the general UX of free/OSS overall in my opinion.

marcus_holmes 2y ago

Because it's an open-source project, not commercial software. In your job, you have to special-case some things because the alternative is not delivering what the boss wants. Regardless of the problems this may cause, or how much tech debt it generates - those are (in the end) business decisions, and while you can make a case to the boss that implementing the special case feature is going to cause huge problems, it's the boss's call as to whether it gets implemented. In an open-source project the maintainer is the boss. If the maintainer thinks that the feature is going to cause problems, they're totally free to say "no, I'm not going to implement that feature". And, ofc, because it's FOSS, the user is totally free to fork it, or submit a PR for the feature, or whatever. > just got here from a Google search. I gotta say the replies from Remi sound defensively toxic. I'm not here to program the app, I'm just here to find a simple feature and/or request it. I think Remi sounds curt rather than toxic. There's no automatic right for anyone to go to a FOSS project and request a feature and have it implemented. The maintainer is perfectly within their rights to just say "no". It's their project, their code, their time, and they're free to do/not do anything they like with it.

somnic 2y ago
If you say "no, we're not pursuing this feature because it's impossible" and users have used other software that implements the feature to a reasonable degree of functionality, you're not doing yourself any favours in terms of shutting down demands. You'd be better off either not giving a reason at all, or giving reasons that are clearer to people who aren't as knowledgable.
- tuxone 2y ago
  Reasons are actually stated, they explained it is not feasible for the general case. Once the devs have made clear they don’t plan to do exceptions (as other softwares do) then users should accept it and move on instead of keep harassing volunteers.
  - account42 2y ago
    ... except VLC implements time-based seeking which has pretty much the same requirements and is consequently not possible with literally all files either. But both are possible with 99.99% of video files you will come accross. VLC developers are of course free to reject any feature request but if they do it by bullshitting their users (and that includes tacking on additional requirements that no user actually needs like perfect support for all formats under the sun) then they will be rightfully called out for it. Then throwing a tantrum and citing CoC violations is not going to improve things. It's their project so ultimately they get to choose to run it into the ground but this kind of behavior is not something I want to support as a user os I will stay away from VLC which includes not making helpful bug reports and not donating.