Corollary - create fake problems then solve them.
Nobody ever gets credit for fixing problems that never happened (2001) [pdf]
211–220 of 446 posts
Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]
#212I've been contemplating the issue in the headline, as pertains to my value. When I help somebody in 40 mins with something they've been stuck on for 3 months, my value is clear to everyone. When I work there the whole time, and nobody ever gets stuck for 3 months, my value is unclear. Don't know how to deal with this paradox.
Easy - half a$$ your code and when it breaks - swoop in, "fix things" (actually do it right) and play the role of hero! (I've seen so-called "Rock Stars" at places I worked do this over and over)
Is it important that no one knows it was the Rock Star’s fault in the beginning?
Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]
#213Just responding to the title, but I think this is why it's important to have leadership with real "IC" experience. If leadership has an intuition for what's hard and what the failure modes are, they will be able to correctly divvy out acknowledgement more often than a "pure manager" type.
Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]
#214[dead]
Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]
#215SAP S4/HANA- the "new" ERP software is hardcoded to calculate depreciation until 2045. As programmers you probably know it could be untill year 9999 or much further.
But the consultants will not be out of work. Also a way to push customers to upgrade.
Artificial problem.
On a side note, I there is in my opinion a place for a new ERP disruptor. However making it is hard. Still even those small fish often manage to get money.
Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]
#216Earlier quoted context omitted.
Would you feel good about being that kind of engineer, if the external validation was great enough?
There are people with integrity and principles; and then there are people who can pay their rent every month.
I was kinda happy when my company replaced their previous feel good nonsense ‘principles’ with ‘do the right thing, even when nobody is looking’.
Of course it doesn’t change anything about the people that work there, but the people at the top now clearly have a better idea of how it works than the last ones :P
Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]
#217I tend to prefer working with people whose stuff "just works". I take that back. I strongly prefer working with them.
As a software engineer who pays more attention on security than average, I often feel my work didn't get recognized. For example, if I successfully prevented a supply chain attack, nobody would say thanks to me for a thing that didn't happen, even when they see a competitor product gets attacked. Similarly, most C/C++ programmers do not really care about integer overflow. But I know we are no longer in the world that…
I think you misunderstand what I mean by "just works". It means it doesn't have bugs in it. That includes security holes.
Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]
#218Earlier quoted context omitted.
I've done that as an hourly contractor, I fixed their 6 month problem on my first day, I hoped they would then hire me for more hours on other stuff but they were like nope, that was all we needed. They did tell some other companies that I was good at this kind of stuff but nothing came of it. My first and last day in contracting for small companies.
The trick is to do these sort of engagements as a fixed price contract. You could have probably done an assessment in a hour or two. Then you charge on what you estimate is the value to the company.
I should have, but it would have been obvious that I pulled a fast one on them as the fix was really quite simple. Instead of building a Hadoop cluster I replace a sql sub query with a bitmask. It really only took an hour to figure it out but they let me charge the whole day.
Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]
#219I tend to prefer working with people whose stuff "just works". I take that back. I strongly prefer working with them.
And people who comment their code. Even if it is just a little. I swear, 90% of my time in coding is just fiddling around with functions to see what they do so that I can actually pull them together in the right way. If there was just a little documentation this would greatly reduce my time. It should also be in every team's and company's best interest because people hours are expensive. It should also be in the best…
Documentation exists in one of these states:
1. incomplete
2. wrong
3. missing
My goal is to write code that is so clear it doesn't need documentation.
Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]
#220I've been contemplating the issue in the headline, as pertains to my value. When I help somebody in 40 mins with something they've been stuck on for 3 months, my value is clear to everyone. When I work there the whole time, and nobody ever gets stuck for 3 months, my value is unclear. Don't know how to deal with this paradox.
Play to your leadership. Exceptions apply, but female bosses tend to appreciate averted crises more than male ones.
If your boss is male, let shit fail. You'll get hero points for responding to incidents.
A female boss will quickly suspect incompetence if things keep breaking (i.e. see how far half-assed DIY home repairs get you with your wife before she loses patience with you). Your hero points will come from mitigation.
This paradox comes up a lot in security. IME in this particular field the gender stuff is less relevant since everyone is paranoid. But when we run stuff up to C-levels, it's only the female execs and lawyers that really stop to consider possible issues-- the men just dismiss everything until it happens.