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.
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.
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 are examples of this?
* if you are given an operational task that isn't well documented, document it.
* if you are given a task that isn't documented at all, document it some
* add a few more tests than you might normally. Or, if there is no testing framework, discuss why not and see if you can add one.
* read code and create draft design docs
Of course, notice what the team's feedback is and adjust your actions if it is negative. You want to come across as helpful, not as a 'know it all'. I've definitely been too eager sometimes and come across the wrong way.
Also, you could ask your manager or other team members what they wish the team was doing and see if it is something you could help with.
- Go get coffee or in a covid world do a couple of one to one calls with some of your team and LISTEN don't TALK
- Don't make a load of suggestions straight away, it would hurt the feelings of an engineer that wrote that code. Everybody has some code they are not proud of
- Look at the sprint backlog and see if you can do some quick wins. However, double check they are still valid and need to be fixed
- Be a rubber duck on some code reviews
- Skip a report and see if you can talk to your bosses boss or in a startup maybe ask to speak to a founder for no more than 15 minutes
This is a good approach: https://lightit.io/blog/digital-product-agency/
Don't overcommunicate, especially in Slack and its equivalents. By this I mean too much chatting and "online bonding" to the extent that it seems to drown out the signal that should (in theory) be generated by you being awesome and getting shit done, etc.
I'm not saying "just keep your head down, let your work speak for itself and eventually you'll be rewarded for it", because we all know that isn't true. Visibility matters, and a certain amount of online projection is necessary. But there's a certain optimal level, and that level is probably a good notch below whatever the medium "social noise" level is in your team.
Again, not that you need to be a wallflower. But in a "less is more" sense. So it doesn't detract from the signal generate by you actual productive output.
- Ask senior devs to give you a tour of the entire system. Ask for code walkthroughs of parts that you will not be working on also.
- Participate in design reviews, providing thoughtful comments.
- Ask plenty of questions, including on seemingly obvious things so that you catch up to the others on the team in terms of your understanding of why things are the way they are.
- Whenever you first open a source file, take a few moments to browse through its version control history.
- Familiarise yourself with the build, CI/testing etc. loop of your product.
- Read the Unit Tests for parts of the system that you do not understand at first. They are usually an excellent starting point to get an understanding of the system.
- If there is a separate QA staff, make time to talk to them and ask them to show you how they put the system through its paces.
- Ask your manager to give you concrete goals for your first three months, and also to give you a few stretch goals. Try your best to exceed your goals, including your stretch goals.
- https://news.ycombinator.com/item?id=19924100 (understanding codebases, etc.)
- https://news.ycombinator.com/item?id=22873103 (making the most out of meetings, leveraging your presence)
- https://news.ycombinator.com/item?id=22827841 (product development)
- https://news.ycombinator.com/item?id=20356222 (giving a damn)
- https://news.ycombinator.com/item?id=25008223 (If I disappear, what will happen)
- https://news.ycombinator.com/item?id=24972611 (about consulting and clients, but you can abstract that as "stakeholders", and understanding the problem your "client", who can be your manager, has.)
- https://news.ycombinator.com/item?id=24209518 (on taking notes. When you're told something, or receive a remark, make sure to make a note and learn from it whether it's a mistake, or a colleague showing you something useful, or a task you must accomplish.. don't be told things twice or worse. Be on the ball and reliable).
- https://news.ycombinator.com/item?id=24503365 (product, architecture, and impact on the team)
- https://news.ycombinator.com/item?id=22860716 (onboarding new hires to a codebase, what if it were you, improve code)
- https://news.ycombinator.com/item?id=22710623 (being efficient learning from video, hacks. Subsequent reply: https://news.ycombinator.com/item?id=22723586)
- https://news.ycombinator.com/item?id=21598632 (communication with the team, and subsequent reply: https://news.ycombinator.com/item?id=21614372)
- https://news.ycombinator.com/item?id=21427886 (template for taking minutes of meetings to dispatch to the team. Notes are in GitHub/GitLab so the team can access them, especially if they haven't attended).
- https://news.ycombinator.com/item?id=24177646 (communication, alignment)
- https://news.ycombinator.com/item?id=21808439 (useful things for the team and product that add leverage)
- https://news.ycombinator.com/item?id=20323660 (more meeting notes. Reply to a person who had trouble talking in corporate meetings)
- https://news.ycombinator.com/item?id=22715971 (management involvement as a spectrum)
- https://news.ycombinator.com/item?id=25922120 (researching topics)
- https://news.ycombinator.com/item?id=26147502 (keeping up with a firehose of information)
- https://news.ycombinator.com/item?id=26123017 (fractal communication: communication that can penetrate several layers of management and be relevant to people with different profiles and skillsets)
- https://news.ycombinator.com/item?id=26179539 (remote work, use existing tooling and build our own. Jitsi videos, record everything, give access to everyone so they can reference them and go back to them, meetings once a week or two weeks to align)
Some people who do their best to "standout", do more harm than good. The last thing you want to be in a new team is an a* licker.
Take this to an extreme. If they expect you to write a program, do it a little cleaner than they expect. Figure out what metrics matter to your team beyond getting the product out and show you can bring value beyond your code.
- Keep the user in mind
- Write quality code consistently
- Be a team player
- Make your teammates look good