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.

I would do a bit extra. What that is depends on what your task is and team culture is, and I wouldn't go overboard, but I think that doing 10% more will make you stand out. Try to ascertain the team culture and work with it, not against it. If the team is all about shipping, think of ways to ship quicker. If the team is in a bit of an operational mess, think about documenting processes or writing scripts.

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

A big one that would be helpful to every team I've ever joined is to take notes about onboarding and either create a doc/scripts to help folks get up to speed or improve existing doc/scripts.

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.

- Ask to shadow a couple of the team at various levels and be a rubber duck

- 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

Engineers that, aside from being good technically, have a product mindset and are constantly thinking about the users, really stand out and are valued by any product team. This helps the whole company move from "delivering software" to building valuable solutions for users, that have a direct impact on the business. Leaders and clients love this. You can start by learning some basic concepts of UX or design thinking.

This is a good approach: https://lightit.io/blog/digital-product-agency/

In addition to all the other helpful advice:

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.

You can do some of the following: - If there are no code reviews, ask developers you look up to to review your code. Review or be a silent participant in others' code reviews as well.

- 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.

Recycling some replies. More context on https://news.ycombinator.com/item?id=26182988:

- 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)

What do you want to achieve by “standing out”?

Sorry, English is not my first language so there might be a better word to describe it. I am asking in terms of showing initiative and taking product ownership. I really enjoy being an engineer, so it's not just a job for me. I have only worked at one medium sized company, so showing initiative there was easy and also I was part of the team that build a product from ground up.

I think that an important thing to do is to figure out what area of the job has big opportunities for the company or tech stack that currently don’t have ownership, and really take ownership of those areas.

Be humble, do your job, show respect to other people!

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.

Exceed expectations.

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.

- Be curious

- Keep the user in mind

- Write quality code consistently

- Be a team player

- Make your teammates look good

make money for your company.