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

121–130 of 395 posts

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

#121

Post by n0w »

Trasmatta wrote: post #53

I'm good at working on a team and looping in others. I also find it to be one of the most exhausting parts of software development. It's so difficult to constantly need to get feedback and buy-in from other people, and takes away a lot of the creativity and joy in programming (for me). Which isn't to say you shouldn't do it, just that it's one of the things that makes me dislike working on a team. I actually think th…

> Writing code as a team is almost like writing a novel with a few dozen other people, all of which have differing ideas on how the book should be written, or even what it should be about. It's hard to feel the joy in creating something when you're only a small cog in the development machine, and every decision needs a dozen voices of input.

This resonates with me. I think we do our best work when we have the autonomy to apply our expertise.

But at the end of the day, you're not the only one writing that novel. If you have an idea of where the plot is going but your teammates think it's heading somewhere else, it's going to be very problematic.

The other problem is that you _will_ make mistakes. Some could be avoided by leveraging the experience of your teammates. You also won't always strictly have the best ideas. Brainstorming as a group can be a lot more effective than sitting alone for a long time thinking hard about a problem (but also sometimes hard problems need a lot of individual thought).

I suppose my point is that I'm not sure where the happy medium is? I've been on both sides of the "engineer working too long alone before sharing" problem and I think it sucks.

How do we enable engineers to do their best work but also allow our teams to be successful?

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

#122

Post by quickthrower2 »

babycake wrote: post #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…

> Imagine if we didn't have that kind of pressure of delivery in the workplace just to get recognition.

While the places I have worked might have a tiny element of this your situation sounds extreme.

What I have seen is yes you do have to do “perception” management to keep a pulse on “how am i rated”.

Having a few long time trusted people vouch “this person is good” helps and all you need to do is work with them and show that you are good, both in attitude and capability.

However your description sounds like a dystopian “house of cards” scenario that I would be looking for another job asap. If the programmers are more like politicians that is very odd and a bad sign.

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

#123

Post by sdoering »

crehn wrote: post #83
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…

This should nearly always include writing integration tests (that run on every change) to ensure you can refactor with confidence. If there are no tests, the team will waste a ton of time anxiously monitoring and reasoning about the messy code and the impact of their changes.

I do. I even implemented tests for tracking code to be developed locally (including mocks).

This way I'm able to quickly and confidently refactor as well as add to existing tracking code (web analytics).

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

#125

Post by friendlydog »

zachlloyd wrote: post #2

I'm the author of the post - would love any feedback / similar experiences / contrasting opinions!

I'm a fan of "always loop people in".

Frequent checkins with detailed commit messages including markdown and graphviz diagrams which state intentions.

Switching the flow from a status meeting low detail reponse of "still working on X issue" to a regular feed of detailed information which serves not only as a development log, documentation, but it crystallizes the developer's planning and thought process because they have to describe what they are doing rather than just "fixing the issue" , or "building the thing".

Persistent chat has made daily stand up status calls redundant. Stakeholders can subscribe to channels which have rich detailed information about what is happening at any given moment. For larger groups a resource can curate the channels and provide a thoughtful summary in a higher level channel of different teams progress. Tools like Azure Dev Ops provide meaningful charts, tracking, and velocity, and the deeper conversations on chat linked to work items, wikis, and repo level filea serve to provide an accurate picture for anyone looking into the effort. Leads, and managers can identify trouble spots and adjust priorities or provide valuable insights. Regular demos can also be linked and serve as a historical record of the development direction.

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

#126

Post by bayindirh »

ttymck wrote: post #94
Victerius wrote: post #86

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?

Could a 30 year old manage a 60 year old? Certainly a 35 year old could manage a 57 year old?

If the 60 year old is wise and humble and 30 year old is open minded and not smug, it'd create a hell of a learning environment.

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

#127

Post by beerandt »

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…

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.

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

#128

Post by zoomablemind »

swagasaurus-rex wrote: post #88
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 find when this happens, it never gets refactored. The edges can be smoothed, but the architecture is dried and hardens into something that needs to be worked around by everybody else touching the code. The easiest way to solve the issue becomes the only way.

Depends on a team, of course. But happens often with business solutions. Done, whichever way. Next. It broke down in prod? Well, go fix it, it's yours now...

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

#129

Post by mkaic »

kinakin wrote: post #115

We see this with engineers of all ages, but especially with new grads. All have just spent 16 to 22 years working under a model where: you get an assignment, you come up with a solution, you are marked on your result, and then you move on… Our education has trained us that involving others is something done at the end. A lot of our new hires need help shifting their approach (and getting over insecurities) to conside…

I'm not a new dev (but I am a new data scientist) and can definitely relate to what you said. I'm so used to "if you get stuck, just figure it out" as the norm for things I'm assigned to do, and getting used to "I'm stuck, I should reach out to someone who's more experienced than me" has been difficult. I'm always afraid of inconveniencing or interrupting my higher-ups, even though they never seem to be bothered by it. I guess it's just an irrational social fear.

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

#130

Post by billforsternz »

aix1 wrote: post #92
billforsternz wrote: post #64

I chronically suffer from this problem. For example I started working on my chess software in 2008 and just yesterday someone raised an issue on GitHub asking me about pertft(). Gulp. Fortunately it turned out my chess logic does pass that very specific, very easy to check correct/not correct test. But it would have been much better to have checked I was building on solid ground 13 years ago!

Sorry, what's pertft()? (Could be a straightforward typo, but I'm not seeing it. Also clearly not important to understanding your point, but I'm just very curious.)

Whoops perft() sorry.
Post reply on HN