What are the most helpful things you did for your team members?
Posted by LargeSinkholesInNYC@reddit | ExperiencedDevs | View on Reddit | 24 comments
What are the most helpful things you did for your team members? I am trying to do everything possible to be a good team member, so I was wondering if there are things I could do that I currently don't do.
ttkciar@reddit
Some of my greatest contributions are also the most understated:
Wrote a bunch of unit tests,
Wrote a lot of documentation mapping common problems to explanations + step-by-step fixes,
In dev meeting debates, I let my opinion be known and then shut my mouth. The debates ended that much sooner because of it, so the meetings ended that much sooner, and we all got back to useful work that much sooner.
Admirable-Area-2678@reddit
If you hear someone making bad assumptions or still making bad decision, you still not say anything or raise concern second time? Basically question is how much you debate or just let it slide
ttkciar@reddit
Yes. Debate doesn't change anyone's minds. If someone sticks with a bad decision, I let it slide and let cause-and-effect play out.
One of two things can happen: Either the consequences of the decision are bad, or they are not.
If the consequences are not bad, that demonstrates that either I was wrong about it being a bad decision, or that the matter was irrelevant in the first place. Either way, arguing about it would have accomplished nothing.
If the consequences are bad, that will be compelling in ways that debate is not, and I will have been on record saying that it was a bad decision (and perhaps even predicting the undesirable consequences). Enough of that and people (or at least some people) start taking my stated positions more seriously.
CharlesV_@reddit
My whole team just got RIFd but I worked with 2 other devs for the last 3 years and we had a great working relationship.
One was a little picky about having very focused commits, so I kept PRs short and commit messages specific. If I needed / wanted to fix formatting and lots of spelling errors, I’d have that as a separate commit at the end.
The other dev was the master of making the smallest necessary change and not going beyond that (legacy system, changing things can break something in dumb ways). I’d usually just get his opinion before making any big refactors if he thought it was worthwhile. Better to check first rather than do the changes and then discuss in PR.
crmpicco@reddit
RIFd?
CharlesV_@reddit
Reduction in Force. A layoff. I’m on paternity leave right now so I haven’t been officially laid off, but pretty sure I will be the day I get back.
bigbry2k3@reddit
At least for new people, spending time getting them oriented to the team. For juniors they seem to like if I'm available for them at all times to answer all questions... well, I try to be. Then I teach them the rubber duck technique. For mid-level what they really want is to be a senior dev so I try to help them build their experience. I never had a senior dev on my team but if they're on another team, they can bounce ideas off me in chat.
justUseAnSvm@reddit
Quickly review PRs, and get them merged.
One of the most annoying things of being on a software team is to have your work gated by PR Reviews. If I at all can, I'll finish whatever is my immediate task, and get on the PR. Fortunately my team is quite senior so it's often an approval + nits, but PRs going over several days really slows people down.
thewritingwallah@reddit
Well I sent this blog https://mtlynch.io/human-code-reviews-1/ around my office everytime someone trying to be a gatekeeper.. It's a good article. some of it is just "remember that the person on the other side of the screen doesn't always interpret stuff how you may have meant it" but that's a reminder we all need sometimes.
We devs are a sensitive bunch and I always try to be cognizant of that fact when doing peer reviews. I rarely hit the "deny" button and always try to communicate my observations to the other dev in a constructive way. It's important to remove ego when doing peer reviews.
That said I wrote my exp on code reviews. https://www.freecodecamp.org/news/how-to-perform-code-reviews-in-tech-the-painless-way/
justUseAnSvm@reddit
Yes!
I'm working on a code modification tool to augment the code in a certain way. We have to go to other product teams and get them approve and merge the PR.
Even though we work with the product architects and negotiate the features, we always find the person who wants to shut it down. It's a lot more work for us, and we always find a way around it and do what we wanted to anyway. It's like the "no" is just a time-consuming side quest to convince the n+1 person.
thewritingwallah@reddit
Engineering ultimatley comes down to communication skills alot more than you would expect. The best Engineers all: listen, do code reviews with empathy, critically think, challenge, accept mistakes, learn from mistakes, collaberate, investigate and support others - All in a team environment.
There was an engineer on my team a while back who was: a good dev, but not the best dev. Got everything done. But had zero ego, a very nice personality, and got along with *everyone* on the team very well.
When he joined, the team became... better. Nicer. More balanced.
CandidPiglet9061@reddit
When we get new junior devs, I block out time to sit them down and teach them explicitly about unit testing, TDD, and dependency injection. Kids come out of school and we expect them to pick these things up, but I’ve found that they start shipping better code, faster, when we go through a crash course on these concepts
kevin074@reddit
high level microservice architecture flowchart via excalidraw
it details how the frontend interacts with various backend microservices and how data gets created and the flows in and out. Nothing that reference actual code.
Longjumping-Cat-2988@reddit
One of the most helpful things I did was push for a project management system that actually fit how our team worked. Once we had a clear place to track tasks, deadlines and blockers, it cut down on so much confusion and freed people up to focus on the work instead of chasing updates.
lagom_kul@reddit
Give high quality peer reviews.
HW_Fuzz@reddit
This question and the comments are like a one for one copy of a question I saw posted on here like 4 hours ago.
GoTheFuckToBed@reddit
you and me are the only humans left
dexter2011412@reddit
set up a full devcontainer + visual debugging setup with vscode, even onboarded an intern in under a 10 days with this setup, they were debugging tests and getting a hand of the codebase (I am not experienced dev, just under \~1 year in the org at that point)
SignoreBanana@reddit
Be accessible, responsive and respectful of their time.
miran248@reddit
This! Also, don't initiate the conversation with a simple Hey, write out what you want! Hey, i'm working on this thing and need your help on that thing, halp!, that way other person can respondd with a potential answer in a single response.
canadaisaniceplace@reddit
Helped a young teammate with a long-term back injury find a surgeon who fixed them up finally. They were so tall when they came back to work!
tmetler@reddit
Automating the tedious parts of the development workflow. Each little sub task adds up and pulls you out of your flow state. Even small things like integrating your version control with your project management system to auto progress stories add up because you don't have to interrupt your thinking with book keeping.
sol7117@reddit
I've worked in small teams so this may not apply to your situation.
Document parts of tech stack that do not have high visibility, requires deep in-house/esoteric knowledge, etc. Basically, the gotchas for your particular company's tech stack/use-cases. You know they're there as well as your teammates, but everyone gets busy (or it may not be a high-value fix at the moment) and it's easy to forget. Massive extra points if this is kept updated and reviewed regularly.
You, your current teammates, and future teammates will appreciate this.
PoopsCodeAllTheTime@reddit
I do my job, and sometimes I answer questions.