Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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 deliver solution alone, because there is noone who even grasps the concept.

One could say its simply an incorrect team composition in this case but well.. what can you do about it when you are also asked to in the same time train ppl who clearly dont have the capacity to match your level - and better - they are supposed to reach that level soonTM.



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, scheduled a meeting, etc but got virtually no engagement. And I was still getting pressure from stakeholders to deliver, so had to keep moving :-/

I think OP brings up an interesting problem, but I don't think the solution is often as easy as sending in earlier PRs. It might actually be a structural or cultural problem in the organization.


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


This reminds me of a coworker that I've had bad experiences with. He fancies himself an architect, but he consistently refuses to accept any feedback on his designs. If we give feedback early in the process, he complains that we're nitpicking an incomplete design. If we give feedback when he deigns it completely ready for our review, he complains that he'll have to throw away so much work. All throughout, his refrain is that we "just don't understand his design".

I agree that it's harder when there's an absence of peers at the same experience level, and for problems that can be completed by one person, it's probably not necessary to seek validation. But if it's a problem that requires a team effort, building shared understanding of the design is at least as important as creating the design in the first place. Yes, it's more work if it doesn't click immediately for everyone else, but it's essential.

And sometimes in the process of explaining it so that even a "not great" engineer can get it, we can better understand it ourselves. And sometimes even a layperson can bring valuable insights once they get the gist of it.


It only sounds good in theory. Reality is that in most cases this discussion is pointless and you are much better just explaining.

Example. You discuss different ways of data replication and have to decide which suits the project the best.

Issue is only you have experience with multi-region data replication and people you discuss the issue with dont even understand how replication works.

From manager point of view -> you were hired to guide those ppl.

Thats what happens in consulting like 99% of the time. You are the part of the team but you are often expected to provide the solution.

You can “explain” how it will work, but 9/10 times you wont get any feedback because ppl that you are supposed to deliver that project with simply dont have the knowledge required to have a good level of discussion.

Its like saying “PHD Doctors should have even field discussion with anti-vaccers, because both of them have something to say”..

Everyone has something to say, whether its something valuable, its a different matter.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: