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

281–290 of 395 posts

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

#281

Post by jacobyoder »

TameAntelope wrote: post #262
Trasmatta wrote: post #261

Earlier quoted context omitted.

> If it impacts a user negatively if it's done wrong, that sounds pretty damn visible to me. Solve the problem at hand in the way that suits that particular problem best. Don't be a slave to a rigid process. Don't burn out your developers with a dysfunctional system. Not every problem is well suited to being broken up into single day chunks of work. Not every developer can maintain a healthy relationship to their wor…

What do you think an "interaction" is? I'm literally saying you need to have more user interactions, and you're saying you need to have fewer. Delivering software to your customer is an interaction. You need more of those, not less of those. "Stories are "just right" when the whole team can finish four to ten per week, or about six on average." [0] "For stories that are too big, work with your customers to split them…

> Suffice it to say, it's all been accounted for. Agile works.

And if you are doing "Agile" but it's not working... then you're Doing It Wrong(tm). Right?

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

#282

Post by teirce »

sdoering wrote: post #29

I was more often than not 'guilty' of what the author describes. And I actually love being the lone detective on the hunt for a cool solution. I am not a dev by trade (data analyst) but still love to work on problems solved in code. A lot of the advice hit home, but what struck me was this part: > Encourage engineers to get something end to end launched internally as quickly as possible. This is something my boss nev…

I always phrased this as "You don't know how to build something until you've built it."

It's very easy to get stuck in design hell and write yourself into a corner. It's much better to get something that does what you want, then you change it to do it how you want it to.

Though like others have mentioned, this requires an engineering culture that values the second part.

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

#283

Post by yibg »

TameAntelope wrote: post #252
yibg wrote: post #226

Earlier quoted context omitted.

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.

In general I agree, where possible and where it makes sense getting others involved early is a good thing. Somethings are more solo work however, at least for a while to get things oriented. Some times it takes time to gather enough context to even start to express a problem space to others. Not everything is just adding a button to a web page.

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

#284

Post by hackerfromthefu »

Trasmatta wrote: post #249
political12345 wrote: post #232

Earlier quoted context omitted.

I think most people are salty about your comment because they fail to see the subtle difference between: 1) "Everyday you should ship something" 2) "At the end of each day you should be able to tell your line manager in a clear and concise way exactly what you did; if you can't you've done nothing." 2) does not mean ship code: you could have spent 12 hours thinking and reading code. But if you can explain i.e provide…

Or you can hire good developers who value their work and want to ship high quality software, and get out of their way so they can get things done. Your method seems to be treating your developers like children who will refuse to get work done if somebody isn't watching over their shoulder. If that's happening, then I think you have a hiring problem.

Part of the problem here is broken incentives.

Many software developers are not that effective at making rapid progress (for whatever reasons), so if you are actually highly skilled and highly motivated you can produce multiple of the progress of some coworkers. But generally management doesn't deliver high performers who deliver multiples of progress multiples of salary, instead they fight to keep it to small percentage rises and don't even fire the deadwood!

This (mis)management destroys intrinsic motivation of high performers and the manager is left with deadwood and skilled but unmotivated people and some average performers, which try to micromanage to get results out of.

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

#285

Post by icedchai »

alexashka wrote: post #260
icedchai wrote: post #151

Earlier quoted context omitted.

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 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.

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

#286

Post by TameAntelope »

jacobyoder wrote: post #281
TameAntelope wrote: post #262

Earlier quoted context omitted.

What do you think an "interaction" is? I'm literally saying you need to have more user interactions, and you're saying you need to have fewer. Delivering software to your customer is an interaction. You need more of those, not less of those. "Stories are "just right" when the whole team can finish four to ten per week, or about six on average." [0] "For stories that are too big, work with your customers to split them…

> Suffice it to say, it's all been accounted for. Agile works. And if you are doing "Agile" but it's not working... then you're Doing It Wrong(tm). Right?

Would it make you feel better to hear it's not your fault?

There are lots of reasons agile won't work for you, but they're also great indications you should probably leave a given org.

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

#287

Post by jlokier »

TameAntelope wrote: post #172
kerneloftruth wrote: post #171

"Looping in others" is an opportunity for others to say NO, or to try and redirect you, or to jump (unwanted and unneeded) onto your band wagon. If I'm working with true peers (not age or title peers, but truly similar in talent and ability), then their early involvement or collaboration is great. Generally, however, I prefer to get solutions developed to the point where they are their own proof. It's much harder to…

