It's not a comprensive list, but I would like advice or resources on:
- effectively learning key information to hit the ground running - knowledge management (checklists? Diaries?) - causing a good impression - positioning myself for impact - balancing adapting to the team with not absorbing established bad patterns - balancing being the people with less business context with being in a position where I'm supposed to lead
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?)
This is the best advice. And truly senior level people have been around long enough to see a lot of mid-level "senior" developers shoot themselves in the foot. I've also been on a lot of projects where bad practices aren't so bad because the team has strengths in other areas, and also best practices which collapse because the team has other deficiencies holding them back.
In a more functional and team oriented environment, your advice is absolutely critical.
Regardless, it's the personal relationships that are primary here. And there can be some nuance in how to handle those. Jumping in and alienating people would not be a wise choice :)
apparently from the San Francisco dot-com rush culture?
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.
With the power of LLMs, notes will be even more helpful as we come up with more innovative ways to parse our daily lives.
It's not a process, but I found this gives some structure to the chaos.
I work as a consultant so I need to do this when requested, but it gives me a quick way to remember details that I would otherwise forget and also quicky get to speed after a vacation or weekend by reading my notes and TODOs from the previous week.
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.
Upper management has no idea what anyone is doing, they will make layoff/promotion decisions that seem insane from the ground floor, so make yourself visible. I legit am still at my current role because of one demo I did that caught the CTOs eye. I was demoing something that took me maybe ~2 days and was relatively minor in my teammates eyes, but it got my name on his radar so I made the cut.
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
i.e. the entrenched incompetence and hype-driven career-butterflies left the firm with a smoldering pile of wishful thinking.
Sometimes, one can slowly migrate to something standard, sustainable, and reliable... Yet if the product is an established code base, it usually means entry level jobs become a glorified Janitor with a digital mop.
Due to the sunk cost fallacy, one usually won't be allowed to fix the core problems even if relatively trivial. =3
Luckily I’m at point of my career where I have nothing left to prove and my success metrics that I take to any company is that I can show I am “smart and gets things done”.
https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid...
And I can work at a staff (smaller companies) or at least a senior (BigTech) level of “impact”, “scope” and “dealing with ambiguity “.
https://www.levels.fyi/blog/swe-level-framework.html
I spent years railing against “Kubernetes everywhere”. But now it’s my go to for anything that’s even slightly complicated with multiple services. But still keep my databases, cache clusters, etc off of it.
If it’s a monolith, just use GitHub actions or Jenkins. Again something standard
It’s a known standard, it’s cross cloud (for the most part) and it works on prem. You can find people that know it easily and it’s easy to recruit career oriented people who want to know Kubernetes or who already know it.
It’s just like standardizing on React on the front end.
My wife and I travel a lot and we have done the digital nomad thing for a year.
I go out of my way not to talk about that at work because I don’t want people to say I’m “being distracted” or when I actually do have something like doctors appointments for them to think that I’m goofing off during work hours.
I worked from 15 cities the year before last.
That’s partially PTSD from my time at AWS (Professional Services).
A good strategy is to listen to other person, read what they want to talk about, and ask follow-up questions in that direction. Is the person only talking about work? Fine, talk about that. Did they mention their favorite team, or offer up an anecdote about their partner? Then follow up on those.
I find this all very difficult. I don't like asking personal questions because it feels like prying. I don't like talking about myself or my family until, like, at least a year goes by. But, everyone is different, and it's important to meet people halfway, not just wherever you are, on the social spectrum.
>> "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"
I'd summarize and simplify your "What to do" by simply saying: Be curious but not annoying.
We have an extremely background (3x Founder/CTO + A bunch of other things). The largest issue I would find with new hires is simply a lack of curiosity and a desire to "perfect" everything without an appreciation for "why". It comes across as extremely arrogant and ignorant, and even more so when the individual becomes frustrated when they're not given free reign to implement their suggestions.
> We have an extremely ??? background (3x Founder/CTO + A bunch of other things).
Start humble, ask questions, don't alienate anyone, set up 1:1s with lots of people where you ask them for their perspective and advice. Listen listen listen.
Figure out who might be threatened by you and earn their trust.
- 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.
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.
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).
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.
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.
Almost every time I join a company/project, they don't have even remotely accurate docs about how to set up a development environment (configure workstation with prerequisites, check out the code, run the code).
If they already have a wiki page you can start editing, great. If they have a wiki without such a page, great. If they're open to having this info in the README.md of the repo, great.
Document everything you have to do, which the next hire probably will have to. (Example: Don't have some credential or authorization to access the repo? Ask around for how to get it, someone tells you that you go ask person X? Document who someone should ask if they don't have that thing.)
If you're not sure whether you'll be stepping on toes, make the notes in a file in your home dir, as you're going through it, and later ask someone about whether it'd be helpful to new hires to put it in the wiki/repo/etc.
When you've just joined from outside, you're in a unique position in that you haven't internalised yet all the little idiosyncrasies. Best to take note of them, understand the context, and maybe help change them.
1. Meet a lot of people through 1:1s, both from tech, leadership and customer side.
2. Get the codebase working on my machine, document anything that's missing from the docs they already have.
3. Ask questions in the open - in a team Slack rather than DM'ing people. Everyone can learn from my questions, and in a team Slack it'll be searchable.
4. Understand from my lead (director) on what the short and long-term goals of the org are. And then talk to others to see how they fit with that story :)
5. Ask about what the role expectations are, how they do performance evaluations, etc etc. I'll ask this to my manager and peers to get a better view.
---
There's probably more that I'll do once I actually start, but this is the quick list of what came to mind.
Listen a lot, keep a notebook, don't go in with the idea that you are going to make the product better, go in with the idea that you're trying to find ways to make the team better at making product.
Sometimes that takes mentoring, sometimes that takes technical leadership, sometimes that takes being the person who can help others see each other's perspective.
Be really clear with your manager about what you learn your evaluation of the current situation and look for and listen to feedback to gauge your discernment accuracy.
Always ask people you meet what could you help them with, what would make it easier for them to accomplish what they are trying to accomplish.
Finally, take time to do things that a 'junior engineer' would do as part of the program of helping. People will want to know you can work at all levels and that you aren't just some 'high level thinker' who doesn't understand how things really work.
I have always advised new senior engineer hires, even though you're senior you are going to have to go through your entire career in speed run mode it seems at the new place so that people understand how you got to be senior.
Start to get to know people, and focus on learning about them and what they do.
Don't start immediately dispensing wisdom / advice / opinions unless asked, take time to really understand what has come before you.
At the same time, be helpful to build rapport, if you see someone more junior post a trivial problem on Slack (ie: "getting this error in Docker..") then jump in to help.
Take notes, and make onboarding better for the next person. Are the onboarding docs unclear? is setting up a dev-env the first time somewhat convoluted? Make meaningful and appreciated improvements.
Learn about the product, the customer experience, and be a user of the product to the best of your ability. Make contact with customer support folks as well to learn more about their jobs, pain points they see, etc.
[0] https://medium.com/feature-creep/the-software-engineer-s-gui...