Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

thezbook.com

Post reply on HN
Print view View original

251–260 of 395 posts

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

#251

Post by TameAntelope »

Trasmatta wrote: post #248
TameAntelope wrote: post #237

Earlier quoted context omitted.

What do you think of the idea that providing finished work on an every-day-or-two cadence allows you to collect feedback from your customers in a way that keeps your work focused and relevant to their needs?

You can gather plenty of useful feedback to keep your work focused and relevant on cadences other than one or two days. What kind of customer even wants to provide feedback that often? That sounds awful, not to mention being a poor user experience, where users are treated like beta testers, with half baked features constantly pushed out the door. This also ignores the fact that there is a huge amount of important wor…

There is no such thing as work that's absolutely crucial and not customer facing, so it makes perfect sense to disincentivize work that's shaped as you describe.

And before you try to list off work you think fits this category, I urge you to think about how that work could affect a customer's experience.

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

#252

Post by TameAntelope »

yibg wrote: post #226
TameAntelope wrote: post #218

Earlier quoted context omitted.

You shouldn't be figuring any of those things out on your own, is the whole point of both the article and my comment.

Possibly in an ideal environment. But expecting the same someone to work with me for an entire week to either debug or design usually hasn't been realistic. Keep talking with different people, or the same person on and off has a huge context cost. What I've found to be a good middle ground is take some time to think things through myself first, at least in rough strokes. Then have someone else come in and review the…

I'm confused about why you're suggesting the only options are "work together for an entire week" or "don't keep anyone updated about what you're working on for a week".

There are a lot of ways to keep your team updated, but more importantly, it's frankly arrogant to think you can or even should tackle any problem on your own.

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

#253

Post by Kaze404 »

Trasmatta wrote: post #53

I'm good at working on a team and looping in others. I also find it to be one of the most exhausting parts of software development. It's so difficult to constantly need to get feedback and buy-in from other people, and takes away a lot of the creativity and joy in programming (for me). Which isn't to say you shouldn't do it, just that it's one of the things that makes me dislike working on a team. I actually think th…

> It's disempowering to feel like you're never able to make a decision yourself, despite supposedly being hired for your expertise in the field.

I'm going through exactly this at the moment. For reasons HN will probably consider fiction, my superiors have started treating me as a toddler that needs oversight on every single decision that needs to be made.

It's something I've been dealing with in therapy, and the way I was able to explain it to her was by saying that I feel like the monkey in the infinite monkey theorem. Never thinking about what you're producing (if you can call it producing at all), just pressing buttons.

It makes me wonder what the point of having me even is, considering they spend so much time solving all my problems for me. I've come really close to saying "ok, go ahead and let me know when it's done" during 40 minute meetings where every minute detail of what I'm supposed to do is discussed by 3 people.

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

#255

Post by Trasmatta »

TameAntelope wrote: post #251
Trasmatta wrote: post #248

Earlier quoted context omitted.

You can gather plenty of useful feedback to keep your work focused and relevant on cadences other than one or two days. What kind of customer even wants to provide feedback that often? That sounds awful, not to mention being a poor user experience, where users are treated like beta testers, with half baked features constantly pushed out the door. This also ignores the fact that there is a huge amount of important wor…

There is no such thing as work that's absolutely crucial and not customer facing, so it makes perfect sense to disincentivize work that's shaped as you describe. And before you try to list off work you think fits this category, I urge you to think about how that work could affect a customer's experience.

I didn't say "not costumer facing", I said "invisible". A lot of important work is something a customer will have no idea exists until it goes wrong. If you've done your job right, it will remain invisible forever.

Because it's invisible, what's the point of arbitrarily shipping it in one-to-two day chunks to "gather user feedback"? Be willing to take the time to do hard things right. I'm not proposing you spin your wheels for ages on something, and I'm generally in favor of shipping early and often, it's just trying to fit every different shaped problem into the same process that doesn't work for me.

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

#256

Post by coryrc »

davidhyde wrote: post #38

> "the biggest mistake I see engineers make is doing too much work on their own before looping in others" > "For more senior engineers, it can happen because they like to work on their own and may be overconfident in finding solutions. It can also happen if the team culture is toxic and engineers fear getting criticism early in the design process." Not saying the above statement is incorrect but here is an alternativ…

