Comment by runamuck
2 years ago
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)
2 years ago
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)
In high school I actually had a friend teach me this in a humorous way. In football we did sprints (the kind where you physically run) at the end. He said -- half ass the sprints. Then on the last sprint, run as fast as you can, you'll have more energy left, and when they see you running fastest you'll get all the credit. He was doing it as a joke, but lo and behold he out runs everyone on the last sprint by a lot, and the coach specifically pulls him aside as an example of how everyone else should carry themselves.
He's one of my favorite pranksters. But needless to say, the football team was not very good.
Nice example for the (common?) inability of many managers to assess performance realistically.
In the case of football that might actually be a good lesson: save enough energy for the end of the game so that you can play best when the other team is tired. Of course you need to play the whole game, but if you play all but the last 5 minutes working just hard enough to keep a tie game, then you can pull ahead in the end.
This only works in time limited sports though. Most real world situations are not time limited like that and so the advice doesn't apply.
On sprint training. Me and a friend figured out that if you moved your arms fast whilst not running a full sprint it gave the appearance that you were trying very hard and coach didn't give you a hard time. Like most slackers instead of using the trick once in a while we over did it and the coach soon figured it out. The result was even more sprints. Needless to say our team too wasn't too good.
That really only works if the other team is terrible relative to your own. ‘Playing to tie’ a team that is an even match (or close to an even match) results in a competitive advantage for their side.
This does work ok for long distance competitive running, since the factors at play are time and metabolic rate and is missing the strategy present in team based ball sports like football, soccer, basketball, etc.
There's a famous green text on 4chan, where a user tells he got a sysadmin job which was so boring he started crashing stuff left and right and blocking an entire office even for entire days.
By the end of the day he would plug back something and come out the "servers room" saying he fixed that and get everybody's praise. Even got him two raises in the span of 18 months.
That's how crazy it is.
I know a variation of this sort of story, where a good sysadmin/DevOps team was halved and then the problems started. The company didn't have those issues exactly because they had a good surplus of eyes to handle everything.
They realized only later the mistake.
I do not think you can trust everything you find on 4chan. Yes, dysfunctional companies exists. No, someone writing something on 4chan does not imply it ever happened.
Which is why I stated I've read about that on 4chan and not taken is as a truth.
That being I highly believe that stuff like this has and is happening right now.
I've worked in consultancy enough to know that many job's securities revolve around solving specific issues, and if the issues don't exist job security gets lower.
> No, someone writing something on 4chan does not imply it ever happened.
Neither does it imply that it never happened.
3 replies →
what about someone claiming it was written on 4chan, but it was actually made up for hn. smh can't trust anyone
Another option is to work at a consultancy where you hop aboard a new customer project every 3-6 months. Approach every customer as an opportunity to do some resume-driven development and pick a bunch of untested new technologies to experiment with. Be sure to do at least a couple of presentations to tell everyone about the hottest new things you are doing to bring value to the customers. Leave the project once it slowly starts sinking and then just keep hopping from customer to customer. You will be far away once the sea water starts coming through the windows and the non-technical people directing these projects will never figure out what you did.
I have seen that this is one of the most efficient ways to advance your career especially in larger consultancy companies with hundreds or thousands of different customers.
For maximum results, trade-off with a buddy:
Spend Q1 each crashing your respective project; spend Q2 as a fixer undoing that damage using his knowledge of his own work.
You’re both cutting edge and a proven fixer!
Reminds me of The Good, The Bad and The Ugly.
Tuco is a wanted man, Blondie brings him in and gets the reward money. Then just as Tuco is about to hang, Blondie shoots the rope and they both escape to another state ... where Tuco is also a wanted man.
Government contracting is the pathological case for that: if they haven’t been allowed to hire civil servants, they have no choice but to use a handful of big companies. The shortage of in-house expertise makes it hard to know if the work is being planned or performed correctly so a common strategy is to hire one company to oversee the work of another company. Unfortunately, since there are only a few companies in the space and job hopping is the best path for a raise or to avoid layoffs when contracts turn over, it’s rare for anyone to be very critical of past or future coworkers.
Don't do it right, double down on the flaws. You had a 3k SLOC single function (all in main) C program to do something that could be expressed cleanly and clearly in 200 SLOC. Some specific sequence of inputs leads to an error. Instead of tidying it up, removing the repetition that led to the mistake, you copy/paste everything again and add another 100 cases to your various switch/case statements (actually you use if/else because switch/case might make things clearer). The specific problem is solved, but in a year another buggy code path will be discovered and you'll have another chance to play hero. In 5 years it'll be 50k SLOC of C all in main, that could have been under 1k SLOC (still all in main). No one else will be able to fix it but you!
For extra points, keep the sane solution in a secret source file, then implement a compiler which generates the obfuscated spaghetti. :-P
I kind of did that once. For a proprietary language that didn't support functions and had very limited support for loops (mostly labels and gotos, it is sold for way too much per seat for a niche industry and the language and implementation are awful). I needed to implement something that was too tedious to write out by hand (~1500 lines of this nonsense) so I made a Python program that spit out the code I needed.
The company that makes it also has a generator they use when they're contracted to make more code in their awful language. It's bad, the code has to be manually cleaned up and sometimes is delivered broken. Then they get the money on the support contract to fix their problems. (It's not their only product/service, but it's key to many of their services, a way of hooking customers.)
Their generator did not using the looping constructs, and several of their "senior" engineers actively discouraged it because "You can't be sure a loop will do what you want it to do." (Wish that weren't an actual quote.)
4 replies →
and enjoy your participation to the ioccc :)
Ah, I see, the legacy RDBMS developer approach!
It is more easy: do your job right, but do not comment, fix or somehow improve work of your colleagues. Let them fail, aknowledge failure and only then come with fix, get all praise.
Never point to the possible issues at the code reviews, retirement refinements etc.
This, but seriously:
Let your junior colleagues fail on a schedule within the margin of error on your planning, but keep a close enough eye on them so you know how to bail it out if they can’t pull it together with a little extra time/guidance.
Okay — still give good code reviews, but if you let them face-plant a little on design, etc, then they get experience. And you don’t look dumb when it turns out they were right. But you do look like a hero when they’re struggling to get across the line, and you whisk in to fix it.
This is also just good practice in general. You learn through struggle, so giving juniors a safety net (when they don't know they have it), is a good way to get them up the curve.
That is naive take, you really think if you work hard on improving code, pointing out flaws, there will never be any issues?
In reality that I live, there is never enough time, if you have 3-4 team mates pumping features out, it is already impossible to prevent every problem and review every piece of code.
I don't have to be cynical about it, it just happens that issues will crop up over time and I am there to fix them and there is never enough time to prevent them up-front, because if you will try then you will never deliver anything. Ship fast and break things is maybe too far - but still shipping something beats not shipping ideal state.
We have a very good test suite, I don't think there's been a bad release in years.
1 reply →
I have seen so many people do this wherever I have worked. In fact there is another thing that they do i.e. when management pulls in the schedule they will meekly agree to it because they already know they are going to half-a$$ their code. Now they are heroes much before as they are "yes-men" and will be targeted for promotion. Swooping in to fix things just adds to their already loaded credentials.
The ones who are honest and actually disagree are banished and their lives are made difficult. They are called all sorts of names the most important being "not a team player".
This is exactly what happens at many software companies. People,sometimes under pressure to meet deadlines, apply totally crazy fixes to stop one problem and create new problems.
I’ve seen it both ways. In one case dev spends 3 days refactoring code beautifully to fix the bug; ships to production only to find out that it wasn’t the only bug in this code path. Now they spend another 2 days refactoring before repeating the process and so on. Meanwhile, the company is losing money/customers/favorite vanity metric/whatever.
Or. Dev hacks a fix up, sends to prod. Sees another bug and fixes immediately. No loss in revenue/customers/favorite vanity metric/whatever. Dev creates ticket to refactor/fix code properly and adds to next sprint. PM removes from next sprint to get capacity for further resume driven management projects. Issue crops up again due to hack. Original dev is now able to do ticket originally removed from sprint.
Definitely. Like so many other things it's the spirit and intent that matter.
Hah, that was in my archetypal description of the fake 10xer, that somehow they are able to swoop in and fix their spaghetti code, come what may, while no one else can make sense of it:
https://news.ycombinator.com/item?id=18462325
Having people thank me for being 'on top of' a problem that I already know about because I'm the one who pushed the button that broke it... It's gross. It feels gross.
Much happier when I can fix something quickly because I have some tools or logic in the codebase already that lets me do something quickly by being covered with sanity checks so I can zip along without driving us off a cliff.
There's some people who break something, realize it, just leave it as is, and cannot comprehend why you would think they should maybe help fix it... So I'd guess the praise is for not being like that.
I see what you're saying, but that still feels like a participation trophy to me.
Maybe I'm the only one who notices people whose work "just works". Those people are solid gold.
Well, if it "just works," then it wasn't that hard to do anyway. No raise for you.
Your comment got me irrationally mad, until I picked up sarcasm. Thanks.
I was just considering it, but never had a chance to see it in real life.
I'm dumbfounded about all this, you spend years learning and reading books about the craft but the only topic which will matter is how you can con the game ?.. weird.
That's literally how promo packs work in FAANG (minus the N) and other adjacent tech companies.
Nope.
I don't think you're wrong, but god what a waste of time. Can't we just fix the actual problem?
One middle ground I've found is to write tools or processes for myself or a mentee, with the intention to avoid avoidable problems. And then use the next time someone breaks things as an opportunity to advertise the preventative measure.
Frequently I end up having to do one more PR to get the tool to correct the exact problem the team experienced, so in practical terms is much less of a 'witholding' and more of a 'burning in' situation. But the final product does end up getting written in hours instead of days so while I don't get the credit I feel entitled to for foresight, I get mis-attributed with being able to solve difficult problems quickly.
Which is kinda true. I hate being caught flat footed so I'm always squirreling away fragments of a Plan C.
How?
I don't do this for one reason - I cannot hold others to a high bar if most of my code is half-assed.
I usually write my best code to show others it's possible to write good code and ship on time, with exceptions of course (and I usually document in code why its half assed)
Would you feel good about being that kind of engineer, if the external validation was great enough?
We review each other's code before it goes in. If the team says they're happy to work with it, then I've fulfilled my obligation. I am literally not paid to write the best code in the world. In fact, the company gives bonuses for fixing things, so they are in fact paying me to sneak bugs in.
What you do though is, you leave a very obscure edge case unhandled, make note of it, then just don't tell anyone. Invariably someone will hit it exactly one day before you're scheduled to go live. Then just apply the fix (make sure to procrastinate long enough to simulate working on it) and voila! The longest I've seen an edge case go unfixed in this manner has been three years.
Though truth be told I'm not smart enough to add bugs on purpose, I just sometimes notice I've failed to address an edge case and ... leave it. If it turns out to be important - I can fix it when the fix's value is maximum. Half my day is spent fixing others' unhandled edge cases, so it's nice to have one tucked away for a rainy day that you know you can fix easily.
How bizarre. I guess I can count myself lucky that I don't seem to live in that particular world.
Is the problem the incentive itself, eg. if they didn't reward fixed bugs would you write better (even just better communicated) code?
I can see how many would object to what you’re suggesting.
However, I’ve also had managers who pushed back against nice-to-have cleanups as the product matured (especially close to a release). They had cause as the product became overly complex, where issues were tedious to root cause and fix.
I tended to queue up a lot of improvements and then unleash them at the beginning of a release cycle.
Later QA would find a problem in the previous release but couldn’t reproduce in the later one… because I had already fixed it.
I didn’t introduce bugs intentionally, and the fixes were visible as we had to backport them for point releases, etc.
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
When the external validation is monetary then you gotta do what you gotta do.
It's OK, the new validation method is AI driven, we're good.
You mean money? Abso-fucking-lately I would do it.
Moral points don’t pay my mortgage.
This is a slippery slope, IMHO. It can easily get you to be the next "tactical tornado" of your team (cf. John Ousterhout, A Philosophy of Software Design).
don't even need to half a$$ it, just use timebombs.
https://en.wikipedia.org/wiki/Time_bomb_(software)
Usually only works if you're the only dev, unless you get creative with counters like the original devs that made some nice cash fixing it all for y2k
(officially: don't do this)
2038 is getting closer every year...
The AI will analyze your codebase next year and the company will sue you if you do stuff like that...
Is it important that no one knows it was the Rock Star’s fault in the beginning?
For i in employment ensure there is someone who checks in with me every month when they read this line of code, else, stop code from running so they come to me.