I saw it in the kube reddit, got a chuckle, and figured I would share here. Guess I got a chuckle 6 years ago too! Can't remember how I found it last time.
Are features going to be de-prioritized in favour of hardening existing code? Or are employees expected to keep doing what they are doing just "with security in mind"?
The article makes it sound like the later. Which will be about as effective as "thoughts and prayers."
"Academia stopped teaching C++, moving to Java and then to Python."
There are a lot more practical and lucrative skills for a young programmer to focus on than C or C++. Many will be able to have good careers without going that low level.
What impact will that have on the economics of legacy C/C++ code bases in the 15-30 year time frame?
"I'm working with a second-party pre-compiled library and don't have a lot of wiggle room. After careful consideration (of both the library and my other job prospects), I want to do $DUMB_THING. Yes, I know it's dumb, but trust me, $SMART_THING is not an option. Unfortunately, $DUMB_THING is not well documented, because it's legitimately a bad idea, so I was hoping someone could fill in some gaps."
If you ever help someone in that situation, know that you are a hero among programmers.
I spent 3 hours last night digging into a Linux workstation issue along these lines. the solution was in a comment on a heavily downvoted SO answer.
the commenter was (unfortunately, inevitably) shat on by a large number of people but it saved me from giving up on tech to live in a cave the rest of my days.
all I could really do was comment with my thanks but that still felt wholly inadequate.
I'd say it's more akin to being dealt a bad hand and trying to work through a strategy to play it well.
Sure, you'd like to have been dealt a better hand. But you haven't, and dwelling on that won't help anyone.
The problem with this metaphor is that it's easy to describe the contents of a hand. But computer programs are a lot more complex than that, and sometimes it's non-trivial (and possibly NDA violating) to describe why the recommended solution isn't feasible.
> sometimes it's non-trivial (and possibly NDA violating) to describe why the recommended solution isn't feasible.
It's not just NDAs. A lot of times people are constrained in what they can do for a reason they're not inclined to admit. This is extremely common with office politics or any kind of corruption.
The boss demands X because Y would mean not getting kickbacks from a particular vendor, but she can't tell you this so she has to make up some hogwash. Now you have to go ask someone how to do X, and you know the boss's justification is ridiculous but you also know that you can't list "because the boss has issued a rattlebrained mandate" as the reason in a written communication with your name attached to it, so you have to submit the hogwash as the reason or make up your own.
Then the person answering the question points out that the proffered reason for doing it is absurd, which everybody already knows, but nobody can admit it.
In large organizations this kind of thing happens so often that people become conditioned to not even question it and just follow orders, and then it happens even when there isn't a hidden underlying reason, because there is now a culture of not questioning stupid decisions.
And even when you can explain your whole justification for doing Y, it often doesn't help. In my experience, longer your question is, the more likely it is that people will just skim over it and misunderstand it. Or they'll argue against your reasons for doing Y and try to convince you that you really should be doing X anyway.
If someone asks, "I've downloaded SUPER SQL EXPLORER PRO how do I connect to prod database so I can add a few columns", then you don't sit back and wait, you take actions fast, including contacting manager and revoking access if needed.
In a less extreme situations, you might have a shared task with quick deadline, and someone else went off to the woods instead of making a working design, increasing load on their teammates.
Not an expert, but as a learning experience I wrote a board game recommender years ago based on data from boardgamegeek.
There were a lot of little things that added up:
1. Everyone interprets the 1.0 - 10.0 rating scale differently.
2. Most users just rate the same, universally known games.
3. For the other users, the games they've played are usually really different. It's a sparse matrix.
Every attempt at game-to-game analysis flopped. User-to-user analysis seemed to work better.
I managed to find a few dozen similar users. Found some hidden gems by going through their pages manually. Fewer than I would have hoped though.
