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

351–360 of 395 posts

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

#351

Post by dogleash »

TameAntelope wrote: post #348
dogleash wrote: post #342

Earlier quoted context omitted.

In my aforementioned example, the set of development practices most often called "agile" was neither the right approach nor what we did. Agile as defined as the ideas in the agile manifesto might have been what we did. It would depend on who you asked and whatever their particular axe to grind was. So I don't know, and quite frankly we didn't really care if we were "agile." All we found was that "agile" is simply too…

You can be as cynical as you like, the general idea of (very) quickly iterating to stay focused on what your customer wants is a proven and effective way of build software. It's not as effective if you're not working in software, or at least I don't know how effective it is, but that's not what this submission is about.

I didn't know I was coming across as cynical? Just saying that I have no idea if we were "agile" because the term is so damn malleable. I do know we weren't a cookie-cutter copy of the popular SCRUM inspired workflow that's commonly just called "agile" regardless of whether the team is being "Agile."

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

#352

Post by TameAntelope »

dogleash wrote: post #351
TameAntelope wrote: post #348

Earlier quoted context omitted.

You can be as cynical as you like, the general idea of (very) quickly iterating to stay focused on what your customer wants is a proven and effective way of build software. It's not as effective if you're not working in software, or at least I don't know how effective it is, but that's not what this submission is about.

I didn't know I was coming across as cynical? Just saying that I have no idea if we were "agile" because the term is so damn malleable. I do know we weren't a cookie-cutter copy of the popular SCRUM inspired workflow that's commonly just called "agile" regardless of whether the team is being "Agile."

Ah okay. SCRUM is the square to Agile's rectangle.

You're "lowercase a" agile if you operate under the prioritization outlined in the Agile Manifesto. I think most of the people who've found consistent success with agile would say that's what matters is more about that than about XP or SCRUM or Kanban or whatever.

Those systems can help, but to be agile is to focus more on individuals, working software, customer collaboration, and responsiveness and less on processes, documentation, contracts, and plans.

I hesitate even to reword the items in the manifesto, just because I know it took a lot of very smart people a good while to agree to the specific wording, and it's seemingly stood the test of time.

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

#353

Post by docmars »

comp_throw7 wrote: post #312
strictfp wrote: post #216

Earlier quoted context omitted.

You can just let some people make mistakes, and give them feedback on it for next time. That way, you get autonomy and eventually mastery. We don't all have to agree on everything. I think that's a fallacy.

The idea that people will better learn from spending several weeks doing something useless (i.e. unnecessary design) instead of having that headed off at the pass is silly, when the specific thing they should be learning is to _not spend several weeks working on something without feedback_.

What if more could be learned / gained from several days or weeks of mistakes in the grander scheme?

I can't tell you how many times I've had to throw out code or designs from longer explorations, but the things I learned in getting there, for the sake of technical purposes, or heck, new ideas I could apply elsewhere in the future, were entirely worth the trouble. This is a pretty fundamental part of increasing skill — to be forced to struggle on one's own, especially if that person's personality is suited to the solitude needed to solve a problem.

Obviously it's smart to avoid larger mistakes or going in the wrong direction for the sake of the product and delivery timelines, but I think it's more realistic to expect these longer adventures to happen, and that an element of trust is necessary to allow that person to not only solve the problem, but grow in that journey.

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

#354

Post by rurp »

e12e wrote: post #325
rurp wrote: post #188

Earlier quoted context omitted.

Due to some turnover I ended up working mostly independently for about a year at a previous job. Nobody cared one bit about the code I wrote, just the end result. Overall it was great! I was surprised at how productive I was in that time. I'm not a partiularly amazing developer, but I managed to ship a ton of work that held up quite well. Obviously there are limits to this approach and it wouldn't work well for solvi…

Sounds like high bus-factor. Were you also expected to pick up "alien" code dumps as other programmers left? Were you happy/efficient working with these unseen code bases?

I had a few coworkers working on very related areas that I coordinated with, plus we did have some contingency plans so one of us could step into the others place in a pinch. But that was a weakness and things could have been rough if I had been hit by a bus.

An alien code dump is basically how I ended up in the situation. My boss left abruptly and a bunch of work he had been handling himself suddenly fell to me. At first it was really stressful trying to get a handle on everything, but once I got over the hump it was quite nice.

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

#355

Post by icedchai »

alexashka wrote: post #338
icedchai wrote: post #285

