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

331–340 of 395 posts

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

#331

Post by lolc »

baby wrote: post #234
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…

> Writing code as a team is almost like writing a novel with a few dozen other people, all of which have differing ideas on how the book should be written, or even what it should be about. It's hard to feel the joy in creating something when you're only a small cog in the development machine, and every decision needs a dozen voices of input. I believe this is why books most often have a single author. A solution to t…

I don't like the analogy to writing a novel because in a novel you do want suspense, drama, surprises and generally a non-ordinary flow of the story. With source-code, you want none of that. The whole process is geared to remove it. And we should not deplore that but embrace it. Maybe there will be non-conventional things, because you have non-conventional requirements, or you're trying something new, but that should be the exception.

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

#332

Post by marcus_holmes »

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 hate being treated as "just the nerd who pushes the nerd-buttons to make the thing we want work", as if the important part of the work was having the idea and not the execution.

One reason they do this is usually around control. A lot of people feel like they have to be in control of everything in order to be safe. There may be ways you can make them feel safe without needing them to be in control.

Another reason is that until the thing is built, there's nothing to do, so everyone gets involved in that. This happens a lot in startups where they have a "build it and they will come" attitude. It's not true; building a sales/marketing channel doesn't actually need a product at the start, and there's a ton of stuff that needs doing while the product is being built. But it can be difficult explaining this to new founders.

Good luck :)

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

#333

Post by burntoutfire »

Trasmatta wrote: post #259
Kaze404 wrote: post #253

Earlier quoted context omitted.

> 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 thi…

I personally much prefer this version:

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

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

#334

Post by Ensorceled »

watwut wrote: post #308
Ensorceled wrote: post #84

I have two big rules for developers that report to me: 1. The 5 minute rule. If you are stuck for more than 5 minutes reach out. Once the developer is on the team for a while, this becomes 15 or 30 minutes. Caveat ... truly stuck ... tried a couple of things, googled, tried some more ... wondering what to try next. One thing I try to do with a new start is go ask them for help in the same way, "Hey, 5 minute rule, I'…

> Caveat ... truly stuck ... tried a couple of things, googled, tried some more ... wondering what to try next. That is not even possible within 5 minutes. I would not want to work there honestly. Just being unable to solve problems demotivates me. It sounds like I will get off everytime I am slightly slower to pick something. This would be too stressful for me.

Yeah, you missed the point. You don't need to solve the problem in 5 minutes. You need to be 5 minutes in a state where you have no idea what to do next.

Why would you want to be sitting there spinning your wheels? Most people find that feeling of helplessness demotivating and stressful which is why I created the rule.

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

#335

Post by nitrogen »

dogleash wrote: post #177
TameAntelope wrote: post #150

Earlier quoted context omitted.

I'd actually flip that, and say if you can't give daily feedback you're a "bad" developer (I'd probably use "inexperienced" or "new" rather than "bad", because it's a hard mindset shift and it takes time). In fact, not only should you be able to give daily updates, you should be able to ship functionality on the daily. From first line of code into production and in front of customers should only ever take about 2 to…

I used to work at an R&D company. While that cadence is possible in a website mill, it’s a laughable blanket statement.

Keeping a daily log of progress helps prove your research is original.

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

#336

Post by nitrogen »

anonymoushn wrote: post #222
TameAntelope wrote: post #215

Earlier quoted context omitted.

If this approach results in you taking limited and short term views of development, or low quality software with unhappy developers, you're doing it wrong. Breaking down work into small, day-or-two chunks is a team effort that the developers are doing together, alongside the customer (representative, usually).

let's have a meeting about how to break down our investigation of the unexplained segfaults in nginx that occasionally happen in our cdn into chunks that deliver value daily!

This is really not that hard: "Yesterday I looked for correlations between segfaults and hardware vendors. I did not find a correlation, and my deliverable for the day is narrowing the search space. Today I will set up a micro cluster of random traffic to try to reproduce the crash. Tomorrow I will look for patterns in request bodies and stack traces."

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

#337

Post by trelane »

TameAntelope wrote: post #320
ngc248 wrote: post #304

Earlier quoted context omitted.

Exactly .... Agile works pretty well in the "execution" phase when all of the requirements are known upfront. For any kind of R&D agile is not a good fit at all. R&D fits the waterfall model better. Ideally it should be like you do your R&D with waterfall and the agile for execution.

"Waterfall works best in well-understood domains without a lot of uncertainty."[0] Agile is, by far , a more effective way to run an R&D shop. By far . "Agile teams show progress with working software, not documents. Right from the beginning. And that's huge." [1] [0] The Art of Agile Development, pp. 35 [1] The Art of Agile Development, pp. 8

This presumes that software is the entirety of the problem being researched, which is not always the case. Especially as you get more physical.

That said, I don't think waterfall works any better there either. Sometimes there's no way past the "muck about and find things out" work.

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

#338

Post by alexashka »

icedchai wrote: post #285
alexashka wrote: post #260

Earlier quoted context omitted.

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 unde…

It is rather unusual for someone to be called out on their bullshit. I’ve been working for 25 years and only seen it happen a couple times. Most people are conflict avoidant, so the perpetually “blocked” individuals are allowed to stay that way. I know people who’ve essentially done no real work for years . Who’s the fool here? Those of us picking up all the slack.

I have a decorated history of calling people on their bullshit. I have the 'you have been let go' and negative resume references to prove it.

The fool is the person not understanding the game they're playing.

Techies who do other people's work are perpetuating the game they despise - they are indeed fools.

Middle managers who perpetuate the game are smart, because it is their job to perpetuate the game. It is not their job to change the rules of the game - that's the job of the techies who can refuse to 'pick up the slack', let targets fail repeatedly and signal to upper management that the game isn't working, forcing them to change the game, which the middle managers will once again perpetuate, because that is their job.

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

#339

Post by alexashka »

jraph wrote: post #306
MauroIksem wrote: post #278

Earlier quoted context omitted.

There is a lot of bullshit in this comment.

Yes. I hope we get rid of this cliché of the technical person who is not good at human interactions. Most developers I know are good at human interactions, some even among the best. I don't want to be put in that box, and I'm not willing to excuse someone bad at human interactions because they are technical. Obviously some people are better at human interactions than others, and I'll be happy to adapt, but let's not…

Your anecdotal evidence and personal preference is irrelevant in a discussion about statistics.

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

#340

Post by mindslight »

favorited wrote: post #314
mindslight wrote: post #263

Earlier quoted context omitted.

Yeah, it's wicked beneficial that you're paying $40 or even $80 just to say hello and ask how their weekend was. I understand that from the other side, talking to you is working and they wouldn't be doing it if they weren't getting paid. But when one's rate is in consultant territory (as opposed to lower contractor rates based on bulk time) then that type of overhead should already be built in. And sure billing incre…

OK... so don't call someone who bills you for their time and make smalltalk. That seems pretty self-evident. If I start a meeting with a consulting software engineer and spend the first 5 minutes making small talk, that's fine, but my company is gonna pay for that time. The same thing is true for lawyers.

Yes, that's the obvious conclusion. But surely you can see how clients needing to deliberately refrain from standard pleasantries doesn't contribute to lawyers having a good reputation.
Post reply on HN