One coworker DM'ed me that I should probably slowdown. I also noticed another has not reviewed my PRs for many weeks now. I'm getting a feeling that I'm upsetting people.
I work from home, sometimes at odd hours. Many of my colleagues are from Europe (different work/life balance).
Should I just keep doing my thing?
What does this mean exactly? If you are redesigning the code base it could be like going into someone's house and redecorating for them. It's no longer familiar. If that's the issue then yes slow down, talk about it and get consensus first. Even if your way is objectively a win.
If it's bug fixes, new features, etc. That's different. You should be encouraged to produce. But politics matter, so you will have to feel the situation out and decide. Bosses may be using you as the new yard stick to measure performance.
What reminded me of that discussion was that he was describing the exact same “symptoms”: code reviews that were never done and colleagues starting to openly resent him.
[1] https://news.ycombinator.com/item?id=16883882
Edit: found the article also - https://web.archive.org/web/20180421142843/https://sites.goo...
You also need to remember that you might be in the wrong team, whether or not your work or your colleagues work is of a high standard or not.
Both can be true but there is no "I just keep doing my thing" option here that has a good outcome. If anything, I'd say the message from your colleague is a good thing, someone wants you to succeed.
For context, reasons I have asked colleagues to “slow down”:
- they were making many mistakes or suboptimal choices, sometimes really bad mistakes, and weren’t correcting when given feedback. Most of these cases, they seemed blissfully unaware of the work they were creating and the negative value they were adding.
- they were good engineers, but obviously burning out and miserable, which made it hard to give any criticism or suggest alternate approaches. See also “heroes”, the always-mega-swamped, and the perennially grumpy (these are different classes, but can be mixed). They also weren’t always aware of their effect on others.
- they were sidelining other peoples views and autonomy, demanding changes in other peoples components, making decisions outside their scope and domain of expertise, informally managing other folks work who were perfectly capable. This was usually done with a nice professional sheen — for example, “demanding changes” often takes the form of 1) writing full on features in another component, 2) making their own work kinda depend on that feature, 3) (finally) starting a very late convo with the maintainer of that component and putting them in a rough spot if the change was a bad idea from a broader perspective. Again, usually unaware.
It’s very easy to make the above mistakes — I have, most engineers probably have teetered, and I’ve seen it a bunch in my relatively short career.
I can say, I have never asked someone to slow down when they were hitting home runs, collaborating well, and making me look bad (please, I love to work with folks I can learn from, that’s engineering). It has always been a complex but totally salvageable performance problem I’m trying to guide back on track.
If you have the feeling that doing less would be spinning your wheels, you could reallocate some time to developing some complementary or speculative skill - acquiring and exercising some new perspective that's not necessarily in direct service to today's codebase. You'll still be able to put energy into your work, which you clearly enjoy, your employer will benefit from your deepening versatility, and your colleagues will appreciate your sensitivity to team dynamics.
Assumptions will make things worse.
Are the hours you are putting in like a sprint or a marathon? Is this sustainable?
When you join a group, you need to do as they do, but a little better. If you start doing 2x the work or touching existing code and changing it to make it 'better', what you're doing is making other people hate your guts :)