A friend of mine accidentally wiped out over 100k hours of other researcher's computing operations the other day, does that make him a -100,000x engineer?
No. You'd call him unemployed.
How to be a -10x Engineer
211–220 of 514 posts
Re: How to be a -10x Engineer
#212Earlier quoted context omitted.
I understand developers’ complaints about this sort of thing and I am as much of a Jira-burnout victim as the next coder. But. How much time should a team be spending figuring out what the right thing to do is? Figuring out if the plan is still the right one? 15% honestly doesn’t sound like a number I would automatically assume is ‘too much’ for such activity. I’m not sure even 30% sounds like a crazy high number. Bu…
> Figuring out if the plan is still the right one? 15% every week is the problem here. If you spend 10% of your annual budget on upfront planning and 5% monthly on checkins, that's maybe ok. Putting the whole team in a room every week is just going to churn the plan constantly - inputs likely aren't changing with that frequency, and you aren't going to be able to pull in all the other stakeholders that often anyway
> Putting the whole team in a room every week is just going to churn the plan constantly
Yes, that's the point, that after each week (or two) of work, we've learned more and the plan already is outdated and needs to change.
> inputs likely aren't changing with that frequency
In my experience, they absolutely are unless you're building the simplest CRUD app that's identical to one you've built before. The inputs are less often changes from external stakeholders, and more often tasks that are turning out to be more difficult than hoped.
> and you aren't going to be able to pull in all the other stakeholders that often anyway
Of course you are. It's the PM's job to gather the new inputs, go check in with relevant stakeholders (takes a day or two at most), update or re-confirm their priorities, and then make the updated decisions for the next sprint.
In my experience, 15% of time spent each week on planning is about right. It doesn't maximize the productivity of each person coding, but it hugely maximizes the productivity of the whole team in delivering a valuable end result.
Re: How to be a -10x Engineer
#213A lot of toxic negativity in that post. Sure bad engineers exist, but you know what is even worse than the -10x engineer: the contagious jerk. https://www.inc.com/jessica-stillman/studies-being-a-jerk-is... Yep being an asshole spreads like a disease within organizations. Avoid these guys like the plague.
I worked with one person who weaponized pedantry. He thought he was educating everyone by being a complete stickler for his specialized vocabulary and would never just answer a bloody question, wasting everyone's time. He thought he was Socrates but he was the hemlock. Similar to a good project manager he was like a chain-saw: very effective, but you always want the tool pointed away from you. It also meant you really thought about whether you could get what you needed done with any other tool rather than pull out the chainsaw. Ultimately this kind of behavior is a productivity sink; forcing everyone into your rules because it'll be so much better when everyone just complies with how you need the world to be means getting worked around and giving the pedant's work to someone more pleasant to work with.
Please note: I'm not dinging people who sincerely need structure to help them function. This was a conscious choice just to be a jerk because in that person's opinion everything would be great as soon as we all thought exactly like he did.
Re: How to be a -10x Engineer
#214> Make undebuggable programs. Plaster layers of abstraction over everything. Write spaghetti code. Make everything sensitive to initial conditions. Avoid pure functions. Use dependencies liberally. Say “it works on my machine” whenever possible. A lot of legacy software is like this. I wonder how many billions it costs the economy per year.
The more difficult situation is the legacy software with all of those problems that actually makes money.
Re: How to be a -10x Engineer
#215I might be skipping the competence part but personally my performance has been directly correlated to how much I care about my team/org. My attention is focused and goal oriented in a proactive way when I do care but passive and reactive when I just want a paycheck. I don't have good advice to spot how people care so its not super helpful but people that don't attempt to help in hairy situations or seem withdrawn from conversations are probably not on the good end of things.
Re: How to be a -10x Engineer
#216Earlier quoted context omitted.
You didn't say it outright, but it was exactly what I inferred from your comment as well. You said "toxic negativity" which comes across as a moral judgement, and anything that follows comes across as the result of that judgement.
It was a judgement. I do think the author is being a jerk here. But people can be critical without sounding like jerks.
I don't think it's reqlly fair to read a person's frustration piece and assert they probably have a character flaw. I don't even see your issue with the article, really. I don't think it's targeting anyone specifically and it seems to be about doing things in excess. Maybe just the idea of people who are consistently negative contributors rubs you the wrong way.
Re: How to be a -10x Engineer
#217Good list but it's It's missing: - "use an new, different and exciting technology for each new project, however small"
The self-appointed "10xers" see this as a sign of greatness.
Re: How to be a -10x Engineer
#218> Ask your team to perform tasks that resemble work. Common examples include presentations, diagrams, and ticket management. I'm as salty as the next guy, but in my experience it has been the sub-par employees who are the ones that don't do this. Ticket management is not busy work, it's a necessity for everyone to keep updated. Presentations and diagrams are tools to communicate. I can safely say that by far the most…
I'm going to go out on a limb and suggest that the author probably thinks a healthy balance exists between zero communication and spending 100% of one's time playing JIRA games and visibility hacking.
Agreed. I think the nuance got lost here. "Typical examples" is the key phrase here.
Not all presentations are created equal. Text you throw on a slide in 10 min to guide a 1 hour conversation, versus trying to make everything pixel perfect for 40 hours prepping the deck for the public. Ticket management is critical, but do you really need to spend 4 hours doing it each day?
Re: How to be a -10x Engineer
#219Earlier quoted context omitted.
> "you know those sorts of geniuses that are so far ahead of everyone else that they can't even explain things, and no one else can quite understand it?" Richard Feynman was certainly a genius and he was well-known for his ability to explain complex topics in ways laypeople could grasp.
I don't believe a fellow is clever, unless he can explain his clever thoughts clearly. Feynman was seriously clever.
Yep, someone smart enough to come up with something should also be smart enough to be able to break down and explain what he came up with.
Re: How to be a -10x Engineer
#220Earlier quoted context omitted.
You’ve never wasted a few minutes on whether a ticket was “critical” or merely “high?” or truly a blocker?
I certainly have, but I have rarely regretted spending the time to prioritize my work before starting my work and/or discussing the same with my team. Like pretty much all work of all kinds, there is variance in how long it takes and how effective the outcome is per person-minute.
These categories on ticket have little to do with me prioritizing my work. There are thousands tickets in each of those categories.
>spending the time to prioritize my work before starting my work and/or discussing the same with my team
And in the past, I did regretted opening unnecessary discussions quite a few times. I learned not to do it, because it ended in endless bike shedding or conflicts and there were no special gained insights. Turns out, I can do trivial decisions by myself.