51–60 of 203 posts
A lot of wisdom here. The hard things are almost always more fun than the easy things anyway. > To get away with postponing, you need an excuse: other supposedly urgent work; This is shockingly easy in “shared resource” environments where team lines blur and management expects people to pitch in “where ever”. Just take on a tasks for manager A and B and play them off of each other.
> Under time pressure, the scope shrinks You may call it evil but I call it building the things that actually need to get done.
Simply prioritizing tasks correctly is all you really need to do. If you can't figure out what is important or not, default to order by descending difficulty. Get the team on a call and figure out hardest, 2nd hardest, 3rd hardest, and then assign those tasks. You will likely (but not always) find the trivial, "easy" shit wasn't that valuable to begin with - otherwise it would have been prioritized by the business an…
If you hire a consulting agency and for some reason they prioritize the easiest and most known task...
You still have no evidence they can complete the hard thing.
This works until your boss understands software development
At my last job I made a feature to deploy arbitrary user code (most likely a trained model in Python) to a subdomain running a JS server that could take input parameters when called at that URL and would respond with the answer from the model. This effectively cut down DS deployments from potentially days to about 45 seconds. It was seen that be hard and I had a good amount of help from our awesome devops person and…
It's sort of like how it's better to be a firefighter than a maintainer, which is guess is the point. The ease may be similar, but coming in to save everyone from an explosion gets you more points than oiling the valve every day so pressure doesn't build up in the first place. It's a cultural issue that is very hard to combat.
A lot of wisdom here. The hard things are almost always more fun than the easy things anyway. > To get away with postponing, you need an excuse: other supposedly urgent work; This is shockingly easy in “shared resource” environments where team lines blur and management expects people to pitch in “where ever”. Just take on a tasks for manager A and B and play them off of each other.
Yes, there are a lot of dysfunctional organizations out there. That's a strategy that might yield short term financial success and entertainment value, but it's probably not helping out the organization.
Earlier quoted context omitted.
This is really easy to say, but having done pretty much exactly this for ages, finding management that doesn't take advantage of you in this regard is really rare.
what industry/country are you in?
Low level programming, on the other side, does not have a lot of openings. The majority have to do those hard "easy" problems for their life.
Earlier quoted context omitted.
I will say as someone who has to wrangle a lot of junior devs -- don't have imposter syndrome on this. The hard part is sticking with the issue and seeing it through to the logical conclusion. Many people have difficulty even conceptualizing the steps that need to be taken in order to solve a problem. If you are smart enough to get help from someone in devops and understand the advice they gave, you're doing the same…
computing is a fraud, a CPU is literally a rock that we tricked into thinking
It is hard to punish people for working hard and fixing something, when they are fixing something they created that was crappy from the start! And then the team that is highly-tuned and made a perfect design from the start shows very little improvement because it is already perfect. The indicators flip the script and make it hard to decide who actually deserves accolades. The correct answer is that they both do: one team for figuring out their mess, the other team for executing flawlessly. But the flawless people, in my experience, tend to have big egos and are offended by the seemingly equitable treatment.
The part about ego trip is the "always looking out for yourself." On the one hand, you have to promote yourself, on the other hand, you're part of a team. And manipulating the system to make to make sure you get preferred assignments backfires spectacularly. Which is why those folks tend to switch companies a lot.
I'm ambivalent about this. It can be taken as some tips as how to be be assertive by not getting shafted by evildoers like the author (remember that debate from last week on HN?), which are healthy. But there's also a lot of "me first" that'll get you shivved in the long run.