Or, you work at an organization which gates promotion on leading projects, so everyone has to lead things.

Or your organization relies on "consensus" or "influence" to get any project done, and one of the groups (which don't share managers back to the ceo) doesn't want to do the project even though the others think it is important. So do you spend months trying to convince them while doing nothing promotion-worthy in your own?

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

#257

Post by TameAntelope »

Trasmatta wrote: post #255
TameAntelope wrote: post #251

Earlier quoted context omitted.

There is no such thing as work that's absolutely crucial and not customer facing, so it makes perfect sense to disincentivize work that's shaped as you describe. And before you try to list off work you think fits this category, I urge you to think about how that work could affect a customer's experience.

I didn't say "not costumer facing", I said "invisible". A lot of important work is something a customer will have no idea exists until it goes wrong. If you've done your job right, it will remain invisible forever. Because it's invisible, what's the point of arbitrarily shipping it in one-to-two day chunks to "gather user feedback"? Be willing to take the time to do hard things right. I'm not proposing you spin your…

If it impacts a user negatively if it's done wrong, that sounds pretty damn visible to me. I can think of plenty of ways to show a customer how we fail gracefully or not at all despite certain negative events. Some customers may even value that very highly, depending on the use case.

And I get that this idea may not work for you, but it works for a lot of very successful people, the luminaries of our field. You're arguing against Ward Cunningham, Robert C. Martin, James Shore, Martin Fowler, Joel Spolsky, Jeff Atwood, Bill Wake, Andrew Hunt, Dave Thomas, et. al.

Customer collaboration over contract negotiation. [0]

Who should I listen to; you, or them?

[0] https://agilemanifesto.org/

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

#258

Post by paulcole »

lostcolony wrote: post #210
ipaddr wrote: post #165

Earlier quoted context omitted.

An experienced manager is not easy to bullshit regardless. Sometimes a non-technical manager is better for many reasons. Having business domain experience can be just as valuable

I have encountered non-technical managers who were good, but in every case they would have been better still had they had some technical background. I have encountered technical managers who were not good, for various reasons. I think having a technical background is always a benefit, HOWEVER, it is neither necessary nor sufficient for being a good manager.

The same is true of software engineers. Every single one of them would be better if they had more of a non-technical background.

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

#259

Post by Trasmatta »

Kaze404 wrote: post #253
Trasmatta wrote: post #53

I'm good at working on a team and looping in others. I also find it to be one of the most exhausting parts of software development. It's so difficult to constantly need to get feedback and buy-in from other people, and takes away a lot of the creativity and joy in programming (for me). Which isn't to say you shouldn't do it, just that it's one of the things that makes me dislike working on a team. I actually think th…

> It's disempowering to feel like you're never able to make a decision yourself, despite supposedly being hired for your expertise in the field. I'm going through exactly this at the moment. For reasons HN will probably consider fiction, my superiors have started treating me as a toddler that needs oversight on every single decision that needs to be made. It's something I've been dealing with in therapy, and the way…

I feel this deeply. I had an extremely similar situation at my last job. My current job is quite a bit better at least, but I still deal with it here.

I guess there's a reason the phrase "code monkey" exists. Jonathan Coulton said it pretty well:

Code Monkey have boring meeting

With boring manager Rob

Rob say Code Monkey very diligent

But his output stink

His code not “functional” or “elegant”

What do Code Monkey think?

Code Monkey think maybe manager want to write god damned login page himself

https://www.youtube.com/watch?v=AEBld6I_AKs

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

#260

Post by alexashka »

icedchai wrote: post #151
imoverclocked wrote: post #99

Earlier quoted context omitted.

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.

When you think you're fooling someone, you're really only fooling yourself.

It doesn't take a genius to know who is doing the work and who is looking for every excuse to be 'blocked'.

Managers simply know that they can't hire or fire and that calling someone on their bullshit would accomplish nothing, so they say nothing.

Managers are masters of soft power. Soft power is very hard for engineering/techie types to understand, which is why it works so well on them, because they don't even understand the game they're a part of :)

Post reply on HN