This does underline a key point. Avoid unnecessary perf hits in your workflow. The whole Interstellar meme of "this little maneuver is gonna cost us 10 years" is very much true. I've worked on high performance teams that did the wrong thing strategically and it ended up effectively slowing down their pace massively. It doesn't matter how fast you're running if you're running in the wrong direction.
How to be a -10x Engineer
61–70 of 514 posts
Re: How to be a -10x Engineer
#62Earlier quoted context omitted.
> 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 rem…
There are definitely corporate cultures where updating ticket status at regular intervals is higher priority than actually working the problem in the ticket.
Re: How to be a -10x Engineer
#63Thanks for sharing! I'll start putting everything here in practice immediately. Some of these are already widely practiced at the company I work for, though, so I probably won't stand out too much.
> Mock function calls until no original code runs.
This one hurt personally. I didn't write it, we maintain it, but we have no time to go back and write real tests.
Re: How to be a -10x Engineer
#64A 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?
Software needs to be used by users. It’s unlikely your developers are so innately talented that everything a user wants to do is obvious and intuitive. So docs, etc matter.
Other teams like marketing need to make schedules because they spend huge amounts of money doing things to make your product successful, that have nothing to do with code. For example, launch events, advertising, conferences, executive briefings for key customers, etc. Planning, dates, progress reports, etc are all needed because unless you are a lone open source developer, you have to work with others.
Users will use your software in unexpected ways. Hackers will try to break it. And users will expect it to work flawlessly when they need to use it to generate their report for their VP meeting in 5 minutes. Testing is critical to ensuring that your software doesn’t suck for your users and make them hate you.
The business you work for probably doesn’t exist with the mission to leave you alone and let you code. They want to solve a customer problem by creating, marketing, selling and/or supporting a software product. Your management wants to know that all the money they are spending on your salaries is getting them a positive ROI. Letting them know what you’re doing and providing them with content about capabilities and features that can be used in marketing, makes them want to keep paying you. Missing deadlines, failing to deliver non-code deliverables, failing to provide status, and being jerks in general make management want to cut your project (and maybe your job) and do something else with cooperative people.
Yes, there are pathological extremes to all of these things and to the points you raised in your post, but I see too many developers who think that developing software is just about coding and that everything else is extraneous. In reality, the vast majority of your time is probably best spent NOT coding.
[ed] spelling, paragraph break
Re: How to be a -10x Engineer
#65Earlier quoted context omitted.
> 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 rem…
You’ve never wasted a few minutes on whether a ticket was “critical” or merely “high?” or truly a blocker?
Re: How to be a -10x Engineer
#66"Explain code in private messages. Write wikis that nobody uses." What the reasonable alternative though? What's the happy medium?
Zero effort solution is to have permanent group chats so background info like discussions on requirements are searchable.
Re: How to be a -10x Engineer
#67The "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.
To extend the boat analogy, I suppose it's impossible to know the stability of a boat without rocking it a bit.
Re: How to be a -10x Engineer
#68A 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?
Re: How to be a -10x Engineer
#69> 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 suspect that the presentations and diagrams which need to be made, are made. Good communication is important, but the artefacts come about from the organic need to communicate an idea rather than orders from on high.
Consider "The Bar team wants to know about our new Foo architecture" vs "The Bar team needs a 30 minute presentation on our new Foo architecture". Does the Bar team actually need a presentation, and could it be a live demo? Do they just need better documentation? Are they building an integration, and would someone from your team working with them for a week unblock them in a way a presentation wouldn't? Could this be a ten minute call between you and the one engineer who needs a hand?
Good and experienced engineers do their best work on open-ended tasks. This is as true of communication as it is solo work. Artificially dictating the solution without understanding the problem limits them.
Re: How to be a -10x Engineer
#70I don't agree that writing and communicating designs, plans, and discussing problems or solutions is a waste of time. Our job isn't to blast code out and not talk to anyone (unless you're the sole developer on a project, but even then you should still write). Writing is thinking! Thinking is our job. Code is the artifact.