How to be a -10x Engineer

Step 16 skip step 16.

step 17 Recognize that questioning the status quo is a critical part of progress and growth, and that "toxic negativity" is often a label applied to dissenting voices to silence them.

step 18 Acknowledge that engineering, like any other field, can benefit from improvements in productivity and efficiency.

step 19 However, also acknowledge that a singular focus on productivity can lead to shortcuts, neglect of quality, and burnout among engineers.

step 20 Question any proposal that seeks to boost productivity without considering its potential drawbacks or unintended consequences.

step 21 Encourage open and honest discussions about the tradeoffs involved in increasing productivity, and welcome feedback and criticism.

step 22 Remember that criticism is not the same as negativity, and that constructive criticism can help identify problems and find solutions.

step 23 Avoid dismissing criticism as "toxic negativity" or labeling critics as "problematic" without engaging with their ideas.

step 24 Recognize that diverse perspectives and voices are essential to a healthy engineering culture, and that dissenting opinions can lead to innovation and progress.

step 25 Cultivate a culture of respect and openness, where all voices are heard and valued, and where criticism is welcomed as an opportunity to improve.

step 26 Challenge assumptions about what constitutes "productivity" and explore alternative approaches that prioritize quality, sustainability, and employee well-being.

step 27 Remember that engineering is a human endeavor, and that the well-being of engineers and the communities they serve should be a top priority.

step 28 Take a shortcut and jump directly to step 42 for your surprise.

step 29 Recognize that productivity gains should not come at the expense of ethical considerations or compromises in safety standards.

step 30 Encourage ongoing learning and professional development among engineers, so that they can remain up-to-date with the latest technologies and practices.

step 31 Ensure that engineers have access to the resources and tools they need to be productive, without sacrificing their mental or physical health.

step 32 Celebrate successes and learn from failures, without casting blame or assigning fault.

step 33 Remember that productivity is just one aspect of a successful engineering organization, and that teamwork, collaboration, and communication are equally important.

step 34 Foster a culture of trust, where engineers feel empowered to speak up and share their concerns without fear of retribution.

step 35 Recognize that engineering productivity can be influenced by external factors, such as economic conditions or resource constraints, and that some challenges may be beyond an individual's control.

step 36 Encourage interdisciplinary collaboration and cross-functional teams, to break down silos and encourage a diversity of ideas and approaches.

step 37 Always be open to feedback and criticism, and recognize that even the most successful organizations can benefit from continuous improvement.

step 38 Emphasize the importance of work-life balance, and support policies that allow engineers to take breaks, recharge, and avoid burnout.

step 39 Encourage knowledge sharing and collaboration across teams and departments, to foster a culture of continuous learning and improvement.

step 40 Seek to understand the root causes of any resistance to productivity improvement, and engage in constructive dialogue to address those concerns.

step 41 Consider the long-term consequences of any productivity-enhancing measures, and make decisions that promote sustainable growth and development.

step 42 Realize that in this message only steps 16, 28 and this one where not generated by ChatGPT.

A lot can be done, even in languages that compile quite slowly, to get good performance in practice. See, for instance, what one can do with bazel and build servers. A cold compile is still not going to be good, but you'll never do a cold compile, and it will be very rare to recompile something that will require changing the entire tree.

At an old job, we had files that were slow enough that we'd have them in a separate compilation unit (automatic derivation of typelcasses with multiple serialization schemes) , so if you didn't change them, you'd just be picking up the binary. And if you were changing them, you weren't changing anything else, so ultimately a very slow compilation step was never a thing.

But yes, it's a matter of investment that few companies are willing to make

My experience with weekly ticket grooming is that most of the time we spent 1-2 hours talking about the exact same tickets we talked about last week and left everything in the exact same order as it was when we started. When working on quarter+ long projects there just wasn't anything that changed week-to-week, and when things did change the actual planning to adapt to that was done immediately, not in the weekly meetings.

As I've become more experienced as a programmer, I've grown to hate unit tests that rely on mocks. They don't test a damn thing and they calcify code by making it a chore to update, since you have to update all the useless tests that don't do anything too.

>I find that the article hides a deep aggressivity towards overall mediocrity behind a thin veil of office-space-like humour. And I think that aggressivity is contagious and so not a good thing to spread

The post came off to me as frustrated not aggressive. I think you are overreaching here, and this can create very toxic environments as well. Disagreements, frustrations, and stress are just part of being a human. They're part of getting work done. Being toxically negative or positive is not a good thing both in the workplace and out of it, and this post was not aggressive, just being frustrated. Frustration can be good! It signals things that we need to talk about, so we can focus more on them. Hiding them only makes the problem worse.