Proof to whom? Shouldn't you be developing things your customers need, not some pet project you enjoy working on for its own sake?

Proof to whoever the stakeholders are, presumably the customers in your model.

Proof that it satisfies what the customer needs or wants - something which can't be demonstrated until the would-be solution reaches some level of demonstrable maturity.

For many engineering solutions, you can talk about them earlier, handwave, present, but nothing conveys that it actually works, or sometimes even makes sense, short of a working demonstration.

Why so quick to assume it's a "pet" project? If the developer is doing it right, they are making exactly what the customer needs, but the customer does not have the developer's expertise to recognise what will work at an early stage.

We are not talking about things everyone understands and could have an opinion on, like say the colour and layout of the login window.

Take something that requires deeper work and hired expertise. For example suppose you've started to design a new kind of GPU technique that will double the customer's calculation throughput for the same power consumption. They hired you for your expertise to solve that sort of problem. They have no idea how it works though, and for the first month you have only an outline of a new algorithm, that only peers at your own level could understand well - and you don't have any peers in that area. And most of figuring out the details is on paper and whiteboards, math and logic along with throwaway experiments to measure. The first line of code in a working demo is not possible to figure out until 3 weeks in, and it takes only 1 day of coding and 2 days of polish after that to finish.

That sort of thing isn't a pet project. It might not even be fun; it might be quite stressful, after all it's a higher risk to the developer to pursue such paths. It doesn't fit into daily PRs and isn't even a coding problem at first. Yet it's exactly what the customer needs, what they said they hired you to accomplish, and what they will appreciate if it has reached the point of "proof" when shown.

It will be incorrectly assumed to be the developer's pet project if it's demonstrated before it works, though. Thus the reason to build it up to "proof" level, if you're sure the customer needs it.

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

#288

Post by TameAntelope »

jlokier wrote: post #287
TameAntelope wrote: post #172

Earlier quoted context omitted.

Proof to whom? Shouldn't you be developing things your customers need, not some pet project you enjoy working on for its own sake?

Proof to whoever the stakeholders are, presumably the customers in your model. Proof that it satisfies what the customer needs or wants - something which can't be demonstrated until the would-be solution reaches some level of demonstrable maturity. For many engineering solutions, you can talk about them earlier, handwave, present, but nothing conveys that it actually works, or sometimes even makes sense, short of a w…

So... how do you know what those people want? How do you know what you're building in 3 weeks isn't something totally different from what the users now want?

The answer is that you, alone, don't. By spending more than a small amount of time building out the simplest possible version of what the customer wants, you get their feedback along the way.

It's generally not true that you need many weeks, or even a full week, to build something you can show a user. Usually you're not being creative enough to figure out what to show your customer if you can't think of a way to provide value in a few days.

There are rare exceptions, but in the vast majority of cases you can build something for the user quickly, even when you initially think you can't.

This isn't even my opinion, it's the observed practice of a whole generation of developers. Read "The Art of Agile Development" if you want to know more, it's extremely helpful if you're trying to understand how to achieve the delivery I'm talking about.

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

#289

Post by nine_zeros »

zomglings wrote: post #271
abofh wrote: 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…

Haha I like everything you said except the "pair program" bit. From my point of view as both a programmer and an employer, this is the cleanest way to make sure knowledge transfers between short-term and long-term team members. Why the disdain? (If I interpreted correctly.)

Pairing is only helpful when you are new and learning from someone more experienced.

However, it may be a time-sink for the more experienced person, who could be using their limited time on more critical things.

That's why newbies get assigned a mentor, with whom they can pair freely.

But pairing rigidly with the whole team just sucks and is incredibly unproductive.

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

#290

Post by zomglings »

nine_zeros wrote: post #289
zomglings wrote: post #271

Earlier quoted context omitted.

Haha I like everything you said except the "pair program" bit. From my point of view as both a programmer and an employer, this is the cleanest way to make sure knowledge transfers between short-term and long-term team members. Why the disdain? (If I interpreted correctly.)

Pairing is only helpful when you are new and learning from someone more experienced. However, it may be a time-sink for the more experienced person, who could be using their limited time on more critical things. That's why newbies get assigned a mentor, with whom they can pair freely. But pairing rigidly with the whole team just sucks and is incredibly unproductive.

I don't think it's true that pairing is only helpful for new people learning from someone more experienced.

But I also think it will be difficult to convince you otherwise if that's what you believe.

Post reply on HN