311–320 of 514 posts
Even when you are at the best team, culture-wise and productivity-wise, accept that this will not last. All it takes is for 1 person to arrive/depart to ruin the culture.
Just do your best and bounce when it's time. You cannot move Mount Fuji with a teaspoon.
> 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…
Yeah that was an interesting read. I like the concept of a -10x engineer because they definitely exist (in my mind it is someone whose work moves you farther away from the project goals, rather than closer to them). But a lot of the bullets sounded like stuff bad managers do, not bad engineers. Off the top of my head these are the most common two "negative engineer" behaviors I have seen 1) Biggest one: an engineer w…
This is my biggest pet peeve of them all. I tell wet-behind-the-ears engineers "always strive to make the life of the next person to touch the code easier, even if only because the 'next person' will probably be you."
Earlier quoted context omitted.
The solution is that the one who write the software/architecture is also the one maintaining it. When it comes to writing easy to maintain code, that can only be learned by maintaining code for a long time. If that dude leaves the team and you have no one that can edit it, just rewrite the code from scratch! So you basically want to follow the Unix philosophy or micro service architecture. This allows you to hire any…
"Rewrite from scratch everything that engineer X touched in four years of working here after he leaves" does not sound like a feasible approach to development. Also, while having good code separation between contractual APIs is a good goal and worth pushing towards, the idea that nobody would ever have shared ownership of any code unit between API contracts is too extreme.
Personally, through decades of experience, I've learned that when this impulse hits me, I need to consciously remind myself of these truths:
1) The engineer(s) that wrote the offensive code were almost certainly not idiots. The code is probably that way for a reason, even if that reason isn't obvious to me.
2) If I embark on rewriting it "correctly", the odds are very good that I will learn why the code was as it was in the first place, and my rewrite will undoubtedly have my own style, but will not likely avoid whatever issue it was that made me think it should be rewritten.
Does it bother anybody that he is promoting his own article by posting it? I have seen this and many other comments by this user as what seems like a funnel to book time with him and eventually be a paying customer. I am not sure how I feel about this.
Earlier quoted context omitted.
Yeah that was an interesting read. I like the concept of a -10x engineer because they definitely exist (in my mind it is someone whose work moves you farther away from the project goals, rather than closer to them). But a lot of the bullets sounded like stuff bad managers do, not bad engineers. Off the top of my head these are the most common two "negative engineer" behaviors I have seen 1) Biggest one: an engineer w…
And the problem our industry has is that these concepts are not well-defined. You can easily have engineer A strongly claim that the code that was put in front of them from engineer B is terribly designed and will be unmaintainable and then they write an alternative proposal that they love, and then the next guy C comes with the exact criticism of the alternative, and the twist is that C is actually B, the guy who wr…
Something something memory allocating llamas cough.
> Attract bright engineers and waste their potential. Undersell the difficulty of the project to management; oversell the project’s usefulness. Tell management it’s “almost complete” until they scrap it. People at every level of the organization, from the top-down, have done this since forever. The -10x engineer will choose a language that they're fascinated by, but have no production experience with, and then spend…
The desire to add $TECHNOLOGY to run a relatively small site even though it will likely never scale beyond what a single postgres instance running on a mac mini can handle.
I got burned out and lost a few years of my life due to a job like this. We had two things: a. Poor systems and poor communication permeated the IT department b. IT was viewed as a cost center so no amount of heroic intervention was ever rewarded proportionately to business impact. It was Sisyphean. If you are in a situation like this, please run away. You can't win - either the free market will destroy your employer…
Serious question: isn't it always?
claim high-value projects/tasks, but don't finish them. when another team starts working on the same problem, schedule a meeting over their head and tell the other team's director level that you're already working on it and it's a waste of resources for multiple teams to work on this simultaneously.
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.
Sometimes requirements are unclear and you just have to learn as you go. Sometimes the AWS bill is the last of your porblems. Sometimes you find out something you had assumed at the outset is wrong, but you still believe in the project. It's context dependent.
Also, it's often more difficult to be the person asking the hard questions than the person who just goes along with things.
> 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…
Yeah that was an interesting read. I like the concept of a -10x engineer because they definitely exist (in my mind it is someone whose work moves you farther away from the project goals, rather than closer to them). But a lot of the bullets sounded like stuff bad managers do, not bad engineers. Off the top of my head these are the most common two "negative engineer" behaviors I have seen 1) Biggest one: an engineer w…
I have dealt with opposite - a monolith-based company grew to a point where more complexity was required, but none of the engineers there seemed to have been equipped with an iota of distributed systems knowledge.
The "senior" and "staff" engineers obviously built something, and everyone was still monkeypatching out all the consistency issues 5+ years later, and some of them were still around declaring that there are no issues.