When BGP traffic is being sent from point A to point B, it can be rerouted through a point C. If you control point C, even for a few hours, you can theoretically collect vast amounts of intelligence that would be very useful for government entities.
Experience: I draw primarily from 14 years in product companies, focusing on the specific friction points where I've seen Leads struggle (or where I struggled myself).
Vetting: I stress-test the dialogue options with a network of Engineering Managers and Directors to ensure the 'winning' paths reflect reality, not just theory.
That said, unlike C++, management doesn't have a compiler to prove you are 'Correct.' It is subjective. The feedback in this thread is actually highlighting some edge cases I missed, which helps me refine the grading logic
My understanding is that home etching is probably still more practical and neither of those are going to match professional quality, but conductive filament and the "print everywhere except where the metal goes and then add metal" options should both be in reach of the upper end of the hobbyist sector.
If there's a legit, measurable performance or data integrity problem, start with that. If most of your production bugs come from a specific module or service, document it.
If it is only technical debt that is hard to understand or maintain, but otherwise works, you're going to have a tougher time of building a case unless you build a second, better version and show the differences. But you could collect other opinions and present that.
Ultimately you have to convince them to spend the time (aka money) on it and do it without making things worse and that is easiest to do with metrics instead of opinions
In my experience development has become too compartmentalized. This is why this game of telephone is so inefficient and frustrating just to implement basic features.
The rise of AI actually is also raising (from my observations) the engineer's role to be more of a product owner. I would highly suggest engineers learn basic UI/UX design principles and understand gherkin behavior scenarios as a way to outline or ideate features. It's not too hard to pick up if you've been a developer for awhile, but this is where we are headed.
If it's been around for a while, look at the last year's worth of projects and estimate the total delay caused by the specific piece of tech debt. Go through old Jira tickets etc. and figure out which ones were affected.
You don't need to be anywhere close to exact, it's just helpful to know whether it costs more like 5 hours a year or 5 weeks a year. Then you can prioritize tech debt along with other projects.
It takes guts to say “this 1 month feature would be done in a couple days by a competent competitor using modern technology and techniques”, and the legendary “I reimplemented it in <framework> over the weekend” is often not well received.
But - sometimes drastic measures and hurt feeling are needed to break out of a bad attractor. Just be sure you’re OK with leaving the company/org if your play does not succeed.
And know that as the OP describes, it’s a lot about politics. If you convince management that there is a problem, you have severely undermined your technical leadership. Game out how that could unfold! In a small company maybe you can be the new TL, but probably don’t try to unseat the founder/CTO. In a big company you are unlikely to overturn many layers above you of technical leadership.
This is why I incessantly preach to my coworkers: "you are not your job". Do not attach to it emotionally, it's not your child, it's a contraption to solve a puzzle. It should be easy and relieving to scrap it in favor of a better contraption, or of not having to solve the problem at all.
This is actually harder for more senior/managerial folks, as often they'll build/buy/create something that's big for their level and now they're committed to this particular approach, which can end up being a real problem, particularly in smaller orgs.
Once upon a time, I worked for a lead who got really frustrated with our codebase and decided to re-write it (over the weekends). This person shipped a POC pretty quickly, and got management buy-in but then it turned out that it would take a lot more work to make it work with everything else.
We persevered, and moved over the code (while still hitting the product requirements) over a two year period. As we were finishing the last part, it became apparent that the problem that we now needed to solve was a different one, and all that work turned out to be pointless.
There's very few people whose brains work like this, it requires constant maintenance and people are ready to fall into the trap easily because they are held accountable for the outcomes, and its easy to pretend your ideas would have saved you from the certain disaster your fellows brought you to.
Just like every league of legends game, it's not possibly your fault!
but it is their code. It's their achievement. It's their mark on the world that says they were needed and did something useful. They struggled and their passion gave them the strength to get through it.
It's how they get to be the experts that are needed.
Replacing their code IS replacing their expertise and therefore them. How would you expect words to change that?
(not my interpretation, it's what the post states - personally that is not what I think of when I read "Open Source")
reply