Ask HN: How to approach first days on a new job as a senior engineer?

I'd say pay very close attention to who does what, literally write it down, what people say they do, what you observe them doing. Try to make no impact, as close to zero as possible. Two weeks later try again to assess who does what. Does it agree. Who changed? Why do you think something is different, why did some things stay the same? Repeat. You will naturally come into contact with most important people trying to get access to everything, where does it go fast, where does it go slow? Who didn't you come in contact with? Who gives bad information? Who gives useless information? Who gives good information, where is their source? Now based on that information you can try to suss out the overall dynamic and form a theory of impact. What are you trying to impact? Do you want to do the things you apparently need to do to make that impact? What is your exit plan if you find yourself in bad positions? What kind of bad positions can you imagine being put in, how do you today wish to see yourself handle it?

My point is that I rarely don't regret (for my careers sake) jumping in and delivering (obvious to me heh heh) value right away because I see the code I see where it ought to be and the new boss is really eager to see somethin, but I'm steamrolling toes and throwing elbows in eyes that I was entirely unaware of. I guarantee the people you will work with do not see you as a senior for some time, any misstep is a case against your status, its better to move slowly and thoughtfully with regard to politics than try to lightning strike some progress in the hopes it gets noticed 3 levels above you (they don't give one shit you already shot your wad can you do it again? and again? and again?)

spectacular anti-patterns -- grandiose "accomplishments" ; bullying peers and coddling weak subordinates ; splashy, attention-getting cubicle changes ; attention-seeking past war stories ; incessant industry name-dropping ..

apparently from the San Francisco dot-com rush culture?

Keep lab notes! I keep detailed daily notes of what I've learned, code I've run, what my todo list is, etc. in markdown. Getting in the daily habit helps you not go "eh I don't need notes for this" and is a GODSEND come review time when you need to write a self eval.

When I onboarded at a larger (10k people) company, I asked my manager for people who did a similar role to me across the company and asked for a fifteen minute time slot on their calendar to ask about how they work, what they thought was vital for me to learn or would be an accelerant to my onboarding, any tips or tricks for working with the company or our tools, and other people they thought would have good answers for those questions, and then rinse and repeat for that new list of people. I ended up doing ten interviews in my first two weeks, published a little internal blog post about common themes and what I learned, and that helped shape a lot about how I worked. Not to mention that type of proactivity in and of itself impressed a lot of people; doing things for clout is dumb but making things you learn public and synthesizing them into a form that's accessible to others is an important hallmark of a senior in my opinion.

Ask SO many questions. Got opaque docs that are important? Ask for a quick meeting with the person who wrote them to make sure your understanding is crystal clear. Abandoning ego and being a knowledge sponge makes such a huge difference.

Run the code base through Gource. It will give you a visual on the history of the project and where all the time is being spent. This video is cool to show management.

Make sure you understand the business problem.

Document your pain points for the next person. Document, don’t just learn, and share it with your team.

Context: I was an early strategic technical hire by a director/manager/CTO 3 times to help execute process changes and lead new initiatives healthcare SaaS companies between 2014-2020 and then started working in strategic cloud consulting since then where I am brought in to get developer, operations and the “business” to be better aligned and/or to lead new initiatives.

I’m currently a “staff software architect” at a 3rd party cloud consulting company.

What not to do:

1. Disrespect current processes. What you call “legacy code” was done for a reason, is generating revenue, solving real world problems, and the reason you have a job

2. Make any suggestions about improving processes before you have been their at least 90 days and understand why the current system is like it is.

3. Suggest rewriting something or introducing new to the company technology until you have worked there 90 days. Especially don’t start doing resume driven development.

What to do:

1. Set up a meeting with sales and ask them to “sale you the value proposition of the product as if you are the customer”. Ask questions as if you were a potential customs and raise objections to the product as if you were customer. Sales is usually very good at answering those questions.

2. Talk to your manager and ask what are their 90 day and 1 year plans for your team and make sure your work is aligned with the goals.

3. Get to know the pecking order. The org chart will not show you who has the most influence in your department.

4. Setup “getting to know you” 1-1’s. What are people working on? What do they want to be working on? What are their biggest pain points? What would they improve if they had a magic wand?

5. Pick up small stories, bugs to get familiar with the development process.

6. Learn about pre-wiring a meeting when you are trying to suggest changes. Do a POC, talk to the person who might have the biggest objection or has the most influence and work collaboratively to address their objectives. Keep doing that for more people on your team. It helps get more people on your side.

ADKAR change management model

https://www.prosci.com/methodology/adkar