151–160 of 514 posts
Earlier quoted context omitted.
You’ve never wasted a few minutes on whether a ticket was “critical” or merely “high?” or truly a blocker?
I certainly have, but I have rarely regretted spending the time to prioritize my work before starting my work and/or discussing the same with my team. Like pretty much all work of all kinds, there is variance in how long it takes and how effective the outcome is per person-minute.
Earlier quoted context omitted.
It's brutal. You want to sound like an Office Space character. But in Office Space, there is no mission, there is no good engineering to do. So all the douche-y people who get in the way of work are more pityful than enemies. But here, you believe in good engineering yourself, and the -10x engineer you encounter get under your skin. So you're venting online about why you hate their guts (in a funny way, for sure, but…
There's a lot of projection going on here, as far as I can tell. The author is about as neutral as possible in describing these traits / behaviors. None of these traits are mutually exclusive with being a jerk, and in my experience, more often than not the people that exhibit these traits tend to also be jerks to compensate for their inability to get high quality work done!
Earlier quoted context omitted.
Make everything, even a 1 min fix a ticket and insist it's under right category and right project, the time is accounted for, and each developer have to report 8h time worked a day and you can have plenty of time wasted on ticketing
If you're making a change without saying what it is or how to test it, and not writing an automated test to cover it then that would be a problem. It might be 1 minute in code, but that doesn't mean it's a 1 minute fix.
> 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.
How long do your legs need to be? Long enough to reach the floor.
Does any of your manager, Product Manager, Project Manager, skip level, or teammates create unneeded communication overhead asking what the status of something is and when it will be done? A planning tool should communicate that.
Are deadlines being missed or visibility into what is actually being done missing? Planning tools should help with estimation and revealing how much complex work is being done.
In a lot of ways these tools are not going to make the work faster, but instead make it so that the human side is appeased. It reduces anxiety of managers, it creates an understandable evidence of work (most non-technical folks cannot tell the difference between a good and great implementation just by observing the app, but they can understand a ticket that explains a refactor). It drives alignment, communication, and buy in.
The fastest a developer can go is alone in a dark room with no interruptions. But that doesn't scale. Even if that engineer is a 10x engineer, you still need a different system when you want 11x development. That's when planning, communication, coordination, allocation etc. all come into play.
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?
Wait until they start adding additional categories like critical blocker, high blocker, severe blocker, exceptionally severe blocker, etc. etc.
> 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…
Earlier quoted context omitted.
Yes but I think people overestimate how automatable this actually is. Where we are context depends on if the audience is - * The next developer to pick up the task where you left off * Your technical lead asking for update * Your manager needing an update for his manager * Product management wanting to know where we are on some feature * End users wanting to know when the bug fix / feature they asked for will be in t…
Are your tickets even designed/written for consumption by product/management?
But very little detail on how one was technically to do the task, or time spent discussing technical options & tradeoffs.
However, exposure to cynicism and witch-hunting, such as labeling someone a "-10x engineer," can lead some people to become disillusioned and potentially adopt harmful behaviors intentionally. This can create a vicious cycle indeed.
Earlier quoted context omitted.
Emphatically yes, there's some really broken process out there. I sat on a team with 6+ hours per week of full-team, in a room, jira ticket creation/reviewing/sizing/prioritizing. So thats 15% overhead right off the top. This of course was not the only time we spent interacting with tickets, as we then had daily standup, random "check-ins" from product/management on ticket status, and of course actually picking, upda…
I understand developers’ complaints about this sort of thing and I am as much of a Jira-burnout victim as the next coder. But. How much time should a team be spending figuring out what the right thing to do is? Figuring out if the plan is still the right one? 15% honestly doesn’t sound like a number I would automatically assume is ‘too much’ for such activity. I’m not sure even 30% sounds like a crazy high number. Bu…
How much value do you get from putting 20 engineers in a conference room for 2 hours, 2-3 times per week? What if this is mostly just a head strong manager who enjoy monologuing his captive audience team?
Note I said "spent 30% of our time talking at high level management view about doing work rather than just technically planning & doing it" This doesn't really help prevent building things that don't fit together at all. It barely allows you to surface technical dependencies and order of operations.
Earlier quoted context omitted.
I agree with most of the author’s points, but the post is overly negative in my opinion. It’s blaming other people for the problems instead of digging into why these problems come up in the first place. Why do managers waste time with busywork? They need insight into the process. If you look to criticize without understanding you’ll always find plenty of material to blog about, but you’ll just create new problems and…
> The author probably thinks these issues are caused by bad people instead of bad processes Author here. This is an excellent way to phrase a subtle point that I couldn't figure out how to fit in the piece. I think that -10x engineering is not someone you are, but something you do. And even more commonly, it's something that organizations do for periods of time.