In about that same timeframe, Y2K is also really good example. Nothing of note really happened. But if people had just ignored it a lot of things probably would have.
"we were all worried about the ozone and nothing happened, this is just a repeat and people will stop talking about it any time now"
and my response is "'Nothing' happened because the governments acted fast and turned it around so now it's mostly just boring stuff like catching some factoryy that decides to go cheap and use banned chemicals to save a buck"
This is a very important case. There was an enormous investment in fixing Y2K, starting long before the day in question (e.g. financial instruments with expiration dates after Y2K had to be fixed before they became due), so on the day there was only a smattering of minor residual bugs.
There were a few jokes about it in the newspapers but by and large the public just ignored it.
I work on climate and hope / hoped that the same would happen, but it's looking like it will soon get everybody's attention regardless.
Y2K would negatively impact companies' bottom lines if not dealt with, directly, in a short and known timeline, in predictable ways.
Climate change will impact companies in different ways at different times. Oil companies, for instance, are incentivized to ramp up production as much as possible while also diversifying.
The way to get all companies to take appropriate actions is to not allow them to externalize costs. That means a significant carbon tax.
I'm sure I'm not the only one that can't wait for the 2038 problem to get closer. bank accounts gonna be jumping like a 3-peat Micheal Jordan when those consultation fee checks start rolling in.. provided the Boston Dynamics dogs haven't taken over yet
Since you "work on climate" I am sure it got your attention that there is a massive effort happening all across the board. R&D has made tremendous advances, whole industries are investing to get away from fossil fuels, and governments have ongoing programs to accelerate and support lange hydro, solar, and wind projects.
Some countries have not heard the call yet it seems (ones that like their role as perpetual victims and blame everyone else but themselves), but even just five years down the road, the world will already look very different for all the effort that's being made.
I didn't worry. Even took a trip to a different country. Though I can totally understand why some people (know you're joking) might have played it more conservatively.
Yeah. I've heard folk who should know better (looking at you, John C. Dvorak) call Y2K a nothingburger and suggest the effort to prevent problems was a total boondoggle.
Disclaimer: I was part of that effort. The funny thing was that I was brought back to a previous client to fix something that my previous efforts had literally caused. Took me 20 minutes to fix it once I saw what the problem was. And then there was a "while you're here, can you take a look at this ..." That lasted about two years until they closed the department and moved it to NY, NY.
In strategic sysadmin and cybersecurity this is staple thinking, and a
useful part of what I teach now.
Problem for vigilant thinkers is the rewards, as explained in TFA,
are perverse.
People are content with technology to be magical. They don't see the
millions of people quietly repairing it and planning to keep it all
going smoothly.
To "bosses" cybersecurity only bring them problems, and cost them
money apparently doing nothing. The same for any defence force, until
you need it.
Did some nice interviews for international sysadmin day last summer
[1].
Not "probably". I was involved at ground level fixing code for BP in '98. Can say without a doubt that bad things would have happened. And not because my salary depended on it - there was no shortage of opportunities to work on other things, obviously. It was legitimately an issue that would have crippled the energy industry (major players, and all their many, many dependents). I infer from this experience that the impact would have been the same on many other industries (e.g. finance, resource development) directly and indirectly.
But it is a great example. I still run into people who recall Y2K as an example of much ado about nothing. No, no!! It wasn't an issue for you because many people worked hard to prevent the problems.
Those problems were not terribly complex just pervasive and critical, requiring a high LOE. It wasn't like a huge moon-landing engineering problem to be held up as some accomplishment of humanity, more akin fixing a lot of dumb Challenger o-ring problems before a blow-up.
If only! Lots of things seem obvious, like common sense, but they apparently aren't because the behavior of many organizations is to reward the firefighters, to push "work harder" over "work smarter", and other behaviors that (in the long term) impede their ability to improve or expand their capabilities.
I liked the quote in the 2015 submission that twic posted [0], it relates back to the "seems obvious" sentiment. A lot of good solutions are simple (or composed of simple elements in a sane and reasonable fashion). But arriving at those solutions is decidedly not simple or obvious if we go by the Rube Goldberg machines that people end up contriving instead.
Another variation on the problem is the over-allocation of resources to preventing problems which actually happened once, versus those that are more severe but haven't happened yet.
This is a management problem, because no-one wants to be accountable for a repeat incident even if it was rational to be working on something else more important.
There's a ton of reactionary legislation on the books that exists pretty much entirely because politicians wanted to be seen doing something. It's mostly crap.
This is probably a bit too cynical; it's not just "politicians who want to be seen doing something"; the public often wants something done as well. And "we didn't do anything after that incident from ten years ago and now it happened again" is not a good look. Complex stories about trade-offs and the cure being worse than the disease often don't "play well" in the media, especially not with the opposition demanding that "something could have been done!" And corporations tend to be pathologically risk-averse.
Politicians, the media, corporations, and the public all have a part in this.
Sure, that's why the politicians want to be seen doing it. But the legislative focus is often on getting something passed now while it's a hot issue rather than on eventually getting a good bill passed (let alone deciding that we actually already have the correct amount of legislation on the topic).
A lot of gun legislation is like this. Whatever your view of guns is, there is no rationale for a "safe hand gun roster" like California's where the Glock 17 Gen 3 is on it, but the Gen 5 -- which introduces a basic safety improvement for left-handed people -- is not.
The thing is: it's very easy to play up the likelihood and severity of problems that are entirely imaginary. This can be just a bad habit, but also a deliberate tactic. In either case, a lot of effort, time, money, etc. is wasted.
Waiting for something to actually happen before allocating resources to preventing it is (to some degree) a rational policy.
The argument there is that waiting for "it" to happen would be way too late. Especially if "it" is a billion people are dead and the rest of the people don't have much time.
> Another variation on the problem is the over-allocation of resources to preventing problems which actually happened once, versus those that are more severe but haven't happened yet.
I've heard this called "institutional scarring" in a blog post somewhere. The idea is a small wound can be replaced with tough inflexible tissue. The jist of the blog post was that just because something happened, doesn't mean you have to change things to ensure it never happens again because that can be an over-reaction that really burdens your future. Accept that loss and that it just might happen again, but that may be better than onerously preventing it with certainty.
e.g., You were tasked with working on a ball of mud and it was miserable, so the next system you get the chance to build has to be the most scalable, modular, and cutting-edge thing ever, just to be safe.
Same thing constantly happens in governments, too. "Oh no, something that's been done for 200 years now caused issues once! We have to restrict/regulate/bureaucratize/outlaw it immadiately!"
This is basically how all bureaucracy comes about. In startups everything is so new that problems haven't had time to happen. In big tech, because they have a tremendous knowledge base of previous incidents and the resulting safeguards, every single step seems mired in bureaucracy.
I have worked in finance tech all my career, so I'm not sure how other orgs work, but this is extremely pertinent. Large investment banks react exactly like this.
I spent a miserable year trying to convince people that they were over-reacting to an outage and there was a very simple solution to the exact problem that occurred. But when senior managers see their jobs at risk because of a repeat, they'll mandate that the entire department review their code for similar issues and remediate. They'll also listen to the loudest voices who somehow come up with massively over-engineered solutions.
Another example, we had a password expire which caused an outage on our trading stack. The amount of effort that went into stupidly convoluted hand-crafted solutions ensuring this "didn't happen again" was laughable. And in the end, after more than a year of work, the whole thing was abandoned in favour of a much simpler centralised solution that should have been done from the start.
In our org, this was brought up. People who had problems, then fixed them, were the ones being seen and recognized by higher level management, and awarded for fixing the problems, when they, often, shouldn't have happened in the first place.
Now we have something akin to a "person that prevents problems" award. It's a nice gesture, but, even though I received one, I think it's mostly nonsense. You don't get the face time/experience presenting with the higher level managers. It's almost impossible to prove that you prevented catastrophes, by working extra hours, or doing the right thing. Nobody likes a "Hey look, I told you so!" sort of perspective, no matter how it's framed.
To me, this is the most gratification-limiting aspect of being a software engineer: time is required to test quality of foresight/design. Rewarding retroactively, for great past decisions, doesn't happen. There are systems I designed, when making a pittance for compensation, that's still being used a decade later, across multiple companies, almost entirely unmodified. That, now objectively, good work wasn't seen or recognized by anyone paying me at the time, and can't be seen by anyone now. I burned good time for a "good job me!" as a reward. As I get older, that mental masturbation seems less desirable, since it's usually at the expense of the surprisingly limited life credits that we spend on those tasks. But along with most other nerds, I can hardly stop myself because it's an innate obsession.
Reminds me that one time I found 17 databases in our org without backups configured. All I got was a thanks from some devops guy and no manager even heard of the problem...
Oh, maybe adversarial salaries. You each, meticulously, go through the others code, trying to find as many bugs as possible, in your spare time. Each bug you find transfers a percentage of their salary into yours. End result: everyone's code is perfect, and everyone hates each other. :D
This happens in organizations that don't measure and respect precursors or leading indicators of success/failure -- organizations that do not practice organizational observability, to coin a phrase. Which is to say, most of them, because this is not something one thinks of until one has suffered its absence. Your managers have to think like SREs, and be technically sophisticated enough to model and address this problem.
Does anyone know any great management books on this subject?
This is a great insight, the idea that management has to look at leading indicators for the org itself. Makes me think that beyond line management, a manger’s job is to behave as an investor and steward of the org, instead of getting involved in the details.
Not a management book per se, but Working Backwards popularised an Amazon approach of thinking about the organisation in terms of mechanisms. You might find that useful.
I’ve always wanted to dig into Scarlet Ink, Dave Anderson’s blog, but never have, and I suspect it’ll be quite useful for you too.
> This happens in organizations that don't measure and respect precursors or leading indicators of success/failure
This happens in organizations that become over reliant on metrics and indicators of success/failure instead of recognizing that these are fuzzy concepts and indicators are just that... indications, not answers.
The High Velocity Edge had a lot about this subject.
The most memorable example was at a hospital, nurses would occasionally pick up the wrong vial. They always noticed before injecting, but there were lots of close calls that didn’t get tracked anywhere. Once they started tracking that as a leading indicator, it became pretty obvious that the vials needed a better design to prevent even the possibility of grabbing the wrong one. Also, if the hospital never realized this problem and someone got hurt, they would’ve ended up with a much worse solution like “double check really close”
I'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)
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
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.
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.
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:
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!
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.)
> "You can't be sure a loop will do what you want it to do."
From my limited experience with "proprietary bullshit languages that only exist to hook customers", there's ways to mess up how loops work in the language. So maybe those senior engineers actually know what they're talking about.
I've seen "languages" that treat variables differently based on whether they have uppercase letters and underscores. Before I saw this in action, I believed the seniors telling me to "never use uppercase letters ever" were insane...
Given the cost of the product, I considered all documented features fair game to use. If a bug was found because of a primitive looping construct, then they were on the hook to fix it (there weren't any, they worked fine). One of those same senior devs also didn't know basic logic rules like De Morgan's Laws and tried to "correct" my conditional logic and broke the program instead.
Not MUMPS, that one actually has a standard. This is a straight up proprietary, maintained-by-one-company language. The concept isn't bad (that is, the objective of having a way to automate a formerly manual, and lengthy, set of processes), but the implementation is. Market capture, that's the name of the game for that company. They slip this into all their projects so even if they lose a follow-on contract they still get license fees for their proprietary components.
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.
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.
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.
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.
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 also don’t have bad releases but we had a new customer that added 100 users that used specific workflow that was working for years for other customers.
Those 100 users took performance to a crawl but we never seen it earlier because it was never used that way in that capacity.
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.
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.
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.
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.
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.
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.
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.
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.
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)
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.
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.
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).
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".
There is a quote about the job being free but you are just paying for the 20 years experience.
The opposite is the lemons market. It is why getting some wet building work done that is actually waterproof is a fucking dark art. Even the pros hiring pros get fucked because the “is waterproof” part is invisible.
Life and its rewards aren't perfect. Work with honest, intelligent people; genuinely do your best; your days will be much better and the odds will be with you.
This is a great answer. The only thing I would add is that you can take mental note when you accomplish something that anticipates and preempts future needs and challenges. It is ok to make brief mention of these things from time to time when appropriate. If nothing more it helps coworkers and bosses realize that you are putting in some thought and effort for the needs of others and to make things go more smoothly behind the scenes.
Doing this effectively requires tact. Try to mostly bring up your silent efforts casually, and be judicious about how often and in what situation you mention it. If it gets interpreted as an "I told you so," an excuse, self-importance, etc, then it will probably do more harm than good in terms of your standing with others.
Might be helpful to some degree. But won't save you if your organization's culture simply doesn't value your work or more generally doesn't care about proactive, methodical improvements that have no flash or immediate payoff.
Great approach!
For the past 2 years I keep experimenting with different ways to track day to day productivity. It has helped me tremendously in assessing how I should feel at the end of the day about my work day and the amount of time I put towards work. (I tend to overwork myself significantly). It is of course a lot harder to apply this approach to individual productivity tracking across my teams. But I do now believe, based on self experiments and within smaller teams, that there is generally a lack of visibility of knowledge worker productivity. Especially within larger companies. WFH and hybrid makes this more crucial to have for both management and self assessments on the IC level.
It also really depends on your organization and how they quantify and reward impact. There are ways to get credit for preventing issues. Establish the baseline level of quality, broadly create classes of issue, define a plan to solve that class of issue and measure your impact relative to your goals at the end.
At a big company you should be able to turn that into a number - 'this kind of issue was costing us $X/quarter, and thanks to my work, it is now costing us $(X-N)/quarter, in line with my estimates.'
It's performance season so I've been giving a lot of thought to how you quantify and attribute impact especially for folks in lower-visibility roles.
Not every company is going to see it this way but that's kind of a truism. Not every company sees any one kind of impact the same way, and you have to think about that relative to your career goals. I think aligning with your manager at the start, quantifying your impact and showing your results is going to get you the recognition you deserve at any company worth working at.
Intelligent people are in larger orgs too. They learn very quickly that promotions aren't tied to effort and anticipating problems or resolving future problems.
The intelligent, optimistic and genuinely good, helpful people who don't learn this (or refuse to compromise their good nature) end up burning out, getting performance managed or with PTSD
Right, don't work in that org. Find the org with more of the intelligent, optimistic and genuinely good, helpful people.
Some people don't want to give up the job at High Status High Pay Corp. That's the trade-off they are choosing. (Not every HSHP Corp. has to be a bad place to work, however.)
You can have intelligent people in the largest orgs, if they are good at hiring.
You can have inexperienced people in small teams or companies, and it happens often.
This kind jaded, reductive answer reeks of sour grapes. I've seen so many adopt a transactional mentality as a sort of defense mechanism against the indifference of the universe, and in the process they unintentionally blind themselves to numerous daily examples of people just trying to do the right thing. Sure the world has problems, but if we can't see both the good and the bad then we become embittered and small, hateful to ourselves and those around us.
On the same note, it's so discouraging when someone who is not/neither takes over, those people leave (one way or another), and you have to start the search again.
Or when someone is intelligent enough you don't figure out they're not honest until it's too late. <shiver>
Anyone who's been around the block a time or two will accumulate those experiences. I hope I've not been jaded by mine.
(Otherwise known as pathological lies). To do as the saying says, and "know thyself" is difficult. People are prone to be overly harsh or generous when evaluating themselves.
This is good advice that’s well intentioned, but (sorry), it can be interpreted as elitist, and in a way that’s detrimental to the reader.
I am no way suggesting that this is the intention or belief of the parent, but while I’ve got more miles on my odometer than I’d prefer, they’ve informed me that “reasonable” is better than “intelligent.”
My god how I’ve found that working with reasonable people is so much healthier, more productive and rewarding than working with the unreasonable* intelligent folks.
*I fully grant to my current and former colleagues, friends and associates that I have been irredeemably unreasonable any number of times. Consider this a small thanks :).
Totally get where you're coming from, but it's also kinda splitting hairs.
Being reasonable is part of being intelligent. Surrounding yourself with intelligent people doesn't necessarily mean "surround yourself with the highest IQ individuals you can find." (not saying you're saying that explicitly, just that i think you're just using a definition of intelligence that's narrower than the parent) Working well with others, understanding when one has made mistakes and being able to admit to it, understanding both the known unknowns and the unknown unknowns of a problem...these are a better mark of intelligence than a mensa membership.
Well the parent made sort of a case for why being reasonable is part of being intelligent, and your response was to claim there was no correlation without an argument.
I happen to believe that reasonableness is part of being intelligent, by the following criteria:
1. when you are reasonable you do not make unreasonable demands that will just be troublesome and cause workflow issues because in the end they are unachievable.
2. a reasonable person will be able to determine what other people are capable of in given situations, and be able to structure things in such a way that other people can perform to best meet expectations.
3. the root of reasonable is reason, a reasonable person can be reasoned with because they possess the quality of reason, in most of the history of philosophy if you do not possess the ability to reason you are an idiot.
Alright, my argument is that parent needed to redefine what those words mean. Intelligent means having high intelligences, high IQ. That does not imply being reasonable or having emotional control. It does not imply ability to shut up when you do not know what you are talking about either.
Moreover, being able to admit mistakes (specific thing mentioned by parent) is oftentimes detrimental for you. People who do not admit them are typically rewarded, people who easily admit them punished. So, what you are looking at is "ethics even if it does not benefits me".
Having worked closely with some dramatically different intelligent people, I really think intelligence and reasonableness are very different.
Being reasonable, is being someone with a strong genuine value for collaboration. They actively advocate for and work with others to optimize situations taking everyone's needs into account. Encourage give and take, constructive debates, and appreciate feedback. Etc.
An intelligent person can be all those things. Or none of them - but manifest them enough that, with some spin, they seem reasonable, while actually optimizing the environment primarily for their own long term benefit.
Very intelligent unreasonable people are disasters to work with.
As the GP, yes good point about reasonableness. I didn't word it well: I meant people who act intelligently; intelligence by itself certainly doesn't yield that!
> it can be interpreted as elitist
If "intelligent" is taken as 'naturally superior intelligence', then I can see what you mean (and I think that idea is a egomaniacal delusion). What I mean is people who choose to act intelligently; that's quite democratic.
I know OP already responded but people who are smart, kind, and are down to earth are special. You have to keep them close, and it’s pure bliss if you find a company filled with them.
It’s life goals to be smart, kind, and down to earth. It really
comes from a LOT of experience though.
> This is good advice that’s well intentioned, but (sorry), it can be interpreted as elitist, and in a way that’s detrimental to the reader.
There's nothing wrong with elitism as long as it leads to initiation rather than gatekeeping.
> My god how I’ve found that working with reasonable people is so much healthier.
Could not agree more. Most people can be trained well to do any job required of them. What cannot be trained, and certainly at the behest of the employer is interpersonal skills.
The one situation where I would prefer someone who is intelligent at the expense of being personable is if I intended to hire 2-3 absolute weapons to be the core of a startup.
> What cannot be trained, and certainly at the behest of the employer is interpersonal skills.
I think that those can be trained as well. The fact is that just acknowledging the issue requires a level of self-awareness that not everyone has, and training THAT as well requires being aware of it. External input and help from a specialist or a dear friend can get the ball rolling.
> Most people can be trained well to do any job required of them.
I really wish this were true, but especially in programming I don’t think this is the case.
I’ve spent years as a programming teacher. Some of my students have been among the most wonderful, enthusiastic, hard working students you can find. And yet, despite both of us working hard for a year or more, some never develop any talent whatsoever for programming. Statements like “everyone can code” can easily turn into a rod for their backs. - “Therefore if I’m not succeeding like many of the other students, it must be because I’m not trying hard enough, or there’s something wrong with me”. I don’t think this is anyone’s fault. Perpetuating the lie that all our brains have an equal capacity to program is a terribly cruel injustice. Some students would be much better served by finding another career that they can excel at. The faster they figure this out, the better.
Programming isn’t for everyone. It’s hard. Not everyone has the same capacity for it. I believe accepting that is an act of kindness.
> I really wish this were true, but especially in programming I don’t think this is the case.
I should have made my prior assumptions clear. The "most people" I'm referring to are CS graduates or people with IT diplomas and the percentage among those who are trainable to a capacity of competence in most companies are roughly 70%.
> Perpetuating the lie that all our brains have an equal capacity to program is a terribly cruel injustice. Some students would be much better served by finding another career that they can excel at.
When I was still a uni student I used to be a CS tutor in a help desk setting and I especially remember one guy who used to come in a lot. He had a really great attitude despite being humbled by the fundamentals. He used to repeat to me: "Sometimes you have to ask for help when you need it." After that semester I didn't see him again. I also remember a particularly annoying guy who used to come in and waste my time and the other tutor's by bringing in a problem and then solving it himself within seconds of sitting down just so he could talk about how he solved it and how much he knew. The world is not a fair place.
Yep. Those two stories are in some amount of conflict. I agree that anyone who has passed a decent hiring bar can be trained to some baseline level of competence. But the difference in capacity between that baseline level and someone brilliant can be huge. And it matters. This is the difference between something being an ongoing issue for the team for months, and it just quietly never seeming like it was ever a problem in the first place. As you say, it’s totally unfair.
People known for being purely highly reasonable people know that they don't know everything and aren't afraid to learn and be humble and are often a net positive.
People known for being purely highly intelligent people often think they know it all and are often a net drain.
I think [reasonable] falls under the heading of [honest].
Both honesty/reasonableness and intelligence are required. A family memebr is tearing her hair out about having to work with some assistants who are honest, well-intentioned, and pleasant, but who are just mentally incapable of keeping things straight — they literally screw things up and make more disorganization than they fix (fortunately, better help is supposedly on the way).
Overall, in hiring and working with people, most of the time, a warm body is definitely NOT better than nobody.
Maybe. But still it is in the spirit of the parent post "Life and its rewards aren't perfect".
If you start micro-optimizing - especially on other people, whose behaviour you can rarely change. It may leave you with lots of frustration and completely missing the grand picture.
Sorry to hear this! At the risk of repeating what others in your life may have told you, have you considered working for a new team/company? I find it of utmost importance to find a job/career that is intrinsically fulfilling and rewarding to you. Extrinsic rewards like money are great, but you can only slog for so long for only money before you burn out.
I've personally been fortunate to have been able to form a network of a bunch of different well-connected folks so I can always choose who I get to work with in the event that companies shut down or get acquired or such and such. I feel the value of such a network does not get touted often enough.
Not everyone has that option, as you say. My career was in a similar dead-end situation at one point; there was no immediate solution - nothing was going to make tomorrow or next month better than today.
Finally, I accepted the solution was long-term. I made a long-term plan - to do what I really loved - and focused my attention on that, and slowly built up the resources, skills, etc. for that plan. One wonderful side effect was that the dead-end part diminished in my mind; sure, I still had to do it, it still sucked and there were some awful days, but it would pass. I didn't matter so much; those people didn't matter; it was like one of those movies where the kid knows that someday they will leave the depressing, dead-end town they are stuck in today.
I hope that helps a little in your situation! Good luck!
I'm going to add: in a place where they have the bandwidth to be honest and intelligent. Sometimes good people are in bad situations. It's important to recognize this.
Another perspective: if you are not in a position to change the rules of the game, understand the rules of the game and play that game, not another one that you would like to play or that you think is more fair to play. Alternatively, if it is not the game you want to play, find a place where that game, or a similar one, is played.
Think that it is the management's fault if they misjudge you. They have the chance to judge you correctly, yet they misjudge you. Their fault entirely.
1.) Create a spreadsheet with all of the features of your group's/company's products(s) listed in rows.
2.) Create a column for every team member in the group and highlight the lead developers for each feature.
3.) Then ask each team member to add a checkmark in their column for every feature for which they would be willing to be on hook for 24x7 triage pager duty.
Over the long term - the most valuable contributor(s) on the team will be the one(s) with the most checkmarks next to the features they led development on (i.e. they write understandable code and document well) combined with the most checkmarked rows in their column (i.e. they proactively seek to understand other peoples codebases).
> Couldn't there then be a risk that now some people want to avoid higher risk projects, and just build the simpler features, and get more checkmarks
This is kinda a well known phenomena in medicine[0]. Same with lawyers. I'm just reminded of this scene from Silicon Valley[1]. It's messed up and why everyone needs to be very careful with metrics and remember that metrics are only guides, not targets.
Agree that there is probably room for improvement to such a process and still a great amount of subjectivity required and a presumption of good faith participants who aren't actively gaming the numbers.
In general though even if some developers are gravitating to only projects that are simple/trivial, those wouldn't necessarily be differentiators because such projects would have checkmarks by other developers as well.
Also it can help to have the Product Management team rank the features in terms of strategic importance and criticality to the functioning of the company.
I'd say the biggest benefit of such a spreadsheet is to provide visibility to leadership about the bus factor of the team. Too often the critical projects are really only maintained by a few team members. There's no incentive for new team members to learn the "legacy" projects versus creating their own pet projec. Then the inevitable RIF or transition happens and the lack of long term support becomes an issue.
Kind of ignores the risk externalities have on projects no? If you tried your best to deliver something, but another teams priorities changed, or the business/market shifted, or the project got bogged down in planning/politics outside of that team members control, or if the team needs to integrate with a system (external or legacy) that’s out of their control and is notoriously flaky and torpedoes their velocity and morale.
Really good bosses make up for this. They push teamwork and collaboration, but at the same time they know the details of what every individual is doing and how they each contribute to the whole, and they can ~accurately compensate/promote/terminate. This prevents demoralization of team members. Team members psychologically need to be recognized for their individual contribution.
These bosses tend to be competent ICs who became team leads, they are best positioned to judge the ICs they manage because they themselves are masters at the craft.
Modern “agile” systems don’t work well with you. They want you to deliver X points of features in 2 weeks. Sounds like you’d be better off as a consultant? But then you need to do all that biz dev stuff! Or find a great CTO to work for (or be the CTO) who understands. You only need one job.
In the end people ended up simply inflating the value of stories.
In my previous team I had to argue with a person that 2 story points to add translation keys were ridiculous.
To which the EM argued that 2 was okay because he also needed to write few accompanying tests.
I have nightmares thinking about this stuff. It was literally quicker to add the translation keys and that pointless test than to even discuss and vote the story and debate the points..
Company has a goal for 5% increased velocity, what they want: teams get more efficient at pushing stories through to completion, what they get: teams just estimate 5% higher.
And large companies will probably never learn, because at some critical mass it becomes less important to ship than it does to tell people how cool the product you want to ship is. Devs don't get paid for shipping outside of a short surge of stocks (which they proceed to not be able to take advantadge of because potential insider trading). Heck, some industries just let you go after you ship.
I think an underrated way to deal with this phenomenon is proper self-marketing. Talk endlessly what you have done to prevent catastrophe. Describe the avoided catastrophes vividly so that people get a clear picture.
Sometimes you can't quantify actual avoided things. For example you can't prove that a regulation stove actually prevented what could have been a kitchen fire.
The caveat to this is to make sure hope doesn't turn into expectation. Expectation can turn into sourness when the others don't reciprocate. Also, some people feel when you do something just because you expect something in exchange, and that tends to make them not reciprocate.
Work for yourself. The fewer bugs you create, the faster you iterate. And the faster you iterate, the better your chances of finding product/market fit.
Even spending 5% of your time self marketing has massive dividends on your career vs spending 0% of your time. The virtues of your skills aren't self evident.
True. But when you're a smart kid and you get auto-noticed in school with no effort on your own part (aside from the academic effort!), maybe it's time to add a course like "Creating Your Own P.R... And Believing It Too" into the curriculum.
That's true, but everyone has to learn at some point.
There's only a limited amount of attention in the world. Even the smartest are subject to the laws of human whims. The purpose of school and most vocational systems is to best advertise and direct the skills of those with the most potential to where their skills are suited best. However individual firms have their own needs and agendas, and often suffer from failures of pure meritocracy that their success allows them to go on without.
Value is in the eye of the beholder is what I discover. Got to play the game.
If you are an IC, you play it up with the right people. Those right people fight for you instead of the other way around. When the “we need to cut the fat” talks come around, suddenly you are not on the chopping block. But that also assumes the people fighting for you are not on the chopping block.
Soft skills across the industry is highly under valued. Knowing when to pick a fight or hold your tongue is also important (ie, reading the room).
I hate it but you got to do what you got to do to get that cheddar
Or worse: People get stuck quite frequently and ask you for help pretty quickly. You get everyone unstuck, but your own work falls behind and when your boss's boss asks for metrics on developers you have few points delivered and few LOC changed. Your boss tries to explain, but your head is the one that rolls next when layoffs happen.
which is why one should not self-sacrifice. It garners no reward for one. Secondly, if the boss doesn't realize how much of an enabler you are, then it's time to start looking for a new job before the layoffs even starts as a thought in the boss' head.
Well at some point you expect some artifacts to show up, even if not just code, design docs, RFCs, code reviews, something. If there truly is nothing I don't think that's a viable way to contribute either. Sure one can "only help others" but all good engineers I've worked with can help others and still do their main tasks, and if they get to a point where they are a point of reference for everyone else and everyone else gets blocked without them this is a high priority thing to fix in the team, probably one of the highest priority things to fix.
I've seen management let bad engineers re-do projects from scratch 2 or 3 times. Because they blame bad requirements, poor choice of programming language, and whatever on all the issues that the project has.
They eventually acquire enough experience to be able to produce something that sort-of works around the 3rd attempt.
But thanks to how good they are at communicating, are considered by management to be good engineers.
While doing a working project at the 1st try, without using this week's new framework and so on isn't as valued.
I mean at some point we just get generic enough that we have to agree on the ultimate fact that at least somewhere in the management chain someone has to actually know enough engineering to recognize good work from just running around in circles. I agree what you say happens but if good work isn't consistently recognized and you think you've worked on your comms, there's not much else to do really.
> at least somewhere in the management chain someone has to actually know enough engineering to recognize good work from just running around in circles
Unfortunately, this can cut the other way as well where you can have someone incompetent override competence or not even involved people further down which is common during large layoffs
Incompetent CTO can promote incompetent developers to be leads, so now all of the projects from that team will be done terribly. But the CTO can't go back on his decision because he'd rather waste years before getting a result that works acceptably rather than show that he made a mistake.
As a senior engineer I've learned that is my job. I take on much less work than anyone else because I know I will be called on to solve those problems.
This is in fact known in management literature: assign your best people to the least important project. That way the second best can grow to become the best, while the best are always free to help out if your fourth most important project has issues - it isn't a big deal if your least important project doesn't get done on time and if they manage to finish it so much the better. (your best are also free should sales discover a short window where a quick feature can bring in a large sale - though this is obviously easy to abuse)
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.
It was $200 an hour for a total of 8 hours. They had a team of 5 working for six months on it and they planed to spend another six months on it.
The UI had options to check some categories and exclude others, this was mapped to sql with a nested query IN (…) and not in (…). I noticed that there were less than 64 categories and always will be so I figured pack the category membership into a 64bit ints and use bitwise operations. The UI query generation would map to use bitmasks instead. They didn’t even let me implement it, just agreed that it would work and took it from there. I think they were quite embarrassed by it. It ended up being 10K faster.
>but it would have been obvious that I pulled a fast one on them as the fix was really quite simple.
If they were ready to have you on for 6 months, You'd still probably be one of the most honest contractors if you stretched that out to a week, or even month. It's a shame honestly isn't always rewarded proportionately to suggesting an entire rework of their infrastructure.
Ok, it doesn't sound that bad to me? You learned something about consulting, got paid 1600$ for one hour work, got good recommendations and now have time for another interesting opportunity.
Don't waste your time and clients money on pretending to do work that you don't. Its ethically wrong (maybe even criminal) and it sounds like you would be bored to death wasting your talent.
Don't blame the company for not wasting its money either. It did pay for the whole day and gave you good recommendations.
You could do fixed price. Or split the difference (on both sides of the estimate), which provides good incentives for both parties.
The problem is it takes typically takes days or even weeks of unpaid work to find the next paid job. If you get 6 months contracts that unpaid time is easy to deal with (and much of the unpaid work is really half an hour here easy to put in after hours while in the middle of the longer contract). Thus a 1 day job needs to pay a lot more perhour than a 6 month contract as the costs to get that contract needs to be paid from than 1 day - a fair price for a 1 day job is likely in the $20,000 range.
It took 3 months to get this first contract, I was trying to break into a new space. Shortly afterwards the government gave many millions of grants to all my potential customers in the country to spend on consulting with a brand new company that was spun out of the government so the entire potential market dried up overnight. The customers didn’t care it was free money. This spinout then tried to hire me where they correctly pointed out that there is now no alternative to working with them and gave me a low ball offer. I left the country instead.
Even with this I would argue that fixed cost would have been the way to go. They were losing $X every day for that six months that it wasn't working. They hired you to fix it, and even if you charge them way more than your day rate you're not solely charging them for the change - you're charging them for "knowing which screw to turn".
The hardest part of getting into contracting was the guilt of feeling "I'm charging too much for a simple fix!". If the fix was so simple and the client didn't find it in those six months then maybe your assumption that the fix was simple and obvious was incorrect. Regardless, your fix provided value, and you should be compensated for the value that you provided, not just the number of hours worked.
Me neither. And I've had a similar issue with the first case. You do your work and help someone finish theirs, people still think you only did you job (even if people do credit you, you still have normal impact).
The psychology of workplace is quite subtle and almost backward. There's a motto "squeaky wheel gets the grease" .. to the point I'm thinking of trying some games. Like designers who produce crappy options and one good to toy with higher ups thinking they decide. There are some ideas in that vein so you flip the relationship and benefit from it instead of bleeding.
It's mostly a question of finding organizations that recognize and value that sort of contribution. It also helps if you track who you work with and what you help out on every day, so when review time comes along you can list not only your 'regular job' wins, but all the wins you helped teammates get.
If your solutions tend to be more stable from the get-go, it will get noticed at most places. There are always going to be that odd company where that's not true, but in my experience, simply doing higher quality work gets appreciated.
Well it's not 'clear' when every promotional process I've encountered doesn't reward such forward-thinking preventative maintenance compared to someone who postures themselves as a hero going around putting out manufactured fires.
Unfortunately one of the best ways is to toot your own horn. If you work with good folks, it will be appreciated for you to present a tricky problem you solved, or to present a design you put forth that would save everyone time.
Think of it this way: when a principal engineer is hired from outside the company, what is the forecasted value of that engineer? How was that determined, since they have yet to do anything? If Andrej Karpathy joined your AI startup, people won't say this person has unclear value. It's because of the impact they've had previously and what other people have to say about that person. Value is your reputation.
Good leaders. Or, worse: Consultants. That is, it takes either an outsider or a self-critical leader to affect change? Those doing the planning are always optimistic [0] about their decisions, processes, evaluations, and progress. https://en.wikipedia.org/wiki/Planning_fallacy
My anecdata is to be vocal about your works, like having short knowledge sharing sessions to show it to your team/manager. Don’t be afraid of little things, your team would learn something from it.
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.
I think there’s a “this is life” aspect and a “this organization is immature aspect”.
A mature organization respects the process that prevents getting stuck for 3 months. But… they may be more stable and less nimble. Boring orgs don’t like heroes.
The problem may be in the relative value contribution. A senior eng that rights a project on 3 days which had been going on for 6 months is incredibly high value/he work.
A Sr eng who spends 6 months coaching a junior engineer has much lower value/hour.
Presumably that's not -all- you do? Or did you sit around for 3 months going quietly mad waiting?
Assuming you are doing other things make sure that is visible.
Also why did your colleague wait 3 months to ask you for help? A couple days would be OK, a month would be crazy. You should poll them and not wait for an interrupt.
Security/insurance paradox: when you do some jobs perfectly, it feels like you're doing nothing. Sadly, the only (ethical) way to counter such narrative is to spend a good amount of your time making reports showing how well everything is working and how it's not something you can just operate autonomously without disaster (to answer the inevitable "well the job is done, what are we paying you for?)
An adjacent problem is how to know that you've really prevented issues/others from getting stuck with whatever you were working on. No system is perfect and engineering is also an art of knowing when to skip which corners. If nobody sees value in your preventive work then maybe there isn't any?
Other problem on similar spectrum, when you have a good performance and your boss notice you, their expectations can increase and increase until you unable to deliver, then suddenly you're bad.
I went on holiday for 2 weeks. Came back to find the team had spent a week on a 5 minute task that had been clearly documented. Nothing had moved forward. Spoke to my manager that day and from that day forward it was clear what my value was. Eventually lead the team and helped the team develop processes and initiative so they could be productive in my absence.
Up until that point I knew my value but I don’t think anyone else quite got it.
At least you're likely not a person who works at a freelance agency where you purposefully do poor work or break things, so then you can bill more time "fixing" the problem - until the client gets the wiser at least, or there's another more oblivious client you can grift much more easily who doesn't know better?
The above seems to be how the top billing agencies on Upwork function, with fewer staff you can grift more people because the hours being billed aren't honest, and so you can have more clients and reach the "top" earnings position faster and more easily; with the same practices existing at least on one of the two prior platforms before oDesk and Elance merged.
If they don't pay you to fix those problems then don't fix those problems until they start paying you for it. You'll have to deal with the psychological torture of watching things go horribly wrong. So it's up to you how to deal with it.
Don't help anyone too much until a manager asks you to help. If someone is really pressing help, tell them that you are busy, but they can ask the manager to tell me to help. This way, you always get maximum credit. Every single manager that I have worked for claimed they were "different" and did not suffer from it. Usually, I give them many chances to see my value. After I am overlooked too many times, I revert to this selfish mode explained previously. In all such cases, my recognition from the manager improves. Sigh.
I don't know about that, you might want to receive some help yourself right? In some cases it might be better to work at a place that values cooperation more than competition. You sound like you would thrive better at such a work culture.
However, often leads just need something in order to know what you are doing, especially managers that don't really closely work together with their team. It can help to just mention it to your lead. Because it is easy to see what you done, but not how you have helped somebody. Just mention it in whatever recurrent meeting you have. And if helping out takes more time, I'd say it is only fair to have whoever is responsible for delivery involved in prioritization, because then it is at the detriment of whatever you are working on, which might be more important.
Often, it takes less than 15-30 minutes to help somebody get unstuck. I wouldn't enjoy working at a place where people would refuse to help me with something like that, or I would be so pressed to achieve things that I can't spare 30 minutes out of my day to help someone out.
Good and bad times will do their usual sinusoidal dance but your slope will be pointing up if you zoom out.
There will be unfair promotions outside of your team, reductions or freezes in yours (companies have tendency to throw people at problems = inflate dysfunctional parts; if you have well performing team - they won’t let you grow short term; just wait it out, they will eventually).
The educational system i was put through was set up to teach that outcome scales more or less linearly with effort and time. The first lesson after graduation is that this is not so. Increased effort and time most likely primarily yields more effort and time being expected of you with lagging compensation.
Value and opportunity are chaotic processes in effort and time.
All we can do is to try to maintain the levels of workload such that we have clarity of mind to seize opportunities when they reveal themselves. Honest and balanced colleagues help there, but that is ultimately a missions for yourself only.
Helpful partners and friends who try to find opportunities most definitely can help (and in unbalanced relationships, can do it all), like the market research team at a startup.
Agree with your point, solving problems gets you points, avoiding them doesn't. My cynical view of the headline is, that a lot of people do get credit for solving problems that never really existed, simply either fabricating (intentionally or not) easy to solve problems or vastly overblowing problems they just happen to have a "solution" for.
If ypu successfully fight a fire, you are a hero, if you prevent fires it is just normal and nothing special.
It's possible to phrase the value proposition to align with what you want to deliver.
You can phrase it as "I help teams deliver on time by making sure they don't get stuck." Or "I increase a team's velocity by preventing mistakes that stop work."
It's how you sell yourself and then, how you tell the story of what happened. Being able to tell a compelling story is important.
The issue is how do you provide the evidence for that. In other terms, how do you differentiate your effect from that of Homer Simpson's Bear Patrol and Lisa's tiger-repellant rock [0]?
It is really really hard to do that in a context where its not embedded in either work culture or appreciated by your lead.
It is easy enough to 'measure', a good lead would value how you benefit the team and enhance your co-workers productivity and seek to understand this part of your contribution. He or she could just ask your peers, it is not science.
If this does not apply to your situation at all, then leave because no amount of evidence will ever force your superiors to accept it, it will only antagonize them. You do need to make your case sometimes, but the level of proof should not be that high, you need some trust in order to function as an org even if it is exploited sometimes.
Your managers need to understand the work that you're doing. When I review someone's code and I see them fixing something potentially catastrophic but that never happened, I definitely remember that and congratulate them. When I see a team member ask a question that makes me or the team rethink implementation strategy. That is very valuable. When a code reviewer finds a potentially critical bug in my code, or just a nuanced bug, I remember and appreciate. Because I fully understand that those are potential p0 or p1 issues.
And great engineers are consistently good at this type of passive, keeping the lights on work, but it does not reflect on their quantifiable work, so orgs do not include this in performance reviews. It is up to your manager to recognize this and advocate for you.
Even when they do recognize it it’s unlikely to be weighed the same as the engineer who heroically stays up all night fixing a critical issue.
Especially with many organizations focused on data or metrics for performance reviews or promotions being able to say you fixed an outage that was costing $X million per hour comes across much better than a vague counterfactual notion that your high code quality prevented Y such outages in the first place.
I am dealing with similar. I can provide solutions 10x faster than anyone. Everyone looks up to me, and are dependent on me for solutions to everything.
However it is clear that noone is improving and that the process IS me.
What I've been trying to do is make sure that my scope and role is fully clarified, and any "extra" activity that I perform is documented and flagged. Anything that becomes a "common" activity implies a missing part of the process - be it a role that is missing, or a skillset that is lacking.
Before you start thinking that it is pretentious or self serving, it's perhaps the opposite - you owe it to the process and the team/business/organisation to make them see what you're putting in, else they fail to find the gap.
It's not paid off yet, but hopefully it will yield results within the next 6 months.
One piece of advice, I found myself this person once - it’s the road to burn out city to be the critical path answer to everyone on the team’s challenges. You sound like someone who is very generous with your time and support. In my experience once people have found a critical path there is no point at which they “stop.” This isn’t because they’re trying to hurt you, they’ve just found the answer so to them it doesn’t seem wrong.
It will take even more of your time, but you ought to consider practicing giving less answers and asking more questions of those who seek your help to try to help them unpack the issues themselves. It will feel more tiring at first, but you’ll gradually help the others learn and also create a small bit of friction that will encourage them to try their own solution or two before seeking you.
Management asks are separate/ they can actually reward you with compensation and promotions for this extra work. But the team asking for help won’t stop when you get more comp unless you start teaching that you’re not the answer.
Depending on your context, if you are at the top of the foodchain as described here, minus the recognition for it, one option is to simply add grist to the mill. Creative problems you can leave for the team to sweat and for you to come and slamdunk.
1. Donald Rumsfeld was right when he said “A’s hire A’s, B’s hire C’s”.
2. Environments where people can’t tell the difference between 1x and 1000x engineers lead to performative work and arsonist firefighting.
3. When folks in your organization can’t recognize (and reward) high impact, it’s probably time to get out, largely due to the first two points.
The lean mantra "Make work visible" is not only good at an organization level but also as professional feedback level. Although if used openly for promotions it will cease to be a good metric.
I'm currently in an unrelated field, but with a similar tension of unclear value while things work. The way to deal with this has been to keep a tally of checks on important systems, whether it's daily, weekly, monthly, with links to undesired outcomes should the process that has been checked fail. This list of you checking the processes is one way to "prove" your value, at least for ppl who wouldn't necessarily understand naturally.
I always get cynical when I see awards for software releases. Someone always gets an award for staying up late to fix a last minute problem. Normally the person that should have written good code in the first place so they wouldn't have had to come in late. The award should go to the person (likely people) who never got called in at all in the first place because we didn't find a bug in their code.
The opposite. Department heads get fired for allowing blow-ups in their area, that should have been avoided. "Getting credit" means keeping the job managing the department via preventing problems.
I’ve seen it mean the department head is told to cut staff. If things run smoothly with 100 people, let’s see how runs with 90, then 80, and so on. The preventative measures start taking a backseat as the staffing issues are felt. The cuts keep coming until something falls over and the department head is pushed out after failing to maintain the service.
At one place, there was some important order processing taking place. As is fairly typical, couldn't rely on getting all the required info. Or critically, getting all the required info correctly. Some extra data, slightly missing pieces but enough to work, etc. etc. Some could be pretty gross. We built validation to massage some inputs, modify processing, what have you to address as many of those as we could think of. The team put in some metrics to identify which validations were "triggered" for each order. Neat. If we'd add more, we'd add a date to it.
It was great. We reported those stats so anyone could see anytime, but we'd also send out some comms about it every now and then. It also helped tremendously when a coworker or customer or whoever would say "Oh no! What happens if XYZ?" and we'd say no worries, we already addressed it, and we prevented #### orders from getting stuck for XYZ.
It showed that the team was thoughtful, that we were invested in making this work, that work needed to continue to keep things running smoothly, and we had data to back that up.
Really helped switch the conversation in the org because folks could see it. If someone pointed out that we hadn't thought of something, it honestly was more about what do we do vs. why didn't we think of this. (Yes, there is a comment here about poor org thinking or blame culture, but some of that exists everywhere.) More proactive. Recognition of preventive quality. People gave us accolades and it bubbled up to some good and real recognition at higher levels too.
I'm mangling the words here a bit but I hope you get the idea.
There is a simple but undeniable element of genius to the idea of, instrumenting the number of validations triggered. I would hazard a guess that 90+% of teams would focus on an "order success rate" type of metric and call it a day, instead of a "# of times bad data was handled" metric, which is exactly how you escape this trap of good work going unnoticed.
Thanks for sharing! Shamelessly stealing and applying this concept at work next week!
Yeah. Another way I would put it is to also look at inputs that strayed off the happy path. There may be something to learn from them as well, maybe something that adjusts the happy path.
That's exactly where we started. It worked or it didn't, right? The team was super curious to know, in fact, how many of the edge cases happened. That piece right there had some unexpected value as well. And it grew out from there.
Reminds me of a place I used to work. Every time they asked for feedback, my refrain was "nothing here gets prioritized without a PIR (post-incident response)". Towards the end of my time there, whenever a PIR-related ticket showed up, I would mark it as a duplicate of whatever actual ticket I had dying in the backlog that would have prevented it. It really hurt team morale to have no influence in preventing foreseeable issues in our domain area. Most of the rest of the team had even stopped suggesting improvements altogether because management refused to let us pull our own tickets in.
This is why in many corporate cultures it pays not to proactively stop a problem that you know how to fix if the problem is not in your immediate problem area. Let it be noticed, let it become someone else's emergency, then fix it. Much better path to a reward that way. Of course, you should also be planning to leave said organization, in the long run it won't do well.
I wouldn't be so sure. As an employee and team member, you'll be better perceived if you do your share of performative firefighting every one in a while. I wish it wasn't true, but it usually is. (Though at remote teams, it's less and less true, with the remote teams I was on, nobody really cared).
"wow, last week we had such nasty bug, impossible to track down, also caused production reliability issues. Tom stayed up all night, and finally pushed the fix at 3 in the morning."
Now, if you then say that it wouldn't have happened if 1. Tom didn't overcomplicate the system, 2. Tom learned our tools properly, 3. Tom actually understood the requirements and at least tested his changes at least once manually, 4. Wrote good code so that it's easy to troubleshoot 5. Wouldn't have forced a rushed PR review together with the product owner.
Nobody ever gets credit for fixing problems that never happened (2001) [pdf]
I'm reminded of this every time I see some YouTuber or other social media click bait claiming that the Y2K bug was no big deal.
The reason it was no big deal is because thousands of graybeards, like myself, stayed up many long nights for months ahead of time making sure things would work.
I still remember the tension during the countdown to midnight UTC. Then the tension rising again during the countdown to Eastern time. Then once more at local time.
Only when it was 2000 in Pacific did we unclench our cheeks.
"Most" programs used epoch time, like video games. The minority that didn't were the big, stable, old programs that ran on big computers. Things like payroll and flight schedules.
That's not what I remember programs looking like. You would have counters that went to 99 and no more because the UI wouldn't accommodate another digit, and programmers didn't know what they were doing, and figured it would be clearer if the software reflected its UI and couldn't handle over 99 at all, invalid UI means unrepresentable state.
Lots of stuff didn't care about the day, too, like you'd get 0997 and that meant September 1st 1997 because the first (or last) of the month was inferred, and you'd get goofy logic around year++ where you add 100 years whenever you want to increment the month, and the whole thing is written as a modulo 1200 but whenever the date is about to be 0000 you look at what's stored in year instead and add one to it instead of 100, because that way you have less variables to allocate and every "little bit" counts.
Everyone knows now, but lots of people writing programs didn't have any prior art, they were just good at messing with computers and sort of fell into programming by accident.
It was also to do with how dates were stored in very old databases that were conceived in the 70s when storage was at a premium - a lot of them just used two digits for year.
Depending on which Y2K bug you're referring to, this very much happened and is an easily believable scenario. I don't think this is a comparable situation.
I call these problems ticking time bombs. This way business has a catchy name to use for the thing they dont understand, its also very clear this needs to be looked at.
Take a leaf from the OH&S book, as OH&S is all about stopping things from happening. Many work places have a huge "Days Since Last Lost Time Accident" sign hanging out the front. It increments every day and the aim is to get it as high as possible.
The same metric could be applied to "Days Since Last Stuff Up That Cost Us". It would be easy thing to apply to an office door or cubicle wall.
This is wonderful description of the kind of hellhole corporate Scrum is turning into.
Agile was literally about doing things quickly and quick cycles of capability improvement. But Scrum is a worse version of the planning processes it meant to replace!
If anything, the way scrum lays out the work into immediate problems exacerbates the cycle. In the long run it just turns into a ticketing system where fires get pushed up and technical debt gets pushed down.
It even spits out a super easy-to-track, meaningless set of efficiency numbers for consultants/executives to min-max!
I found the idea Scrum being efficient when done right was true at one company I worked at. Everyone was committed to the process, the Scrum team included debt as a priority for 20% of the effort and everyone had a fairly accurate velocity that we could bake in an additional 20% of your work as your own interests, so stakeholder priorities filled that remaining 60%. Then we would pivot in some Sprints if any epic/team goals required a push to get done or other emergencies/bugs that required a change in priority.
I don't think it can't be done right, but it's been cargo-culted pretty hard at Fortune 500 companies. But the best scrums I have ever done have just been literally post-it notes on a whiteboard - I think Jira ads a level of complexity that is unsustainable for most orgs.
In my 17 years in the industry I saw working agile twice. Both were small places, both used post-it notes. Both were consultancies, each team dedicated to an independent project.
Everything else, world-class, public, private, consultants or not... was a joke.
I don't think cross-team collaboration works in agile. Either one plans ahead, or everything becomes an unpredictable mess.
Similar, but one place, and same with post-it notes. It went down the shitter when Jira was force fed and all the problems related to keeping them in sync arose.
"b-b-but other teams need visibility of your sprint!" no they don't. I don't think I've looked at other board other than by accident.
I still can't believe a scrum master is an actual FT job - last company I worked for had one FT scrum master for each project - so they ran the meetings and as far as I can tell, did nothing else - what the heck do they pretend to do for the rest of the week?
I went to all the same meetings, and was still supposed to actually develop software in between them all.
I've found it works better when you "build up" to Scrum by incrementally adding processes when you identify issues and relaxing the process if things are working well.
Adding a bunch of processes because you want to add processes doesn't provide value.
Agile seems to have ended up as a way for PMs to report upward to senior managers who also need to report upward.
You can see why. These people have to decide what will be worked on out of all the potential things that can be worked on. Someone has to make that decision. Will this feature make us money? What about that bit of work that doesn't add a feature but reduces resource costs? What about tech debt that I'm told is building up and slowing the ability to deliver features?
I'm not a senior manager, but ultimately someone up the chain is responsible for the company surviving and making money and paying our salaries. They are just like you and I, trying to make decisions based on what little information that can glean. So part of that is "what will this cost and how much will it be worth" vs "what will that other thing cost and how much will it be worth".
To that end, they need some way to estimate this. They latched on to agile as it was being promoted by tech as a way to do this. Whose fault is that?
And so with that came all the frequent estimations, are we on track, rituals, etc. Some people don't believe this should naturally follow. I agree. But somehow all those rituals have become part of the cult.
We abondanded scrum. We abandoned refinements and estimation of stories and story points etc. Now we meet with a PM once a month formally and as a team perform a t-shirt size estimate on where we are. Otherwise we update her as frequently as she asks (which isn't often) or we want. This gives power to us but because of that we're conscientious and make sure to inform her timeously when things are looking sketchy or whatever. Yes, we still have to give "estimates", because ultimately, senior management want to make decisions, but it is otherwise quite lightweight.
445 comments
[ 3.2 ms ] story [ 303 ms ] threadhttps://news.ycombinator.com/item?id=8940820 - Jan 24, 2015 (50 comments)
"we were all worried about the ozone and nothing happened, this is just a repeat and people will stop talking about it any time now"
and my response is "'Nothing' happened because the governments acted fast and turned it around so now it's mostly just boring stuff like catching some factoryy that decides to go cheap and use banned chemicals to save a buck"
There were a few jokes about it in the newspapers but by and large the public just ignored it.
I work on climate and hope / hoped that the same would happen, but it's looking like it will soon get everybody's attention regardless.
Unfortunately those fixes are slated for Humanity 2.0, Homo extinctus.
Climate change will impact companies in different ways at different times. Oil companies, for instance, are incentivized to ramp up production as much as possible while also diversifying.
The way to get all companies to take appropriate actions is to not allow them to externalize costs. That means a significant carbon tax.
People ask why they don't hear about it anymore -- oh, it's because we listened and banned CFCs and fixed the hole.
Some countries have not heard the call yet it seems (ones that like their role as perpetual victims and blame everyone else but themselves), but even just five years down the road, the world will already look very different for all the effort that's being made.
You guys are all in your Y2K underground bunkers still, right?
Disclaimer: I was part of that effort. The funny thing was that I was brought back to a previous client to fix something that my previous efforts had literally caused. Took me 20 minutes to fix it once I saw what the problem was. And then there was a "while you're here, can you take a look at this ..." That lasted about two years until they closed the department and moved it to NY, NY.
At least I got credit in terms of billable hours.
If you are prepared, nothing interesting happens, life moves on, people opened a notebook and pressed a few buttons.
If you are not prepared, the texas grid freezes, people die, people lose their savings, and "nobody could have imagined it would be this bad".
In strategic sysadmin and cybersecurity this is staple thinking, and a useful part of what I teach now.
Problem for vigilant thinkers is the rewards, as explained in TFA, are perverse.
People are content with technology to be magical. They don't see the millions of people quietly repairing it and planning to keep it all going smoothly.
To "bosses" cybersecurity only bring them problems, and cost them money apparently doing nothing. The same for any defence force, until you need it.
Did some nice interviews for international sysadmin day last summer [1].
[0] https://www.goodreads.com/book/show/22663095-left-of-bang
[1] https://cybershow.uk/episodes.php?id=15
But it is a great example. I still run into people who recall Y2K as an example of much ado about nothing. No, no!! It wasn't an issue for you because many people worked hard to prevent the problems.
Those problems were not terribly complex just pervasive and critical, requiring a high LOE. It wasn't like a huge moon-landing engineering problem to be held up as some accomplishment of humanity, more akin fixing a lot of dumb Challenger o-ring problems before a blow-up.
I liked the quote in the 2015 submission that twic posted [0], it relates back to the "seems obvious" sentiment. A lot of good solutions are simple (or composed of simple elements in a sane and reasonable fashion). But arriving at those solutions is decidedly not simple or obvious if we go by the Rube Goldberg machines that people end up contriving instead.
[0] https://news.ycombinator.com/item?id=8940820#8941621
[1] https://en.wikipedia.org/wiki/Preparedness_paradox
This is a management problem, because no-one wants to be accountable for a repeat incident even if it was rational to be working on something else more important.
1) We must do something.
2) This is something.
3) Therefore, we must do this.
Politicians, the media, corporations, and the public all have a part in this.
Sure, that's why the politicians want to be seen doing it. But the legislative focus is often on getting something passed now while it's a hot issue rather than on eventually getting a good bill passed (let alone deciding that we actually already have the correct amount of legislation on the topic).
Like many other problems in politics, the root of the problem is the other voters.
Waiting for something to actually happen before allocating resources to preventing it is (to some degree) a rational policy.
I've heard this called "institutional scarring" in a blog post somewhere. The idea is a small wound can be replaced with tough inflexible tissue. The jist of the blog post was that just because something happened, doesn't mean you have to change things to ensure it never happens again because that can be an over-reaction that really burdens your future. Accept that loss and that it just might happen again, but that may be better than onerously preventing it with certainty.
Surprised you found it despite my butchery!
e.g., You were tasked with working on a ball of mud and it was miserable, so the next system you get the chance to build has to be the most scalable, modular, and cutting-edge thing ever, just to be safe.
I spent a miserable year trying to convince people that they were over-reacting to an outage and there was a very simple solution to the exact problem that occurred. But when senior managers see their jobs at risk because of a repeat, they'll mandate that the entire department review their code for similar issues and remediate. They'll also listen to the loudest voices who somehow come up with massively over-engineered solutions.
Another example, we had a password expire which caused an outage on our trading stack. The amount of effort that went into stupidly convoluted hand-crafted solutions ensuring this "didn't happen again" was laughable. And in the end, after more than a year of work, the whole thing was abandoned in favour of a much simpler centralised solution that should have been done from the start.
Now we have something akin to a "person that prevents problems" award. It's a nice gesture, but, even though I received one, I think it's mostly nonsense. You don't get the face time/experience presenting with the higher level managers. It's almost impossible to prove that you prevented catastrophes, by working extra hours, or doing the right thing. Nobody likes a "Hey look, I told you so!" sort of perspective, no matter how it's framed.
To me, this is the most gratification-limiting aspect of being a software engineer: time is required to test quality of foresight/design. Rewarding retroactively, for great past decisions, doesn't happen. There are systems I designed, when making a pittance for compensation, that's still being used a decade later, across multiple companies, almost entirely unmodified. That, now objectively, good work wasn't seen or recognized by anyone paying me at the time, and can't be seen by anyone now. I burned good time for a "good job me!" as a reward. As I get older, that mental masturbation seems less desirable, since it's usually at the expense of the surprisingly limited life credits that we spend on those tasks. But along with most other nerds, I can hardly stop myself because it's an innate obsession.
Does anyone know any great management books on this subject?
Not a management book per se, but Working Backwards popularised an Amazon approach of thinking about the organisation in terms of mechanisms. You might find that useful.
I’ve always wanted to dig into Scarlet Ink, Dave Anderson’s blog, but never have, and I suspect it’ll be quite useful for you too.
This happens in organizations that become over reliant on metrics and indicators of success/failure instead of recognizing that these are fuzzy concepts and indicators are just that... indications, not answers.
The most memorable example was at a hospital, nurses would occasionally pick up the wrong vial. They always noticed before injecting, but there were lots of close calls that didn’t get tracked anywhere. Once they started tracking that as a leading indicator, it became pretty obvious that the vials needed a better design to prevent even the possibility of grabbing the wrong one. Also, if the hospital never realized this problem and someone got hurt, they would’ve ended up with a much worse solution like “double check really close”
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
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.
Is the problem the incentive itself, eg. if they didn't reward fixed bugs would you write better (even just better communicated) code?
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.
Moral points don’t pay my mortgage.
https://news.ycombinator.com/item?id=18462325
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.)
From my limited experience with "proprietary bullshit languages that only exist to hook customers", there's ways to mess up how loops work in the language. So maybe those senior engineers actually know what they're talking about.
I've seen "languages" that treat variables differently based on whether they have uppercase letters and underscores. Before I saw this in action, I believed the seniors telling me to "never use uppercase letters ever" were insane...
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.
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.
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!
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.
Never point to the possible issues at the code reviews, retirement refinements etc.
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.
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.
Those 100 users took performance to a crawl but we never seen it earlier because it was never used that way in that capacity.
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.
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)
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.
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.
He's one of my favorite pranksters. But needless to say, the football team was not very good.
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.
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.
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)
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.
Neither does it imply that it never happened.
They shared a story.
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.
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".
The opposite is the lemons market. It is why getting some wet building work done that is actually waterproof is a fucking dark art. Even the pros hiring pros get fucked because the “is waterproof” part is invisible.
Doing this effectively requires tact. Try to mostly bring up your silent efforts casually, and be judicious about how often and in what situation you mention it. If it gets interpreted as an "I told you so," an excuse, self-importance, etc, then it will probably do more harm than good in terms of your standing with others.
Might be helpful to some degree. But won't save you if your organization's culture simply doesn't value your work or more generally doesn't care about proactive, methodical improvements that have no flash or immediate payoff.
In the context of one's effort valuation it seem to be a very bad advice. Unfortunately.
So in small teams where visibility is clear those things are obvious.
It's in larger orgs where you want to climb the ladder that you get bonus points for the problems fixed but not those you prevented.
At a big company you should be able to turn that into a number - 'this kind of issue was costing us $X/quarter, and thanks to my work, it is now costing us $(X-N)/quarter, in line with my estimates.'
It's performance season so I've been giving a lot of thought to how you quantify and attribute impact especially for folks in lower-visibility roles.
Not every company is going to see it this way but that's kind of a truism. Not every company sees any one kind of impact the same way, and you have to think about that relative to your career goals. I think aligning with your manager at the start, quantifying your impact and showing your results is going to get you the recognition you deserve at any company worth working at.
The intelligent, optimistic and genuinely good, helpful people who don't learn this (or refuse to compromise their good nature) end up burning out, getting performance managed or with PTSD
Some people don't want to give up the job at High Status High Pay Corp. That's the trade-off they are choosing. (Not every HSHP Corp. has to be a bad place to work, however.)
Well thought and expressed. Thanks.
> numerous daily examples of people just trying to do the right thing
And most people reading HN can do that.
That's such good advice.
On the same note, it's so discouraging when someone who is not/neither takes over, those people leave (one way or another), and you have to start the search again.
Or when someone is intelligent enough you don't figure out they're not honest until it's too late. <shiver>
Anyone who's been around the block a time or two will accumulate those experiences. I hope I've not been jaded by mine.
> Work is with honest, intelligent people
Yes.
Very true, and it may not even be malicious on their end, just avoidance and their brain rationalizing/minimizing without them realizing it.
This is good advice that’s well intentioned, but (sorry), it can be interpreted as elitist, and in a way that’s detrimental to the reader.
I am no way suggesting that this is the intention or belief of the parent, but while I’ve got more miles on my odometer than I’d prefer, they’ve informed me that “reasonable” is better than “intelligent.”
My god how I’ve found that working with reasonable people is so much healthier, more productive and rewarding than working with the unreasonable* intelligent folks.
*I fully grant to my current and former colleagues, friends and associates that I have been irredeemably unreasonable any number of times. Consider this a small thanks :).
Being reasonable is part of being intelligent. Surrounding yourself with intelligent people doesn't necessarily mean "surround yourself with the highest IQ individuals you can find." (not saying you're saying that explicitly, just that i think you're just using a definition of intelligence that's narrower than the parent) Working well with others, understanding when one has made mistakes and being able to admit to it, understanding both the known unknowns and the unknown unknowns of a problem...these are a better mark of intelligence than a mensa membership.
Not in the slightest, those two are quite separate.
I happen to believe that reasonableness is part of being intelligent, by the following criteria:
1. when you are reasonable you do not make unreasonable demands that will just be troublesome and cause workflow issues because in the end they are unachievable.
2. a reasonable person will be able to determine what other people are capable of in given situations, and be able to structure things in such a way that other people can perform to best meet expectations.
3. the root of reasonable is reason, a reasonable person can be reasoned with because they possess the quality of reason, in most of the history of philosophy if you do not possess the ability to reason you are an idiot.
Moreover, being able to admit mistakes (specific thing mentioned by parent) is oftentimes detrimental for you. People who do not admit them are typically rewarded, people who easily admit them punished. So, what you are looking at is "ethics even if it does not benefits me".
Being reasonable, is being someone with a strong genuine value for collaboration. They actively advocate for and work with others to optimize situations taking everyone's needs into account. Encourage give and take, constructive debates, and appreciate feedback. Etc.
An intelligent person can be all those things. Or none of them - but manifest them enough that, with some spin, they seem reasonable, while actually optimizing the environment primarily for their own long term benefit.
Very intelligent unreasonable people are disasters to work with.
> it can be interpreted as elitist
If "intelligent" is taken as 'naturally superior intelligence', then I can see what you mean (and I think that idea is a egomaniacal delusion). What I mean is people who choose to act intelligently; that's quite democratic.
It’s life goals to be smart, kind, and down to earth. It really comes from a LOT of experience though.
There's nothing wrong with elitism as long as it leads to initiation rather than gatekeeping.
> My god how I’ve found that working with reasonable people is so much healthier.
Could not agree more. Most people can be trained well to do any job required of them. What cannot be trained, and certainly at the behest of the employer is interpersonal skills.
The one situation where I would prefer someone who is intelligent at the expense of being personable is if I intended to hire 2-3 absolute weapons to be the core of a startup.
I think that those can be trained as well. The fact is that just acknowledging the issue requires a level of self-awareness that not everyone has, and training THAT as well requires being aware of it. External input and help from a specialist or a dear friend can get the ball rolling.
I really wish this were true, but especially in programming I don’t think this is the case.
I’ve spent years as a programming teacher. Some of my students have been among the most wonderful, enthusiastic, hard working students you can find. And yet, despite both of us working hard for a year or more, some never develop any talent whatsoever for programming. Statements like “everyone can code” can easily turn into a rod for their backs. - “Therefore if I’m not succeeding like many of the other students, it must be because I’m not trying hard enough, or there’s something wrong with me”. I don’t think this is anyone’s fault. Perpetuating the lie that all our brains have an equal capacity to program is a terribly cruel injustice. Some students would be much better served by finding another career that they can excel at. The faster they figure this out, the better.
Programming isn’t for everyone. It’s hard. Not everyone has the same capacity for it. I believe accepting that is an act of kindness.
I should have made my prior assumptions clear. The "most people" I'm referring to are CS graduates or people with IT diplomas and the percentage among those who are trainable to a capacity of competence in most companies are roughly 70%.
> Perpetuating the lie that all our brains have an equal capacity to program is a terribly cruel injustice. Some students would be much better served by finding another career that they can excel at.
When I was still a uni student I used to be a CS tutor in a help desk setting and I especially remember one guy who used to come in a lot. He had a really great attitude despite being humbled by the fundamentals. He used to repeat to me: "Sometimes you have to ask for help when you need it." After that semester I didn't see him again. I also remember a particularly annoying guy who used to come in and waste my time and the other tutor's by bringing in a problem and then solving it himself within seconds of sitting down just so he could talk about how he solved it and how much he knew. The world is not a fair place.
Yep. Those two stories are in some amount of conflict. I agree that anyone who has passed a decent hiring bar can be trained to some baseline level of competence. But the difference in capacity between that baseline level and someone brilliant can be huge. And it matters. This is the difference between something being an ongoing issue for the team for months, and it just quietly never seeming like it was ever a problem in the first place. As you say, it’s totally unfair.
People known for being purely highly intelligent people often think they know it all and are often a net drain.
Both honesty/reasonableness and intelligence are required. A family memebr is tearing her hair out about having to work with some assistants who are honest, well-intentioned, and pleasant, but who are just mentally incapable of keeping things straight — they literally screw things up and make more disorganization than they fix (fortunately, better help is supposedly on the way).
Overall, in hiring and working with people, most of the time, a warm body is definitely NOT better than nobody.
I'll let you know when I find this communist utopia.
If you start micro-optimizing - especially on other people, whose behaviour you can rarely change. It may leave you with lots of frustration and completely missing the grand picture.
I've personally been fortunate to have been able to form a network of a bunch of different well-connected folks so I can always choose who I get to work with in the event that companies shut down or get acquired or such and such. I feel the value of such a network does not get touted often enough.
Finally, I accepted the solution was long-term. I made a long-term plan - to do what I really loved - and focused my attention on that, and slowly built up the resources, skills, etc. for that plan. One wonderful side effect was that the dead-end part diminished in my mind; sure, I still had to do it, it still sucked and there were some awful days, but it would pass. I didn't matter so much; those people didn't matter; it was like one of those movies where the kid knows that someday they will leave the depressing, dead-end town they are stuck in today.
I hope that helps a little in your situation! Good luck!
Not too many of them around, are there? You can have either honesty or intelligence but not both.
Think that it is the management's fault if they misjudge you. They have the chance to judge you correctly, yet they misjudge you. Their fault entirely.
1.) Create a spreadsheet with all of the features of your group's/company's products(s) listed in rows.
2.) Create a column for every team member in the group and highlight the lead developers for each feature.
3.) Then ask each team member to add a checkmark in their column for every feature for which they would be willing to be on hook for 24x7 triage pager duty.
Over the long term - the most valuable contributor(s) on the team will be the one(s) with the most checkmarks next to the features they led development on (i.e. they write understandable code and document well) combined with the most checkmarked rows in their column (i.e. they proactively seek to understand other peoples codebases).
What if the table in fact shows which people are best at dodging the hard work
Combined with showing who has the most friends in the office (giving checkmarks to features built by one's friends)
This is kinda a well known phenomena in medicine[0]. Same with lawyers. I'm just reminded of this scene from Silicon Valley[1]. It's messed up and why everyone needs to be very careful with metrics and remember that metrics are only guides, not targets.
[0] https://www.theguardian.com/society/2016/jan/29/doctors-avoi...
[1] https://www.youtube.com/watch?v=5sTbjO3eI_0
In general though even if some developers are gravitating to only projects that are simple/trivial, those wouldn't necessarily be differentiators because such projects would have checkmarks by other developers as well.
Also it can help to have the Product Management team rank the features in terms of strategic importance and criticality to the functioning of the company.
I'd say the biggest benefit of such a spreadsheet is to provide visibility to leadership about the bus factor of the team. Too often the critical projects are really only maintained by a few team members. There's no incentive for new team members to learn the "legacy" projects versus creating their own pet projec. Then the inevitable RIF or transition happens and the lack of long term support becomes an issue.
These bosses tend to be competent ICs who became team leads, they are best positioned to judge the ICs they manage because they themselves are masters at the craft.
In the end people ended up simply inflating the value of stories.
In my previous team I had to argue with a person that 2 story points to add translation keys were ridiculous.
To which the EM argued that 2 was okay because he also needed to write few accompanying tests.
I have nightmares thinking about this stuff. It was literally quicker to add the translation keys and that pointless test than to even discuss and vote the story and debate the points..
And large companies will probably never learn, because at some critical mass it becomes less important to ship than it does to tell people how cool the product you want to ship is. Devs don't get paid for shipping outside of a short surge of stocks (which they proceed to not be able to take advantadge of because potential insider trading). Heck, some industries just let you go after you ship.
"learn how to be better at self promotion"
Do you have another solution to this issue?
If you are an IC, you play it up with the right people. Those right people fight for you instead of the other way around. When the “we need to cut the fat” talks come around, suddenly you are not on the chopping block. But that also assumes the people fighting for you are not on the chopping block.
Soft skills across the industry is highly under valued. Knowing when to pick a fight or hold your tongue is also important (ie, reading the room).
I hate it but you got to do what you got to do to get that cheddar
which is why one should not self-sacrifice. It garners no reward for one. Secondly, if the boss doesn't realize how much of an enabler you are, then it's time to start looking for a new job before the layoffs even starts as a thought in the boss' head.
They eventually acquire enough experience to be able to produce something that sort-of works around the 3rd attempt.
But thanks to how good they are at communicating, are considered by management to be good engineers.
While doing a working project at the 1st try, without using this week's new framework and so on isn't as valued.
Unfortunately, this can cut the other way as well where you can have someone incompetent override competence or not even involved people further down which is common during large layoffs
This is in fact known in management literature: assign your best people to the least important project. That way the second best can grow to become the best, while the best are always free to help out if your fourth most important project has issues - it isn't a big deal if your least important project doesn't get done on time and if they manage to finish it so much the better. (your best are also free should sales discover a short window where a quick feature can bring in a large sale - though this is obviously easy to abuse)
Also, can you describe the problem? It sounds interesting.
The UI had options to check some categories and exclude others, this was mapped to sql with a nested query IN (…) and not in (…). I noticed that there were less than 64 categories and always will be so I figured pack the category membership into a 64bit ints and use bitwise operations. The UI query generation would map to use bitmasks instead. They didn’t even let me implement it, just agreed that it would work and took it from there. I think they were quite embarrassed by it. It ended up being 10K faster.
If they were ready to have you on for 6 months, You'd still probably be one of the most honest contractors if you stretched that out to a week, or even month. It's a shame honestly isn't always rewarded proportionately to suggesting an entire rework of their infrastructure.
Don't waste your time and clients money on pretending to do work that you don't. Its ethically wrong (maybe even criminal) and it sounds like you would be bored to death wasting your talent.
Don't blame the company for not wasting its money either. It did pay for the whole day and gave you good recommendations.
You could do fixed price. Or split the difference (on both sides of the estimate), which provides good incentives for both parties.
The hardest part of getting into contracting was the guilt of feeling "I'm charging too much for a simple fix!". If the fix was so simple and the client didn't find it in those six months then maybe your assumption that the fix was simple and obvious was incorrect. Regardless, your fix provided value, and you should be compensated for the value that you provided, not just the number of hours worked.
The psychology of workplace is quite subtle and almost backward. There's a motto "squeaky wheel gets the grease" .. to the point I'm thinking of trying some games. Like designers who produce crappy options and one good to toy with higher ups thinking they decide. There are some ideas in that vein so you flip the relationship and benefit from it instead of bleeding.
If your solutions tend to be more stable from the get-go, it will get noticed at most places. There are always going to be that odd company where that's not true, but in my experience, simply doing higher quality work gets appreciated.
Good leaders. Or, worse: Consultants. That is, it takes either an outsider or a self-critical leader to affect change? Those doing the planning are always optimistic [0] about their decisions, processes, evaluations, and progress. https://en.wikipedia.org/wiki/Planning_fallacy
[0] not always bad: https://en.wikipedia.org/wiki/Hiding_hand_principle
Having a boss that loves to sell his team's work to his boss also works wonders.
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.
A mature organization respects the process that prevents getting stuck for 3 months. But… they may be more stable and less nimble. Boring orgs don’t like heroes.
A Sr eng who spends 6 months coaching a junior engineer has much lower value/hour.
Assuming you are doing other things make sure that is visible.
Also why did your colleague wait 3 months to ask you for help? A couple days would be OK, a month would be crazy. You should poll them and not wait for an interrupt.
Up until that point I knew my value but I don’t think anyone else quite got it.
The above seems to be how the top billing agencies on Upwork function, with fewer staff you can grift more people because the hours being billed aren't honest, and so you can have more clients and reach the "top" earnings position faster and more easily; with the same practices existing at least on one of the two prior platforms before oDesk and Elance merged.
However, often leads just need something in order to know what you are doing, especially managers that don't really closely work together with their team. It can help to just mention it to your lead. Because it is easy to see what you done, but not how you have helped somebody. Just mention it in whatever recurrent meeting you have. And if helping out takes more time, I'd say it is only fair to have whoever is responsible for delivery involved in prioritization, because then it is at the detriment of whatever you are working on, which might be more important.
Often, it takes less than 15-30 minutes to help somebody get unstuck. I wouldn't enjoy working at a place where people would refuse to help me with something like that, or I would be so pressed to achieve things that I can't spare 30 minutes out of my day to help someone out.
Your value will emerge with time.
Just keep calm and carry on.
Good and bad times will do their usual sinusoidal dance but your slope will be pointing up if you zoom out.
There will be unfair promotions outside of your team, reductions or freezes in yours (companies have tendency to throw people at problems = inflate dysfunctional parts; if you have well performing team - they won’t let you grow short term; just wait it out, they will eventually).
Value and opportunity are chaotic processes in effort and time.
All we can do is to try to maintain the levels of workload such that we have clarity of mind to seize opportunities when they reveal themselves. Honest and balanced colleagues help there, but that is ultimately a missions for yourself only.
Agree with your point, solving problems gets you points, avoiding them doesn't. My cynical view of the headline is, that a lot of people do get credit for solving problems that never really existed, simply either fabricating (intentionally or not) easy to solve problems or vastly overblowing problems they just happen to have a "solution" for.
If ypu successfully fight a fire, you are a hero, if you prevent fires it is just normal and nothing special.
You can phrase it as "I help teams deliver on time by making sure they don't get stuck." Or "I increase a team's velocity by preventing mistakes that stop work."
It's how you sell yourself and then, how you tell the story of what happened. Being able to tell a compelling story is important.
[0] https://www.youtube.com/watch?v=xSVqLHghLpw
It is easy enough to 'measure', a good lead would value how you benefit the team and enhance your co-workers productivity and seek to understand this part of your contribution. He or she could just ask your peers, it is not science.
If this does not apply to your situation at all, then leave because no amount of evidence will ever force your superiors to accept it, it will only antagonize them. You do need to make your case sometimes, but the level of proof should not be that high, you need some trust in order to function as an org even if it is exploited sometimes.
If you don’t have such a manager, perhaps find them. Or become them.
And great engineers are consistently good at this type of passive, keeping the lights on work, but it does not reflect on their quantifiable work, so orgs do not include this in performance reviews. It is up to your manager to recognize this and advocate for you.
Especially with many organizations focused on data or metrics for performance reviews or promotions being able to say you fixed an outage that was costing $X million per hour comes across much better than a vague counterfactual notion that your high code quality prevented Y such outages in the first place.
However it is clear that noone is improving and that the process IS me.
What I've been trying to do is make sure that my scope and role is fully clarified, and any "extra" activity that I perform is documented and flagged. Anything that becomes a "common" activity implies a missing part of the process - be it a role that is missing, or a skillset that is lacking.
Before you start thinking that it is pretentious or self serving, it's perhaps the opposite - you owe it to the process and the team/business/organisation to make them see what you're putting in, else they fail to find the gap.
It's not paid off yet, but hopefully it will yield results within the next 6 months.
One piece of advice, I found myself this person once - it’s the road to burn out city to be the critical path answer to everyone on the team’s challenges. You sound like someone who is very generous with your time and support. In my experience once people have found a critical path there is no point at which they “stop.” This isn’t because they’re trying to hurt you, they’ve just found the answer so to them it doesn’t seem wrong.
It will take even more of your time, but you ought to consider practicing giving less answers and asking more questions of those who seek your help to try to help them unpack the issues themselves. It will feel more tiring at first, but you’ll gradually help the others learn and also create a small bit of friction that will encourage them to try their own solution or two before seeking you.
Management asks are separate/ they can actually reward you with compensation and promotions for this extra work. But the team asking for help won’t stop when you get more comp unless you start teaching that you’re not the answer.
Well, a problem that hasn't happened yet is a risk, right? So you can apply risk assessment math to it:
Value = Estimated risk of the problem occurring * Cost if it happens
But in this case, if those problems were to happen, they wouldn't be stopped by their measures.
At one place, there was some important order processing taking place. As is fairly typical, couldn't rely on getting all the required info. Or critically, getting all the required info correctly. Some extra data, slightly missing pieces but enough to work, etc. etc. Some could be pretty gross. We built validation to massage some inputs, modify processing, what have you to address as many of those as we could think of. The team put in some metrics to identify which validations were "triggered" for each order. Neat. If we'd add more, we'd add a date to it.
It was great. We reported those stats so anyone could see anytime, but we'd also send out some comms about it every now and then. It also helped tremendously when a coworker or customer or whoever would say "Oh no! What happens if XYZ?" and we'd say no worries, we already addressed it, and we prevented #### orders from getting stuck for XYZ.
It showed that the team was thoughtful, that we were invested in making this work, that work needed to continue to keep things running smoothly, and we had data to back that up.
Really helped switch the conversation in the org because folks could see it. If someone pointed out that we hadn't thought of something, it honestly was more about what do we do vs. why didn't we think of this. (Yes, there is a comment here about poor org thinking or blame culture, but some of that exists everywhere.) More proactive. Recognition of preventive quality. People gave us accolades and it bubbled up to some good and real recognition at higher levels too.
I'm mangling the words here a bit but I hope you get the idea.
Thanks for sharing! Shamelessly stealing and applying this concept at work next week!
I hope it helps!
This is why in many corporate cultures it pays not to proactively stop a problem that you know how to fix if the problem is not in your immediate problem area. Let it be noticed, let it become someone else's emergency, then fix it. Much better path to a reward that way. Of course, you should also be planning to leave said organization, in the long run it won't do well.
"wow, last week we had such nasty bug, impossible to track down, also caused production reliability issues. Tom stayed up all night, and finally pushed the fix at 3 in the morning."
Now, if you then say that it wouldn't have happened if 1. Tom didn't overcomplicate the system, 2. Tom learned our tools properly, 3. Tom actually understood the requirements and at least tested his changes at least once manually, 4. Wrote good code so that it's easy to troubleshoot 5. Wouldn't have forced a rushed PR review together with the product owner.
You'll just sound like a bitter, know it all.
I'm reminded of this every time I see some YouTuber or other social media click bait claiming that the Y2K bug was no big deal.
The reason it was no big deal is because thousands of graybeards, like myself, stayed up many long nights for months ahead of time making sure things would work.
I still remember the tension during the countdown to midnight UTC. Then the tension rising again during the countdown to Eastern time. Then once more at local time.
Only when it was 2000 in Pacific did we unclench our cheeks.
Guess we'll find out in 2038.
https://en.wikipedia.org/wiki/Year_2000_problem#On_1_January...
Lots of stuff didn't care about the day, too, like you'd get 0997 and that meant September 1st 1997 because the first (or last) of the month was inferred, and you'd get goofy logic around year++ where you add 100 years whenever you want to increment the month, and the whole thing is written as a modulo 1200 but whenever the date is about to be 0000 you look at what's stored in year instead and add one to it instead of 100, because that way you have less variables to allocate and every "little bit" counts.
Everyone knows now, but lots of people writing programs didn't have any prior art, they were just good at messing with computers and sort of fell into programming by accident.
https://en.wikipedia.org/wiki/Year_2038_problem
The same metric could be applied to "Days Since Last Stuff Up That Cost Us". It would be easy thing to apply to an office door or cubicle wall.
There is extensive writing on this subject http://rachelbythebay.com/w/2021/06/01/count/
Agile was literally about doing things quickly and quick cycles of capability improvement. But Scrum is a worse version of the planning processes it meant to replace!
If anything, the way scrum lays out the work into immediate problems exacerbates the cycle. In the long run it just turns into a ticketing system where fires get pushed up and technical debt gets pushed down.
It even spits out a super easy-to-track, meaningless set of efficiency numbers for consultants/executives to min-max!
I always thought this just meant to scrumble every week to get things done with a weekly standup?
The unit of work is even called a sprint because the idea is specifically to commit to very intense units of work.
I'm an engineer type, most of this makes very little sense to me.
Everything else, world-class, public, private, consultants or not... was a joke.
I don't think cross-team collaboration works in agile. Either one plans ahead, or everything becomes an unpredictable mess.
"b-b-but other teams need visibility of your sprint!" no they don't. I don't think I've looked at other board other than by accident.
You say this as if it was a coincidence.
I'm allowed to say such things. Some of my best friends are scrum masters.
I went to all the same meetings, and was still supposed to actually develop software in between them all.
Adding a bunch of processes because you want to add processes doesn't provide value.
You can see why. These people have to decide what will be worked on out of all the potential things that can be worked on. Someone has to make that decision. Will this feature make us money? What about that bit of work that doesn't add a feature but reduces resource costs? What about tech debt that I'm told is building up and slowing the ability to deliver features?
I'm not a senior manager, but ultimately someone up the chain is responsible for the company surviving and making money and paying our salaries. They are just like you and I, trying to make decisions based on what little information that can glean. So part of that is "what will this cost and how much will it be worth" vs "what will that other thing cost and how much will it be worth".
To that end, they need some way to estimate this. They latched on to agile as it was being promoted by tech as a way to do this. Whose fault is that?
And so with that came all the frequent estimations, are we on track, rituals, etc. Some people don't believe this should naturally follow. I agree. But somehow all those rituals have become part of the cult.
We abondanded scrum. We abandoned refinements and estimation of stories and story points etc. Now we meet with a PM once a month formally and as a team perform a t-shirt size estimate on where we are. Otherwise we update her as frequently as she asks (which isn't often) or we want. This gives power to us but because of that we're conscientious and make sure to inform her timeously when things are looking sketchy or whatever. Yes, we still have to give "estimates", because ultimately, senior management want to make decisions, but it is otherwise quite lightweight.
It is so liberating.