Live data from Hacker News

Doing too much work on one's own before looping in others

thezbook.com

151–160 of 395 posts

Re: Doing too much work on one's own before looping in others

#151

Earlier quoted context omitted.

> I've been doing this longer than some of my managers have been alive. In what organisation do 25 year olds manage 50 year olds?

A lot. Technical managers need not be experienced technical talents who have made a potentially incompatible shift to management.

It is better if the managers of technical people are technical themselves. Otherwise you wind up with the Dilbert "pointy-haired-boss" syndrome. The non-technical manager is extremely easy to bullshit, so it's better for the company in almost all ways.

Re: Doing too much work on one's own before looping in others

#152
post #55

Earlier quoted context omitted.

You are not wrong. I generally sell as a mercenary, and prefer it that way - I've been doing this longer than some of my managers have been alive. I'm paid just as well if they want to "pair program" or jira the whole process, but yeah, you hired me to fix a problem - if you are the problem, I get paid just the same. Welcome to the real world, if your work is interesting, the clock might not turn on when I'm having f…

> I've been doing this longer than some of my managers have been alive. In what organisation do 25 year olds manage 50 year olds?

In a previous job I was team lead of a team that had a person in they're 40s and one in their 50s, I started as lead as a 23 year old and moved on when I was 30. There are many things I'd do differently now, but it was an effective and impactful mostly high functioning team. It does happen.

Re: Doing too much work on one's own before looping in others

#153
post #79

Earlier quoted context omitted.

> It also offers chance to produce memorable work as nobody remembers the set of 3 point tasks you completed ten sprints ago. This is one of the more toxic ones. To get past senior, you often need to be seen to do Big Memorable Things. It sometimes leads to perverse incentives.

I mean it's not that toxic, if you are a good worker bee your manager will usually notice and be happy with your performance. Then from time-to-time you branch off to do something more high-risk to add to your promo doc. I think a lot of people have weaker communication skills than execution skills. So they could loop in everyone early on, but their idea might get killed off because they failed to justify it properly…

>"if you are a good worker bee your manager will usually notice and be happy with your performance"

And other than some bonus never promote you. If you have capability to be anything above that "worker bee" say / ask exactly what you want. If not look for another job. While this SCRUM / Agile bullshit is wide spread and even works in some specific circumstances there are enough companies that are not hung up on moving pins on dashboard and where one can really grow.

Work for yourself. Work with the manager, not for manager.

Re: Doing too much work on one's own before looping in others

#154

Earlier quoted context omitted.

I'll be honest - half the time it's trying to keep it from other engineers who are overly eager to have an opinion because a) they're low-output and looking to posture, and/or b) or want things to be done a different way. At least the business side of the house appreciates the spec'd work being accomplished.

Intentionally not communicating things in order to prevent bikeshedding is a dangerous game to play and a symptom of a broken environment, but that doesn't mean it's not sometimes a valid approach.

Agree - and it 100% comes from broken teams/environments/people. In engineering, I find most teams are more invested in tearing each other down more-so than building each other up - that's admittedly very anecdotal and personal to me.

Re: Doing too much work on one's own before looping in others

#155
post #73

I'm the author of the post - would love any feedback / similar experiences / contrasting opinions!

The description of the "problem" is that the requirements specified in the beginning were wrong, and then the developer is blamed for solving exactly what was specified, and not constantly asking management every day "have you changed your mind?". I don't understand at all, how this is the fault of the developer, talk about expecting the developer to bend over backwards for any product manager. How is it not reasonab…

Non-trivial problems often require exploration of the solution space. You're not expected to ask management if they've changed their mind, you're meant to present your finding so far, and ask if they have any feedback.

Simply stating that you did as instructed is not a viable excuse for a human, that's not what they're paying you for. Computers can get away with it.

Re: Doing too much work on one's own before looping in others

#157
post #153
post #79

Earlier quoted context omitted.

I mean it's not that toxic, if you are a good worker bee your manager will usually notice and be happy with your performance. Then from time-to-time you branch off to do something more high-risk to add to your promo doc. I think a lot of people have weaker communication skills than execution skills. So they could loop in everyone early on, but their idea might get killed off because they failed to justify it properly…

>"if you are a good worker bee your manager will usually notice and be happy with your performance" And other than some bonus never promote you. If you have capability to be anything above that "worker bee" say / ask exactly what you want. If not look for another job. While this SCRUM / Agile bullshit is wide spread and even works in some specific circumstances there are enough companies that are not hung up on movin…

> Then from time-to-time you branch off to do something more high-risk to add to your promo doc.

I agree, that's exactly what I wrote.

Re: Doing too much work on one's own before looping in others

#158
I'm honestly surprised Jeff Atwood's excellent blog post about this hasn't been linked. [0]

From his article: "It's effectively impossible to go dark if you're practicing any form of agile software development."

There are a lot of psychological reasons to "go dark", but very few (if any) solid business reasons.

[0] https://blog.codinghorror.com/dont-go-dark/

Re: Doing too much work on one's own before looping in others

#159
post #52

Earlier quoted context omitted.

I'm curious, what about that semantic differentiation is confusing for you? At least in my experience, "Software Engineer" is a standard title for the kind of work the author is describing in the article and is often used interchangeably with "Developer".

I think they mean generally. And I tend to agree. I had suspicions while reading it but wasn't completely sure till I checked the Author's bio on the right. Some, if not a lot, of it doesn't apply well if at all the the "classic" fields of engineering, where engineers tend to be much more focused and trained in their skills.

there's no classical software development engineering so depending where you were trained (web startup vs. software company vs. deep in the bowls of a huge corporation etc.) you could have very different ideas of normal - see eg: https://www.stilldrinking.org/programming-sucks

Re: Doing too much work on one's own before looping in others

#160

To be honest, I don't think this is any of the engineer's fault. I think we're an open creature by nature; we like to share and explore ideas with others. In the corporate field, what I've observed is that deliveries are most important. Not just any deliveries, but the project has to be big and "impactful" (as in, other teams use it too), and you personally have to own it. Like your name has to be attached to it. No…

> Imagine if we didn't have that kind of pressure of delivery in the workplace just to get recognition. While the places I have worked might have a tiny element of this your situation sounds extreme. What I have seen is yes you do have to do “perception” management to keep a pulse on “how am i rated”. Having a few long time trusted people vouch “this person is good” helps and all you need to do is work with them and…

I should clarify this behavior is mostly at larger companies... and although it's my anecdotal piece, it is what I've consistently seen at different companies and what my friends tell me they've experienced at other large companies. I've also worked at smaller places and this behavior was not as prevalent since everyone knows everyone on the dev team.

Also, at larger companies your manager tends to reorg. I've gone through 5 managers in a single year before. And with them goes all the goodwill you built up during that time. New manager comes in, and it basically resets your 'perception' factor. The old manager might tell the new manager that some people are good, but you have to get lucky to get the new manager to care, because they haven't seen the results with their own eyes yet. That small time window is when it's ripe for someone to swoop in and claim ownerships of projects, while smooching up to the new manager. That's what happened with the senior dev I saw, but he had aces up his sleeves. What an epic showdown.

Yea, I should leave probably, but it's just one burning ship to another. That's our fundamental reality.

Post reply on HN