Earlier quoted context omitted.

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

I called someone out, and pushed back on someone who wanted me to do their work. This was a useless "scrum master" type who couldn't even update a spreadsheet for one of his weekly reports. I explained to him that that updating those spreadsheets was not an engineering responsibility, but I would be happy to provide him with input. I also complained about him to my manager. He was one of those guys who couldn't even copy-and-paste.

They just harassed some other person into doing it. He was a bit passive aggressive about it on some future calls: "Bob doesn't want to update the spreadsheet, so I will have Alice do it!" Anyway, nice guy, but didn't do any work at all, and he's gone now.

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

#356

Post by skrtskrt »

nine_zeros wrote: post #236
skrtskrt wrote: post #111

Earlier quoted context omitted.

To me moving beyond senior means you enable the entire team to contribute together accomplish Big Memorable Things. This can mean a ton of things, which cannot all be served by a single senior+ engineer: * mentorship * seeking out, establishing, and evangelizing best practices, and not just coding best practices: architecture, documentation, testing, ci/cd etc * high-level architecture knowledge and experience * eval…

If every senior only does internal assistant work, which senior does actual building of complex services? What is more important? Building better services or being a library writer? Every point you describe is exactly perverse incentives.

"Write great code to build stuff" is still a core part of the job.

But it doesn't really enable anyone else on the team, other than providing a model of well-structured code to follow - and most people's code is really not as great as they think it is.

I'd rather have a team of average coders who do things to enable and better each other and the team over a team reliant on a great coder or two who can't or refuses to enable anyone else.

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

#357

Post by rtikulit »

TameAntelope wrote: post #348
dogleash wrote: post #342

Earlier quoted context omitted.

In my aforementioned example, the set of development practices most often called "agile" was neither the right approach nor what we did. Agile as defined as the ideas in the agile manifesto might have been what we did. It would depend on who you asked and whatever their particular axe to grind was. So I don't know, and quite frankly we didn't really care if we were "agile." All we found was that "agile" is simply too…

You can be as cynical as you like, the general idea of (very) quickly iterating to stay focused on what your customer wants is a proven and effective way of build software. It's not as effective if you're not working in software, or at least I don't know how effective it is, but that's not what this submission is about.

This may be true if you have no aspirations for your software beyond what your customer can imagine in the present. Almost seems like a methodology that has internalized learned helplessness.

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

#358

Post by TameAntelope »

rtikulit wrote: post #357
TameAntelope wrote: post #348

Earlier quoted context omitted.

You can be as cynical as you like, the general idea of (very) quickly iterating to stay focused on what your customer wants is a proven and effective way of build software. It's not as effective if you're not working in software, or at least I don't know how effective it is, but that's not what this submission is about.

This may be true if you have no aspirations for your software beyond what your customer can imagine in the present. Almost seems like a methodology that has internalized learned helplessness.

If you think the process I'm describing here is, "Ask customer what they want, do exactly what they say." then I'm not being very clear.

"Don't assume that your team should build what it's told to build. Instead assume the opposite: nobody really knows what you should build, not even the people asking for it. Your team's job is to take those ideas, test them, and learn what you should really build." [0]

That's your team's job. Not to make guesses by assuming you know what's best, not to do what they're told by customers, but to run tests and use results to inform next steps. That's the entire purpose of a development team, and you simply cannot do this without a quick iterative cycle.

[0] The Art of Agile Development, pp. 453

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

#359

Post by black_13 »

I dont like working with others or rather when I sought out others help I was seen as an impediment to the 10 percent performer. Most organizations reward and the individual scale not group when you tried to work communally you were chastised or all the way punished.

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

#360

Post by vinaypunwani »

Trasmatta wrote: post #223
anonymoushn wrote: post #222

Earlier quoted context omitted.

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!

And then let's have daily progress meetings to report on the status of each chunk of the investigation! Please update Jira at least once a day! This is a great example of the perverse incentives built into the "everything should be done in one day chunks that you report on daily". The team is incentivized to ignore highly important but challenging / hidden work, and instead only focus on things that are highly visibl…

I think the point is that the only work that matters is work that will improve the customer experience in some way. That could be infrastructure/stability work, or that could be visible front-end work. Not sure how you're using the word "hidden", but that's my reading from this discussion. Either of those things are important/valued by management probably. But none of that should imply or require micromanagement in a high-trust engineering org.
Post reply on HN