- Make a token commit day 1 or 2 to show you can and will deliver, even if just docs. Ensure you can go end-to-end on a real code PR week 1, even if a trivial one. Identify which area of code is most important for you to learn, vs not learn, and focus there.
- Get agreement on week 1 / month 1 / q1 goal for you+team+co with your direct peers, manager, skip level. Assuming a startup, also with CEO. Meet associated peers, like if an eng mang, other eng manga, and if a startup, head of X, Y, Z.
- Learn the business & product, eg, use it + shadow sales/marketing meetings.
- Observe culture and start acting: your first 30-90d is when you can make some changes by power and set tone, but doing any in weeks 1-2 are generally presumptuous as means you don't care about existing people & their earned & lived experienced. Change depends on seniority, eg, less senior can mean just adding better linting.
Man I just joined a new company, super disorganized like no ticketing, don't know what I'm supposed to do/when. I think my manager is new. Oh well I'm grateful for the job. I at least have self-awareness (like someone else mentioned below) about not sh*tting on everything existing. No PRs, No tests, Code barely works from master, no docs how to get started, that's the kind of environment I'm in so it's not like it's not warranted but yeah. There's freedom in it too that's nice but I'm not used to it (defined tasks).
Edit: side note, other thing I don't like about this place, everybody's so separated, there are community events like happy hour (beer on tap) but in general everybody's in their cubicle/area and only talk to their small team. Idk why I care but yeah. In the past I'd have buddies to chat with in slack/teams but right now it's just me and my manager/co-developer. That's a weird dynamic too when you aren't sure how friendly/buddy buddy you can be with your manager/co-dev.
Sounds like an environment where you should not ask for permission and just implement whatever you need to be efficient. Ask for forgiveness instead.
I would implement the bare minimum of what I need (probably unit tests, integration tests, branching, some kind of DevOps, wiki, auto-generated testspec/test report).
It's interesting my manager is also a developer (we work on the same project). Possible I'm one of his first underlings. But yeah we get heated when we talk it sucks. I don't know what is considered done. Tasks usually have a defined goal. I sound dumb asking so I guess I'll just do. I'm not a newbie I'm more mid but not senior. I have the years but self esteem wise I don't consider myself a senior, still doubts. I will see how it goes, I really need to stay here a while and get out of debt.
> Make a token commit day 1 or 2 to show you can and will deliver, even if just docs. Ensure you can go end-to-end on a real code PR week 1, even if a trivial one. Identify which area of code is most important for you to learn, vs not learn, and focus there.
Even if you are not on the management track, as a “senior” developer, your first goal is to understand the business, the organization, etc.
I would not be committing code until I had a good understanding of the “why”.
For a senior developer thinking about the leveling guidelines I’ve seen first hand and the ones that are publicly available, coding is not the highest value you should bring to the company.
If I were to priorities your bullet points it would be the second, third and then the first.
Unless you live somewhere that has some form of probation, a token commit day 1 or 2 seems pretty meaningless. Everyone involved will see it instantly as that, a token commit.
Making an effort to learn the business (essentially the 'why' of your area at the company) is valuable of course.
Ex: I'd not expect a code commit to happen at a bank or most gov places, eg, you might be waiting for clearance for months to even see the real data!
There are many ways to set the tone, and code does speak. Great interns, senior engineers, PhDs, etc I have worked with have managed to get bits flowing the first day and week in great teams & companies environments I've worked with, and it's a pretty sure fire way to set the tone & build team trust. Multiple people often start at the same time, and everyone sees the difference. I've seen other folks do other things too, so it's not the only way. Whatever way, what you do, and not do, is a decision.
Other folks here are right to point out that not all Senior (Software) Engineers contribute code. Ex: The more senior you go, you get more differentiated titles than a generic senior eng, and part of that is splitting between management vs engineering. What an effective staff eng at Facebook vs Microsoft vs openai does on week 1 is an interesting question -- at an early stage startup, they would already be ramping up to deliver, so both the soft & hard side.
Yeah sorry -- I mean paid dues in diff ways, such as study and practice (earned), and having seen the realities of the business / software / last attempts (lived).
- Make a token commit day 1 or 2 to show you can and will deliver, even if just docs. Ensure you can go end-to-end on a real code PR week 1, even if a trivial one. Identify which area of code is most important for you to learn, vs not learn, and focus there.
- Get agreement on week 1 / month 1 / q1 goal for you+team+co with your direct peers, manager, skip level. Assuming a startup, also with CEO. Meet associated peers, like if an eng mang, other eng manga, and if a startup, head of X, Y, Z.
- Learn the business & product, eg, use it + shadow sales/marketing meetings.
- Observe culture and start acting: your first 30-90d is when you can make some changes by power and set tone, but doing any in weeks 1-2 are generally presumptuous as means you don't care about existing people & their earned & lived experienced. Change depends on seniority, eg, less senior can mean just adding better linting.