Comment by d--b | Hacker News Reader

Comment by d--b | Hacker News Reader

1. be independent when reading code: read the code to figure out what it's doing before asking questions. A new engineer who can say : "oh yes, I've seen where that happens" is a lot more useful than an engineer who needs hand holding.

2. don't be independent when writing code: don't go into development mode and start creating a lisp compiler in the project without telling anyone. Check that what you're building is ok with others.

3. copycat the style: you need to adapt to the style of the company you're joining. Whether it's variable naming, or the way they do unit tests, it's great that from your first commit you show that you'll blend in.

4. don't mention the way you used to do things. It's _very_ tempting to complain about things that the new company does less well than the old one. Do not do it, or only when asked.

On point 4 - I do think it’s tempting to say “we used to do it this way at my old place, and it was much better”. I call it “at my old place” syndrome.

However, if you never take your learnings from place to place, that’s also pretty useless isn’t it?

I think it’s more about how you communicate those learnings. Perhaps start by not suggesting they are better, just that you’ve also seen it done a different way in the past (I.e. avoid “at my last place...”) and you’re wondering why we do it this way instead. People are going to be much more receptive to not opening with “I know better”, especially because when you do it this way you often find they’ve already tried it the way that your previous place did it and it didn’t work for them for very straightforward reasons.

I think it's good to take notes on how you could improve things based on past experience for the first 30-60 days. Keep the notes to yourself. Review after you have more experience in the team.

You'll either find that the suggestions have some merit, in which case you'll have more credibility to make them, or that you learned enough about the new environment to know they weren't useful.

What and excellent summary. Do this.

Reply on news.ycombinator.com