Hacker News new | ask | show | jobs
by softwaredoug 1838 days ago
Don’t come in with too many ideas and no context on the org.

Don’t try to do too much, you’re new, onboarding takes time.

Don't pass judgment on the team, it’s practices, it’s work, etc until you can establish some empathy and context for why/how things got there.

Do listen a lot. But really do this always anyway as your default mode of communicating.

Do make small improvements to the onboarding process. It’s an easy way to ship in your first week

Do find ways to make small, but meaningful improvements.

Do have a “beginners mindset”[1] regardless of what you’ve accomplished in the past.

Do appreciate what is different about this place, it’s culture, working norms, values, etc - esp the unspoken ones that might be taken for granted. Write those down for future new people.

Do schedule 1-1s with your lead and teammates. Maybe your skiplevel. Connect with them as people.

Do be open and growth oriented. Expect to not like something at first, but give it time to let it grow on you and gain context before passing judgment.

Do collaborate a lot. Pairing is caring when you’re new. Esp when remote, building together can help grow your relationship with teammates. (They should want to collaborate to help onboard you)

Do demo a lot, but make it about what the team did together in your collaboration, not about you.

Do couch your observations and ideas as questions, not strong assertions or pronouncements. It lets you probe the issue. Instead of “WE SHOULD TEST WITH PYTEST!!!” Maybe try “I notice we used pythons built in unit testing, just curious if there’s history there on how that came to be?”

Do understand how your team is measured and incentivized.

1 - https://en.m.wikipedia.org/wiki/Shoshin

1 comments

Great points. I would say some of the most annoying new members are the ones that go around saying "you should have used [insert whatever hot tool] instead" after spending an hour learning about a project just because they read it somewhere. It can take months before you understand the decisions and context behind a software project that has been maintained for a while.