Why are such LinkedIn style BS messages being upvoted to HN first page. Can we please stick to the motto of posting things that have some interesting phenomena
Ask HN: Coworkers are suggesting I should slow down
11–17 of 17 posts
Re: Ask HN: Coworkers are suggesting I should slow down
#12Why are such LinkedIn style BS messages being upvoted to HN first page. Can we please stick to the motto of posting things that have some interesting phenomena
I am guessing, for a lot of people, this is their social forum and I see nothing wrong in asking for help/suggestions in an ASK HN topic. After all, that is why ASK HN exists.
[Edited for grammer]
Re: Ask HN: Coworkers are suggesting I should slow down
#13Are all the hours you are putting in being paid for and acknowledged by management?
Are the hours you are putting in like a sprint or a marathon? Is this sustainable?
Re: Ask HN: Coworkers are suggesting I should slow down
#14This happened to me and I learnt from it. Regardless of how objectively good your work is you need to remember that you're part of a team, and that means learning to fit in with the team while helping push it forward.
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.
Re: Ask HN: Coworkers are suggesting I should slow down
#15Leave.
Re: Ask HN: Coworkers are suggesting I should slow down
#16No post body was provided.
Re: Ask HN: Coworkers are suggesting I should slow down
#17> I do think I'm improving our codebase on a daily basis. 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 t…
This.
I've been in a similar situation, but on the other end. We hired a very expensive (for us) freelancer with the goal of fixing some very critical performance issues. We had all aspects of the issues documented, even line numbers of where the problem was (thanks, datadog). So we knew about the issues, but had no time to address them properly (very small team).
So this new developer starts refactoring a bunch of unrelated or seemingly related code, with pull requests in the 5k+ changes range, but no real performance gains (we needed to see CPU going down by 50% or more).
It would have taken us more time to review those pull requests and provide valuable feedback, than to fix the issues ourselves (which we finally did, by updating one or our dependencies).
Point is, as a new person on the team everything looks bad because its unfamiliar to you. But there's a reason for that current state and unless you try to, or show that you are trying to, understand why it's like that I don't think you are actually making things better - just more familiar to you.