Live data from Hacker News

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

thezbook.com

101–110 of 395 posts

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

#101
Solid advice. Everything is such a difficult balancing act when you work with other engineers. I say this because at the other end of the spectrum its really easy to land yourself and those around you in needless drama by asking too publicly for feedback on ideas. Hey everyone, just wondering what our thoughts as a team are on auto formatting the codebase / switching tabs to spaces / repainting the bike shed?

Some wise advice I once got from an engineer who has gone on to be a stellar engineering leader: utilise the power of managers. Good managers are drama fire breaks. They can tell you — without raising the emotional stakes with anyone else — why a particular bit of tech debt exists, whether anyone on their team is going to be amenable to you fiddling with it, and who to work with directly on anything likely to cause drama would it have been more widely shared.

Managers aren’t immune to drama but the good ones can help keep it minimised.

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

#102
post #93

I have two big rules for developers that report to me: 1. The 5 minute rule. If you are stuck for more than 5 minutes reach out. Once the developer is on the team for a while, this becomes 15 or 30 minutes. Caveat ... truly stuck ... tried a couple of things, googled, tried some more ... wondering what to try next. One thing I try to do with a new start is go ask them for help in the same way, "Hey, 5 minute rule, I'…

What's a PRD? Love the five-minute rule, by the way. I tried to apply that a lot especially when I was just starting at my job. So many things that I would spend two hours trying to fix, only to be told the next day that we had a super simple internal process to fix that thing.

Product Requirements Document ... a full specification of everything the software needs to do.

Sometimes VERY detailed, sometimes not so much.

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

#103

> "the biggest mistake I see engineers make is doing too much work on their own before looping in others" > "For more senior engineers, it can happen because they like to work on their own and may be overconfident in finding solutions. It can also happen if the team culture is toxic and engineers fear getting criticism early in the design process." Not saying the above statement is incorrect but here is an alternativ…

Yes, I think this is undoubtedly true. I didn't really learn until I advanced my career that, in some respects, being a junior or mid-level developer is actually better. Being a senior can be a slog, and while I got paid little in earlier positions, I actually got to do more interesting things, screw up more, and build things from scratch.

The other thing that can encourage doing too much work before looping in others is the culture of the team. You are lucky if you can amass a team of people who all have the same attitude of talking to each other frequently and handling a certain level of interruption. I've worked on such teams and miss them. Although pretty much everyone at any company you work at will say "ask questions, don't hesitate, blah blah blah", there are teams where people go weeks not talking or sharing work, and everyone is always too busy to get interrupted. If work gets assigned in large chunks, as can happen for seniors in particular, it can also just not make sense to loop in someone temporarily if more time needs to be taken for the other person to catch up.

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

#104
To be honest, I don't think this is any of the engineer's fault. I think we're an open creature by nature; we like to share and explore ideas with others.

In the corporate field, what I've observed is that deliveries are most important. Not just any deliveries, but the project has to be big and "impactful" (as in, other teams use it too), and you personally have to own it. Like your name has to be attached to it. No one is going to remember your tiny fixes here and there, or tiny feature implementations in the larger system, even if it's tracked in sprint. All that stuff gets looked down upon as just 'doing your job'.

To get any kind of recognition and ultimately, a promotion (or better raise, better rating, better bonus, etc), we absolutely have to clam up and take entire ownership of the work. If that's not done, other people can swoop in and steal the work. Things become need-to-know basis for your other fellow devs, design meetings is just you leading them and asking if this is fine, etc. Everyone has to know you're leading the project, and you have to constantly enforce that knowledge to put down any attempt at a takeover.

I've personally witnessed this happening to an older and more senior dev when a college graduate tried to assert himself on the team until the senior dev fought back with office politics.

In the end, office politics is what matters, along with your work to back up your office political agenda. Another senior dev could come in and take your project, claim your code is terrible and needs a rewrite, etc. You can only win if the boss is on your side, and that requires you to take on more than you can chew (and of course, deliver it all) to get on the boss's good side.

Imagine if we didn't have that kind of pressure of delivery in the workplace just to get recognition. The first example that comes to mind is Open source work. People just contribute, we share and deliver openly, and as a result community projects grew so big our entire corporate infrastructure became dependent on it.

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

#105
post #97

Sometimes you have to dive into a problem, experiment, try things out. There is such a thing as premature collaboration. If you want to be truly great at something, you need to practice it consistently by yourself.

Indeed, question made by managers is:

“Can you train in spare time?”

“While working on your own projects”

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

#106

Earlier quoted context omitted.

Ugh, my worst development job ever was one that had mandatory full time pair programming. Full time pairing is one of the worst ideas ever conceived in the software world.

Pair programming should be optional and for whoever wants to get team members (especially juniors) up to speed and on the same page. It could be very productive but like all methods/tools that are shoved down everyone's throat and forced to apply them, I could see them being a disaster.

I generally enjoy pair programming when utilized occasionally and as needed, but mandatory pairing is just horrible.

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

#107

This is a bit of a nuanced topic with lots of shades of truth or context, and overall I agree with the article, but that said: Sometimes you know your team is going to do the stupid shortcut if you let them and you save them from themselves by solving the robust solution before they have a chance to "be pragmatic" and pointlessly bikeshed about things that don't matter to waste your time. Sometimes you know it will t…

I have found that the attitude of "just silently do the robust and proper thing immediately and push it, instead of letting the entire team discuss this important infrastructure topic forever in order to ultimately come up with an abomination of design-by-committee-architecture, just to then find out that the remaining time now is way too short to implement it, which is why they then take all the stupid shortcuts to get it done in time, ending up with something barely holding together with duct tape that somehow works for the moment, but immediately tumbles down as soon as the next guy tries to build the next layer on top of it" is a very important senior dev skill, especially at the beginning of new projects when a lot of basic building blocks on which the more complex features have to rest later are still being created.

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

#108
post #9

Earlier quoted context omitted.

Y-e-p. It's not like these retreats happen in a vacuum.

I'll be honest - half the time it's trying to keep it from other engineers who are overly eager to have an opinion because a) they're low-output and looking to posture, and/or b) or want things to be done a different way. At least the business side of the house appreciates the spec'd work being accomplished.

Intentionally not communicating things in order to prevent bikeshedding is a dangerous game to play and a symptom of a broken environment, but that doesn't mean it's not sometimes a valid approach.

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

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

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

#110
We have a saying on our team, "don't go down the rabbit hole alone".

Honestly I think the reasons mentioned in the article for why this happens are valid, but more frequently, people are a little insecure about their work or a little too much of a perfectionist, and that creates slightly enough friction to deter them from sharing progress or asking for help early on.

Post reply on HN