Live data from Hacker News

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

thezbook.com

261–270 of 395 posts

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

#261

Earlier quoted context omitted.

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

> 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 work with that level of micromanagement. There is a huge amount of anecdotal evidence about this if you read any thread about developer burnout, or modern day scrum and agile. You mention the Agile Manifesto, but seem to forget that one of the primary points is "individuals and interactions over processes and tools".

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

#262

Earlier quoted context omitted.

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

> 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 into smaller stories." [0]

If you think it's just "Everything gets shipped every day or two and no other changes get made to how the team functions." then I have not been clear. It's a massive mindset shift, and it comes with a number of other important changes, all of which are best read from the experts themselves, rather than interpreted through me in an HN comment.

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

[0] https://www.amazon.com/Art-Agile-Development-Pragmatic-Softw...

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

#263

Earlier quoted context omitted.

> If your work is bullshot, I bill tighter than my lawyer Lawyers must hate their work.

Lawyers aren't tracking & billing in 6 or 10 minute increments to punish their clients, they do it so you only pay for the time they actually spent on your account. It's beneficial that, if they get a 5 minute phone call while preparing a document for you, you don't get billed for the time they were on the phone.

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 increments are theoretically orthogonal to billing for overhead, but it's galling to see "1.1 hours" knowing that 6 minutes of that was overhead that didn't get rounded down.

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

#264

Earlier quoted context omitted.

It might be good advice, but that's not engineering in concept, spirit, or practice of the term. I don't usually pick an absolute, decisive side in the "what counts as engineering" debate, but this is the opposite of engineering.

Lol, you think physical engineers don't throw together prototypes that they know won't be good enough for the final design just to get everything working together?

They do a preliminary design. They don't throw up some 2x4s and corrugated aluminum to use as a building in the meantime while doing a real design.

Or they iterate designs and prototype manufactured products.

They do not stamp and accept professional liability for thrown-together designs that bosses want to prematurely push out the door into production.

They tell the boss to budget them what's needed, or go find some other sucker to stamp it.

I'm mixed on the pros and cons of professional licensing, but it does give PE's a great amount of personal authority in refusing to be a part of substandard work. Even to clients and bosses.

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

#265

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…

I'll just reiterate what I said above, because I feel there's more to the problem at hand than "number of customer interactions":

> 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 work with that level of micromanagement. There is a huge amount of anecdotal evidence about this if you read any thread about developer burnout, or modern day scrum and agile. You mention the Agile Manifesto, but seem to forget that one of the primary points is "individuals and interactions over processes and tools".

I don't plan to continue the conversation at this point, because it's not productive.

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

#266
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?

I used to work for a company in which employees in some departments would do 2 or 3 year "shifts" as managers. When your shift was up, you went back to a regular employee in the same department, and someone you had been managing took over. It was not uncommon to have a young manager, but not everyone was eligible, obviously.

I think it prevented the "us vs. them" mentality from creeping in, and I got the impression that most managers were eager to return to production work. There were dedicated managers higher up the ladder, of course.

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

#267

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…

I'll just reiterate what I said above, because I feel there's more to the problem at hand than "number of customer interactions": > 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 work with that level of micromanagement. There is a huge amount of anecdotal evidence about this if you read any thread about developer bur…

You began this conversation saying that interactions are bad, and end with saying they're good, so I will take that win as I can get it! :D

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

#268

Earlier quoted context omitted.

I think criminal defense is a great service to humanity. It's hard to estimate how many are wrongfully accused, but surely there are many. Further, things like the plea bargain system or parole regularly lead innocent people to proclaim their guilt. It's very messed up and must be a terrible trauma for some. Lastly, I think even guilty people deserve humane treatment and perhaps forgiveness.

> and perhaps forgiveness. I would agree here, on the condition of rehabilitation. Obviously our "justice system", isn't. Edit: Speaking of the US above, no experience or knowledge about other countries systems. It appears I've found a new gap in my knowledge, anyone have a good intro to how courts work in their country?

My lawyer friend and I are both Australians, and he works as a criminal lawyer in the Australian legal system.

The US inherited the basics of its legal system from that of England. Australia did too, along with many other countries. So at a very high level, the basics are the same. But, there has been a lot of divergent evolution, so as we drill down into the details lots of differences come up.

I think one huge difference is not really legal but social – Australia has always been a less violent society, with less violent crime and less social conflict than the US has, which reduces political pressure for punitiveness in the legal system. On a per capita basis, the US homicide rate is 5 times that of Australia, and while these numbers go up and down, I think it has been consistently significantly higher than Australia's, for many decades.

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

#269

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?

I used to work for a company in which employees in some departments would do 2 or 3 year "shifts" as managers. When your shift was up, you went back to a regular employee in the same department, and someone you had been managing took over. It was not uncommon to have a young manager, but not everyone was eligible, obviously. I think it prevented the "us vs. them" mentality from creeping in, and I got the impression t…

How did that work out overall? I really like that idea, but I haven't heard of it before. People seem very motivated to stick to career tracks.

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

#270

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.

Agreed - I’ve spent months working on a deep tech problem before I could even show a functional core, let alone putting it into production. Some problems take time, experience and foresight to solve and the solution only dovetails at the end.
Post reply on HN