Omg, I knew a PM/Architect combo who fit the bill. Scary how quick they came to mind.
How to be a -10x Engineer
51–60 of 514 posts
Re: How to be a -10x Engineer
#52A 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 disagree. For me this outlines the caveats and pitfalls of software development and management. There is real truth to some of the authors points showing real paths that emerge naturally. If you're going to gaslight him by inferring anyone who is critical is an asshole, maybe you should ask yourself why you're taking the article so personally...
Well put.
Re: How to be a -10x Engineer
#53A 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.
Author here. I don't want to empower jerks. Anything particular I should change? Or is the structure of the essay too cynical overall?
The article is good at making a point of what is bad and for the fun of it. However, it is not successful at compassionately explaining what one should strive to instead as there is no simple negation of the points being made.
Re: How to be a -10x Engineer
#54> 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…
> Ticket management is not busy work, it's a necessity for everyone to keep updated.
I would say that rather depends on how much of it you do.
Re: How to be a -10x Engineer
#55The "don't rock boats" is really what can slowly destroy companies. The -nx engineers know a lot of other -nx engineers that can come onboard until the stable boat just sinks.
Sometimes things just need to fail naturally and some rando on a mission to “rock the boat” is a net negative. Picking your fights is an important thing to learn too, throwing a fit over everything “wrong” can be terrible for everyone… even if you’re right every time.
People have limited bandwidth. Especially, it takes a lot longer to fix something than it does to just point out that it's broken. You can be right in every problem you point out, but if you point them out all at once, nobody can fix all that. Pick one and point it out (preferably also suggesting a path to fixing it), and then work with people to get it fixed. Keep your mouth shut about the others while this is going on.
Re: How to be a -10x Engineer
#56Earlier quoted context omitted.
Anything written in interpreted languages like Javascript/Typescript. UI stuff usually has hot reloading where you get "compilation" times measured in milliseconds, and from experience restarting even a complex typescript server is a few seconds max. This applies to mobile apps as well when using React Native.
What about Gulp, NPM, Yarn etc. running in the new build of UI stuff? Those take up a bunch of time.
I don't quite get your point. Your parent was pointing out that there are interesting projects where the "compile" time is milliseconds — at least for the developer perspective. It doesn't really matter that there's a step later in the pipeline at takes longer, so long as it's not in your way. Also, most of that could be cached away anyways.
Re: How to be a -10x Engineer
#57> To ensure developers are context-switching, recompilation should take at least 20 seconds. I'm now wondering what languages and projects the author has worked on if they expect compilation to take less than 20 seconds. Maybe small-ish golang projects? I don't remember the last time I worked on something interesting where recompilation was always under a minute...
I worked hard on my previous project to achieve a 5sec build-run-test cycle for a medium-sized embedded C project (we don't have monster workstations, just some i7-10xxx/16GiB PCs).
Thinking about proper modularization, runtime code (hot-re)loading, and eliminating single-point-of-recompilation for header files goes a long way.
The gamedev industry figured this out a long time ago, see Handmade Hero's Hot reloading[0].
Also, an interactive shell (we use IPython) with all of the compiling and debugging utilities you need is easily a 5x efficiency boost, e.g. I can run `./devshell.py `, then `run('foo', 'bar')` and the script will compile, upload, and re-execute the `foo` and `bar` modules. Makes onboarding much easier too.
Re: How to be a -10x Engineer
#58"Explain code in private messages. Write wikis that nobody uses." What the reasonable alternative though? What's the happy medium?
>>Explain code in private messages.
...and this is the natural result of the 'no comments allowed in the code' nazi's that seem to permeate lots of organizations. For the life of me I could never understand that particular bandwagon.
I for one love it when I go back into my code after a few years and a few well placed comments remind me why I did what I did last time I worked on it.
Re: How to be a -10x Engineer
#59A 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.
Author here. I don't want to empower jerks. Anything particular I should change? Or is the structure of the essay too cynical overall?
don’t let the -10Xers get you down it’s a delightfully funny and insightful piece
Re: How to be a -10x Engineer
#60> 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…
> Ticket management is not busy work, it's a necessity for everyone to keep updated. I would say that rather depends on how much of it you do.
Oh, I see... I just assumed people read tickets and did the work and updated the ticket?
For example, I went through a dozen tickets this morning and 96% of my time was spent either writing updates or doing the work the tickets were talking about. 4% probably went to reading the ticket itself and placing it in the correct place after updates/work. That 4% means meetings later will flow faster, and I don't have to remember or write down details and statuses of things somewhere else.
Are people really wasting time on 'ticket management' that isn't as I've described?
Edit:
I've spent some time thinking about this, and despite being the org owner for our companies Azure DevOps instance I'm actually firmly in the 'Ops' camp of OpsDevOpsDev. My job is mainly Ops and I do some DevOps/SRE work on the side as the pragmatic-infrastructure-guy. I often see lots of nonsense done in the Developer camp. I think why I don't see the downsides of tickets is because I come from the background where tickets are more Help Centre-like. It's just pieces of work that needs doing or people need help with. If the help centre started arguing about if something is 'high' or 'critical' or spent 50% of their time just 'managing tickets' then they would flat-out just get fired. I guess that's the cultural difference between HC/Ops and 'Dev' that I wasn't really seeing before.