5 ms·

I wish I knew the answer to this, but I don’t. The closest I’ve come to succeeding at this is to have a reputation as a “breaker”. This really started in underg

I wish I knew the answer to this, but I don’t. The closest I’ve come to succeeding at this is to have a reputation as a “breaker”. This really started in undergrad algorithms; I wasn’t great at finding solutions, but I had a knack for finding edge cases to break solutions others had come up with. Sometimes it just needed a tweak to work, sometimes it was “throw it all away and start over”. For the few times I’ve done regular office-style work over the years, that’s come in handy. I feel like a dick a too, but I try to be really gentle and end up with people showing up on their own to “run something by me” before building it out. Saves everyone frustration! There have been colleagues though who do exactly what you’ve described. That brutally painful loop of breaking pieces of an overly complicated solution over and over. My unfortunate confession is that I usually end up giving up and let them fail on their own. I’m always willing to help, but if someone doesn’t want help, I won’t spend much energy forcing it on them.

korijn 8y ago
IMHO, Essentially you need to let them experience the issue you foresee first hand, by letting them fail. That way they can learn the same lessons you learned previously.
- deanmoriarty 8y ago
  In my experience, it doesn’t work that way at all. What happens is that the code will be released, some user will hit the bug in the field, and the issue will be escalated to the engineer, who will proceed to spend entire days or weeks to troubleshoot the problem, and then just put a dirty patch that fixes the specific issue, leaving all the other corner conditions still exposed and ready to explode. At that point, major redesign of the solution, which would have been possible at the code review phase, will just be deemed too risky by both the engineer and the management. On top of this, Management, usually ignorant to concepts such as “over engineered solution”, will praise the heroic effort of the engineer who spent days troubleshooting the issue, clueless of the fact that it was a completely self inflicted wound because the engineer decided that the best way to calculate 2+2 is to really do sqrt(2^4) and then realized that the user really wanted to do 3+3, so they’re going to put a special case to evaluate 3+3 as sqrt(3^3+3^2) rather than just doing the damn x+y. Nobody will even realize that the issue could have been completely prevented in the first place by adopting a solution that was much easier to reason with on the whiteboard, rather than a house of cards of custom logic. I’ve seen this script dozens of time.
- PhantomGremlin 8y ago
  That's a little easier to do for software, harder to do in the context of building hardware, which is what the book was about. Circa 1980, around the time of the events in the book, the time delays involved in making design changes to boards built from MSI building blocks were bad enough. Physical wire mods to a board took hours or days. New boards could be made in weeks or months. There was also some flexibility because parts of that design used PALs, which were easily reprogrammed. But in today's world the time cost of a re-spin of a CPU or a highly integrated SOC chip is huge. Months for simple changes, years for complete re-designs. Just look at the time estimates for hardware changes to x86 chips to mitigate Spectre and Meltdown. Some months for new microcode; many years for new silicon. Nevertheless, it's perhaps easier to let things happen and afterward think "I told you so". Because, unfortunately at most companies, if you try to impart those lessons earlier in the process, e.g. at design reviews, you quickly get the reputation of not being a "team player". Sounds crazy, but that's simple human nature.
- nradov 8y ago
  Only lazy, sloppy developers fail by repeating the same mistakes as others. Unless they're working on something truly novel (unlikely) there are books and articles out there which explain the problems to avoid.
bookofjoe 8y ago
Yes! Finally, a word — "breaker" — for my greatest talent, which I still haven't found a way to monetize in my 70 years and 8 months on the planet. I can unerringly and quickly find the FAIL point in most devices/methods/ideas/setups/systems/websites etc. in a savant-like fashion. Perhaps in the future I'll find someone who will pay me for my quirky skill.
- deleted 8y ago
  [deleted]
- ThrowawayR2 8y ago
  Software QA. Not particularly prestigious but the pay is passable, more so if you can code well enough to automate tests or dig into the codebase to isolate the bug.
  - bookofjoe 8y ago
    Alas, I cannot code at all.
- grkvlt 8y ago
  security related positions, such as application penetration testing, physical pen testing, etc. all require the "security mindset" which is essentially the skill of thinking adversarily and breaking things.
  - bookofjoe 8y ago
    I'm thinking no decent company is gonna hire a geezer like me for any job like this.

korijn 8y ago

IMHO, Essentially you need to let them experience the issue you foresee first hand, by letting them fail. That way they can learn the same lessons you learned previously.

deanmoriarty 8y ago
In my experience, it doesn’t work that way at all. What happens is that the code will be released, some user will hit the bug in the field, and the issue will be escalated to the engineer, who will proceed to spend entire days or weeks to troubleshoot the problem, and then just put a dirty patch that fixes the specific issue, leaving all the other corner conditions still exposed and ready to explode. At that point, major redesign of the solution, which would have been possible at the code review phase, will just be deemed too risky by both the engineer and the management. On top of this, Management, usually ignorant to concepts such as “over engineered solution”, will praise the heroic effort of the engineer who spent days troubleshooting the issue, clueless of the fact that it was a completely self inflicted wound because the engineer decided that the best way to calculate 2+2 is to really do sqrt(2^4) and then realized that the user really wanted to do 3+3, so they’re going to put a special case to evaluate 3+3 as sqrt(3^3+3^2) rather than just doing the damn x+y. Nobody will even realize that the issue could have been completely prevented in the first place by adopting a solution that was much easier to reason with on the whiteboard, rather than a house of cards of custom logic. I’ve seen this script dozens of time.
PhantomGremlin 8y ago
That's a little easier to do for software, harder to do in the context of building hardware, which is what the book was about. Circa 1980, around the time of the events in the book, the time delays involved in making design changes to boards built from MSI building blocks were bad enough. Physical wire mods to a board took hours or days. New boards could be made in weeks or months. There was also some flexibility because parts of that design used PALs, which were easily reprogrammed. But in today's world the time cost of a re-spin of a CPU or a highly integrated SOC chip is huge. Months for simple changes, years for complete re-designs. Just look at the time estimates for hardware changes to x86 chips to mitigate Spectre and Meltdown. Some months for new microcode; many years for new silicon. Nevertheless, it's perhaps easier to let things happen and afterward think "I told you so". Because, unfortunately at most companies, if you try to impart those lessons earlier in the process, e.g. at design reviews, you quickly get the reputation of not being a "team player". Sounds crazy, but that's simple human nature.
nradov 8y ago
Only lazy, sloppy developers fail by repeating the same mistakes as others. Unless they're working on something truly novel (unlikely) there are books and articles out there which explain the problems to avoid.

bookofjoe 8y ago

Yes! Finally, a word — "breaker" — for my greatest talent, which I still haven't found a way to monetize in my 70 years and 8 months on the planet. I can unerringly and quickly find the FAIL point in most devices/methods/ideas/setups/systems/websites etc. in a savant-like fashion. Perhaps in the future I'll find someone who will pay me for my quirky skill.

deleted 8y ago
[deleted]
ThrowawayR2 8y ago
Software QA. Not particularly prestigious but the pay is passable, more so if you can code well enough to automate tests or dig into the codebase to isolate the bug.
- bookofjoe 8y ago
  Alas, I cannot code at all.
grkvlt 8y ago
security related positions, such as application penetration testing, physical pen testing, etc. all require the "security mindset" which is essentially the skill of thinking adversarily and breaking things.
- bookofjoe 8y ago
  I'm thinking no decent company is gonna hire a geezer like me for any job like this.