91–100 of 514 posts
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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?
Calling "deciding on how to spend your time" a waste of time seems a misnomer.
> "Waste 400 hours of engineering on bad architecture: Give zero consideration to how your system design will evolve over time. Alternatively, drive your team obsess over architecture decisions so that they don’t have time to test their hypotheses."
A complex project with many people working on it in different teams calls for modularization and well-defined interfaces, so working out the architecture up-front does matter, and changing it down the line will have huge costs. Staged progession is the answer, probably, which is why you'd want to have a meeting where everyone agrees, "this is the architecture we're going with, now everyone go build the modularized widgets that fit into this architecture, here are the stable interfaces to build to." Screw that up and you end up with tons of wasted effort, but dithering around and never making a decision is no better.
Some of the other stuff relates to the 'build team spirit' corporate mentality which is kind of culturally variable - some people love it and some people hate it. Minimal is better, IMO.
Then there's the 'basic technical proficiency' category of problems, e.g. recompliling the entire collection of source code every time you make a lttle change because the build configuration in the makefiles is incorrect etc. That's probably the easiest category to fix, some people just have holes in their knowledge and those can be filled. Here is where the company jerk is a major liability, though - you want people who can teach others how to improve their workflows without engaging in any condescending / egomaniacal / prima donna behavior.
A 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.
But bending over backwards for bad solutions just coz you "don't want to rock the boat" or "don't want to argue" leads to mediocre product driven by whoever happens to be least polite in the team. Tiny bit off stubborness and assholery on stuff you know is right (as in when nobody can provide actual sensible arguments for other way) can be very helpful.
Also I did worked with "toxic but brilliant" ones and honestly I vastly prefer it over nice useless people. Toxicity can be managed, uselessness can not.
> 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…
Off the top of my head these are the most common two "negative engineer" behaviors I have seen
1) Biggest one: an engineer who is not experienced at architecting complex systems, goes and architects one when complexity was not required in the first place. This is the key to never shipping and destroying entire companies.
2) Close runner up: an engineer who writes code that is inscrutable and therefore unmaintainable (always by others, often by themselves as well). This is the key to your product dying a slow death over several years.
There are negative engineers doing this stuff ALL. THE. TIME. EVERYWHERE. Despite unquantifiable volumes of both ink and blood spilled trying to prevent them.
A 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.
Step 11: Call out any attempt to make engineering more productive as toxic negativity.
Step 13: have a blogpost about how inclusive and equitable your company is.
A 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...
The author probably thinks these issues are caused by bad people instead of bad processes, which is why he doesn’t suggest realistic fixes.
Earlier quoted context omitted.
Rust may still be a bit too pragmatic, perhaps you could use a language you wrote yourself?
"Aaaand that's the container address orchestrator -- it's written in Haskell by that one guy a few years ago."