As someone in the dev team for a “business app”, we probably know about most or all of them, but they’re just not important enough for anyone in management to prioritize them as part of a sprint. It’s also possible no one has given us reproducible steps to make them happen, so we just straight up don’t know what to fix. Usually the former though.
i will never forgive the emby team for creating the single most idiotic (although rather funny) transcoding system.
It has a resolution selection, along with a bitrate selection, so you would think it forces transcoding.
It turns out the resolution is actually just a suggestion, and the bitrate is what it targets, if it doesn’t meet the bitrate, it will transcode, and if you get lucky, it might transcode to the specified resolution.
I am steadfast that I will occasionally take some time and kill off some low hanging fruit. For me, its kind of like a break and lets me clear my head on the bigger issues.
The problem is that what users consider low hanging fruit is often not, and what is low hanging fruit for devs, is invisible stuff that users don’t notice. The intersection is the tastiest low hanging fruit, but as such it’s also rare and easily picked by anyone.
I never said that users were involved in this. This is just grabbing some bugs off the queue that are simple to fix but have been deprioritized by project manager.
But they do make the customer happy because they are the one that submitted the bug.
They usually do yes however it’s all about prioritization.
You may have hundreds or thousands or open requests and issues.
With tens of thousands of closed issues that were either not reproducible, not actually problems, or largely indecipherable.
There’s usually a feature roadmap which is where most of the development money and time is spent. If it’s an older business application then certain bugs might easily take weeks to find, fix, test, validate, go through user acceptance, A/B test, and then deploy. But fixing is expensive work, so if the bug isn’t severe it’s usually deprioritized next to higher priority work.
inb4 they wait until his last day then roll back the changes because functional code/unauthorized changes are against company policy and actually they need that bug to slow down the user so they don’t click so fast the database crashes.
NGL I apply to places where I use the software. But it’s not one thing, it’s a dozen things I would fix.
I actually never successfully got the job. Probably because during the interview, I come off like a rambling psychopath pointing out extremely specific things.
Part of my previous company’s hiring process included having the candidate use our software, then asking what they thought of the experience and what improvements they thought would have the most impact. It wasn’t entirely useful because devs weren’t in control of prioritizing changes, but it was always interesting to see which pain points stuck out to the candidate.
It does give some insight into how people think. Some people are bothered with UI events and placement, others wanted to reduce the bandwidth it required, we had one girl who approached it focused on the accessibility of the software, and unfortunately for us support was abysmal. You also need thick skin to invite random joe off the street to tell you how your software sucks.
Honestly, anybody with a gender studies degree can get into software developer nowadays no sweat, nowadays the fortune 500 standards are so low that they’ll just hire anyone on the spot without even questioning it. Honestly only started to take note of this the second Biden got into office, the quality of software overall has gone down. Overall, back to open source, I never truly got the open source movement in general, never been my thing. Proprietary software is inheitly more secure which is why most enterprise systems still use windows xp.
By not understanding how version control works. I’ve worked at places that had a surprising number of developers who would just merge things in ways that drop code from other developers.
I now work for a small business but in the interest of not getting bitten in the ass I don’t wish to give the name of my previous employer. It was a large defense contractor, but our values didn’t align so I moved on when I found another opportunity to put food on the table. I know that’s not a satisfying answer but I’m here for entertainment value and the opportunity cost might not be worth it. My main point was that even though they have the money they didn’t see the value in good software process.
All the time! We would leave bugs unfixed even if the fix was trivially easy because management felt productive listing it as a cost savings. Software maintenance was seen as a necessary evil.
Software maintenance was seen as a necessary evil.
The most important lesson I learned about the economics of software is that sourcecode is always accounted as a liability and not an asset. Accountants will never let you code your way into more value. Everything else you see stems from that truth.
lemmy.today
Hot