Doing too much work on one's own before looping in others • Hacker News Board

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

#381

Post by rtikulit » Thu, Jan 27, 2022, 6:02 PM UTC

tomnipotent wrote: post #375

rtikulit wrote: post #362

Earlier quoted context omitted.

Actually, "my" team's job is 1/2 asking the customer, and 1/2 not asking the customer so we can invent stuff they haven't thought of and ideally can't/won't think of. I think the reason people aren't fully agreeing with you is that there's a lot of important stuff where a quick iterative cycle in front of a customer eliminates the possibility of high-value outcomes.

> we can invent stuff they haven't thought of Except you're not inventing things, you're discovering things. That's a big difference. The best way to discover if something works, is to put it into the hands of customers as fast as possible while minimizing your expense at doing so.

Are you asserting there's no scope for invention in software development?

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

#382

Post by tomnipotent » Thu, Jan 27, 2022, 6:59 PM UTC

rtikulit wrote: post #381

tomnipotent wrote: post #375

Earlier quoted context omitted.

> we can invent stuff they haven't thought of Except you're not inventing things, you're discovering things. That's a big difference. The best way to discover if something works, is to put it into the hands of customers as fast as possible while minimizing your expense at doing so.

Are you asserting there's no scope for invention in software development?

Only that an invention isn't something you can just put on your calendar.

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

#383

Post by rtikulit » Thu, Jan 27, 2022, 7:14 PM UTC

TameAntelope wrote: post #363

rtikulit wrote: post #362

Earlier quoted context omitted.

Actually, "my" team's job is 1/2 asking the customer, and 1/2 not asking the customer so we can invent stuff they haven't thought of and ideally can't/won't think of. I think the reason people aren't fully agreeing with you is that there's a lot of important stuff where a quick iterative cycle in front of a customer eliminates the possibility of high-value outcomes.

That's only true if you're interacting with your customer in some weird, subservient way that has nothing to do with anything I've said at all. The point you're trying to make isn't the novel insight I think you're trying to present it as. Of course you don't just build what your customer asks for blindly, of course you design with the future in mind, none of that is precluded whatsoever by iterating quickly to provi…

The point I'm trying to make is a corollary to “A committee is a life form with six or more legs and no brain". It's an acknowledgement that sometimes the customer is bikeshedding from start to finish. It's the recognition that rapid iteration can mean a short planning horizon that traps an architecture in a local maximum that won't deliver on business aspirations.

In a past life I had developed 3 generations of tooling to support a certain complex and information-dense task that was essential to the business. Generational change was not incremental and required months/years exploring the problem domain and prototyping and backtracking and intentionally not consulting anyone. If I came out of stealth too early I'd be directed back to a gen 1 approach that was functionally and architecturally exhausted and could not meet the business needs at a reasonable cost. By the time I was done I understood the problem domain better than the business did. (I will stipulate that most of the time this is a bad approach--but sometimes it's absolutely necessary.)

My (aspirational) purpose at work is to surprise my customer with valuable and insightful solutions that they could not have arrived at incrementally, or with their methods, or with their team. Surely you can see how this is in direct conflict with rapid iteration in collaboration with them?

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

#384

Post by closeparen » Thu, Jan 27, 2022, 7:30 PM UTC

someguydave wrote: post #380

closeparen wrote: post #246

Earlier quoted context omitted.

We have plenty of turnover and it works out fine. In fact turnover of the senior engineers who are service/project owners usually creates the opening for one of the more junior contributors to demonstrate L+1 competency by taking over.

“the status quo is fine”

Of course the status quo is fine, you're one of the highest paid people in one of the cushiest occupations in all of human history.

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

#385

Post by ziggus » Thu, Jan 27, 2022, 8:43 PM UTC

spmurrayzzz wrote: post #16

ziggus wrote: post #12

Why the conflation of 'engineer' and 'developer'? That's a bit confusing.

I'm curious, what about that semantic differentiation is confusing for you? At least in my experience, "Software Engineer" is a standard title for the kind of work the author is describing in the article and is often used interchangeably with "Developer".

Maybe in your experience that conflation makes sense, but a developer is not necessarily a software engineer.

There are distinct educational programs that differ between "computer science" and "software engineering", and a number of professional organizations are lobbying for software engineering licensure, similar to other engineering professions.

Even Dijkstra knew of the differentation: '"A number of these phenomena have been bundled under the name "Software Engineering". As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot."'

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

#386

Post by pojzon » Thu, Jan 27, 2022, 11:04 PM UTC

reureu wrote: post #185

pojzon wrote: post #109

I’ve faced worse issue. So you are thinking about problem solution, you created a design and you ask ppl for their opinionated view about the problem and your solution. Issue is - they cannot even give you a good feedback because they are not that advanced. The issue of being a great engineer is that there are not many great engineers you can have a constructive discussion with. You are sometimes even “expected” to d…

Amen to this. In a similar vein, in a heavily resourced constrained environment, the rest of the team may be really competent but be struggling to meet their own deadlines so just don't have the mental bandwidth or time to provide any feedback. I've had this issue at a few jobs in the past, and I know I've come off as the lone developer who ventured too far... but at every step along the way I stopped, sent in a PR,…

> It might actually be a structural or cultural problem in the organization.

It's indeed often a structural and cultural problem. I'm yet to see some organization to turn that around.

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

#387

Post by MonaroVXR » Fri, Jan 28, 2022, 2:58 AM UTC

marcus_holmes wrote: post #332

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

> "building a sales/marketing channel doesn't actually need a product at the start..."

Never knew this, can you tell more about it?

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

#388

Post by rockemsockem » Fri, Jan 28, 2022, 6:23 AM UTC

beerandt wrote: post #264

rockemsockem wrote: post #240

Earlier quoted context omitted.

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…

I would add that not all physical engineers have to get licensed to do their work.

So what's the difference then between that type of iteration and the type of iteration you see commonly in software? It sounds like the main differentiator for you is "doneness" or something similar to that?

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

#389

Post by areeh » Fri, Jan 28, 2022, 10:49 AM UTC

Treblemaker wrote: post #370

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.

How many times do I need to go down this path: ... - ask for help - try to explain how it's supposed to work - try to explain how it's not working - Listen to them come up with all the ideas that I've already ruled out - Try to explain why their preferred idea has already been ruled out or is not actually relevant to the problem - conclude they still don't understand the problem or even how this part of the system wo…

I could see this the other way, where the reason this path happens is because of a problem with how the team operates so others are not in the loop on the problem or , even worse, the entire system. I think what the parent is proposing is trying to combat that entire issue

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

#390

Post by areeh » Fri, Jan 28, 2022, 11:01 AM UTC

Treblemaker wrote: post #374

TameAntelope wrote: post #252

Earlier quoted context omitted.

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.

Joe is the expert on feature X. When we have a problem in X we ask Joe for help and he invariably provides the insight needed to solve the problem. When Joe has a problem with X, he should go ask for help, even though he's the one best able to deal with it? Should he ask himself for help? Can you see the problem with blanket statements like this?

I've been in this situation many times too, but I have to say it feels like a weakness. When a single person works on a problem I see improvements being left on the table compared to when two people effectively collaborate. I've experienced this in a wide range of skill/experience levels so I don't think that is the problem.

That said, I don't know how to change the situation if you have devs with skillsets that don't seem to overlap much, which seems inevitable for some companies