4 ms·
> 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 e
by n0w 5y ago
> 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?
- strictfp 5y agoYou can just let some people make mistakes, and give them feedback on it for next time. That way, you get autonomy and eventually mastery. We don't all have to agree on everything. I think that's a fallacy.
- comp_throw7 5y agoThe idea that people will better learn from spending several weeks doing something useless (i.e. unnecessary design) instead of having that headed off at the pass is silly, when the specific thing they should be learning is to _not spend several weeks working on something without feedback_.
- js8 5y agoI don't think that's what GP was suggesting at all.. everyone in the thread agrees that feedback is good. However, the opposite extreme, spending time in meetings where lot of good ideas get proposed but most of them get killed, because somebody doesn't like a detail, or nobody champions them strongly enough, is not a good learning experience either.
- docmars 5y agoWhat if more could be learned / gained from several days or weeks of mistakes in the grander scheme? I can't tell you how many times I've had to throw out code or designs from longer explorations, but the things I learned in getting there, for the sake of technical purposes, or heck, new ideas I could apply elsewhere in the future, were entirely worth the trouble. This is a pretty fundamental part of increasing skill — to be forced to struggle on one's own, especially if that person's personality is suited to the solitude needed to solve a problem. Obviously it's smart to avoid larger mistakes or going in the wrong direction for the sake of the product and delivery timelines, but I think it's more realistic to expect these longer adventures to happen, and that an element of trust is necessary to allow that person to not only solve the problem, but grow in that journey.