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.
Great list - especially the "what not to do". The most self-destructive thing you can do is be the new guy that shows up talking about how everything is shit and needs to be rewritten with your favorite stack. I have seen so many autist senior engineers come in and completely self-sabotage their employment with that move.
On point 4: keep these work-focused. Don't ask about families, hobbies, "what are you passionate about," what sports they follow, etc. Fine to discuss that if it they volunteer it, but as an developer I always felt put on the spot by those sorts of questions, even if they were meant with friendly intent.
Very important to be able to read the room on this one. Some people love to talk about themselves, and are turned off if you do not engage with them. Others are very private and don't want to discuss anything outside of work. A fair number of people are right in the middle.
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.
Exactly this. I keep my personal life and work completely separate.
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).
Indeed. I've heard people getting laid off, for other similar personal reasons, first over others because "well, A has kids and B doesn't, B can doesn't have to support anyone so we'll let B go first." One should not give an employer any more reasons than necessary to lay one off over others.
In general, some spend a large portion of that part of their career cleaning up dysfunctional projects.
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
> i.e. the entrenched incompetence and hype-driven career-butterflies left the firm with a smoldering pile of wishful thinking.
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”.
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.
>> "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.
The what not to do section is basically Chesterton's Fence [0], if anyone was curious.
> There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.”
This is great advice. The first x days change freeze on anything you'd like to implement / 'improve' is crucial.
Definitely note down everything that you think is a good idea. By time you reach those first few months and you have context you will likely cross most out. See the concept of "Chesterton's fence" for more.
Ask the flip side during #4 as well - what do they love about the work, that would bring great disappointment if it were to change?
Aside from getting more info, it keeps the conversation positive. Nothing brings fear into an organization like a new leader who calls everyone into 1:1s and only digs into the negative.
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.
Notes are extremely helpful, including those about coworkers you meet. Write down every detail during or after your meeting. Use a mind map program (miro works ok).
With the power of LLMs, notes will be even more helpful as we come up with more innovative ways to parse our daily lives.
Notes are important for me.. I write a (private) timestamped diary which I can go back to and find out why I did something at a specific time when asked about it.
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.
On the topic of notes: are there any standard formats you prefer: I've been guilty in the past of ending up with a chaotic endless MD and I'd like a bit more process
Not the OP, but I've ended up on a good note taking pattern that works for me. I create a new folder each week with the week number of my time of employment as the name. Then, all notes for that week get put in that folder. I don't know why, but this works for me. I think knowing there's a place for them that I know I can find them later lowers the activation energy I need to take notes. Also, I put the top-level folder in my `CDPATH`.
It's not a process, but I found this gives some structure to the chaos.
I recommend Logseq if you're taking notes on a computer. Takes a moment to wrap your head around an outliner if you haven't used one, but after a short while notes will fly from your fingertips.
Being able to quickly jot things down and later revisit and expand them is crucial. Logseq also gives you a fresh journal for each day, and you can make and reference your own topic-specific pages as well.
This is a pretty low-level mechanical thing, but your first day/week is the best time to do it...
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.
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?)
> 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,
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.
Well a lot of this depends on context. I've worked at a place where (for reasons beyond my knowledge), there was a pre-existing false conception of my experience and level. In that situation, it was important to disprove that false perception early. Especially in a competitive environment, establishing your cred is important.
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 :)
It is surprising that this still happens, but I’ve had senior engineers (L6-L7 from FAANG) join my teams (multiple examples, different companies) and in the first couple days make extremely superficial but strong arguments on how the architecture of a system should be completely revisited, and how libraries that have been in production for years should just be rewritten from scratch asap.
In virtually all cases the suggestion was extremely naive and coming from a lack of understanding of all the requirements. This did not come from a curious angle “wondering if we could do X?”, it was always based on some ground truth they knew better.
Very calmly, you start explaining to them all the key requirements that they just missed in their grand vision. Upon hearing those, some will decide to double down and come up, on the spot, with increasingly complex and arcane evolutions of their initial proposal (this is always very comical, and painful to witness), while others will quickly get the message and basically say “oh sorry, seems like I lack a lot of context, please ignore”.
And let’s not even talk about their first code reviews.
I truly don’t know what goes in someone’s head when they decide, shortly after joining, to dismiss years of work of a competent team who has objectively solved problems for the business.
My experience is limited to technical teams in technology companies (primarily CA Bay Area based), as such what I've experienced and learned may not be as applicable to what you're getting into. That said, there are some common things I've noticed, and one is that 'new senior guy' is a disadvantageous position to start in. Generally due to the competitive nature of such places there are others in the team who probably feel they would have been a better choice to fill your new role.
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.
Something that has always been really appreciated, and can be an easy "first commit": update/complete the docs. There's always a missing step, something unclear, an outdated link, and undocumented "whys", something to automate, ...
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.
Figure out the core technologies they use and become an expert at them. Read the documentation of those technologies like a book. Is kafka at the heart of the stack? Learn everything related to kafka and setup a small dummy instance to play around with. This can take some time but after a couple of months you'll be more knowledgeable about the technology than many people on the team who have been there longer.
- 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).
I’ve always treated my first days on any job as “my job is to make the (inevitably outdated) onboarding docs as good as possible.” That way you can contribute from day one, and you hopefully lower the rope ladder some for the next new hire.
Dig in to learn the details of how your systems and software work, do this by getting local dev resources set up, reading docs/diagrams, etc.
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.
Go in, set up your laptop. Take notes, update the welcome docs, and provide it to the team to consider merging in. Don't go in trying to change everything on day 1. Listen. Provide useful advice. Start providing value. Meet everyone, and understand how they like to work and be managed. Do you need to manage up? Down?
I'm starting as a Staff SDE at a new company next week, and this is roughly my onboarding plan:
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.
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.
Hah, good old Gource! I once organized a project completion event with cocktails, Gource projected on the wall and Monolake CERN playing in the background.
Just joined a new team as a senior dev last fall and went through this. I simply worked my ass off the first couple of months and asked a lot of questions and banged out some very high quality initial commits to make a strong first impression. Have a zen mind/open mind, things will be different and you may not care for some of the approaches taken. Play the long game and gradually make suggestions and changes as you get to know the landscape. My initial feedback from management was very positive, so this approach worked for me.
There was a discussion about 8 months ago about a "wtf" journal and all of the things that need to be considered about current processes and team dynamics before you start making big (and effective) waves. A lot of the points are already made in the replies here, but it was a good discussion and article you may be interested in:
Try and talk to the other seniors? Last time I joined (fully remote) I asked all the other seniors for a 1 to 1 - not all replied but I learnt a huge amount about past projects, what people would have done differently and where the pain points were. Meant I could get a jump on the issues rather than find out slowly. You also get a sense of the weather and who you can vibe with. Oh yeah, taking notes about everything!
In a senior role, you'll spend more time working with people who aren't developers. PMs, designers, managers, etc. In your first few weeks, book a little bit of time to meet them. They'll appreciate the forwardness, you'll quickly expand your network in the company, and it can be the start of a good working relationship that pays off 3-6 months later.
Yeah this is the biggest difference imo. You have to play the game at the senior+ level, that means no more just doing tasks and then sitting back. You have to reach out to people and schedule meeting, you have to be speak up during team meetings, you have to do tech talks and demos.
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.
Building a reputation is important. Can you make a contribution immediately? I was pulled into a firefight where the biz folks were micromanaging the tech folks with twice-daily meetings, with little progress being made. Two or three obvious and immediate fixes later I was able to cut the meetings back to daily and after a few more to weekly.
Set up your dev environment and get the project running locally. This can take anywhere from 2-3 hours to a week. But if it does take towards the longer end of that period, you will have learned tons about the application's architecture, past design decisions, and will probably have made at least 1 git commit to a README somewhere.
#1 Listen
#2 Listen More and be patient.
#3 Resist the urge to fix things that aren't broken. It may not be the way you would do it but recognize this as an opportunity for you to learn.
#4 If you do items 1, 2, and 3 you will see where you have an opportunity to contribute constructively.
You're going to enter a complex political environment that has developed over years.
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.
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
Great list - especially the "what not to do". The most self-destructive thing you can do is be the new guy that shows up talking about how everything is shit and needs to be rewritten with your favorite stack. I have seen so many autist senior engineers come in and completely self-sabotage their employment with that move.
On point 4: keep these work-focused. Don't ask about families, hobbies, "what are you passionate about," what sports they follow, etc. Fine to discuss that if it they volunteer it, but as an developer I always felt put on the spot by those sorts of questions, even if they were meant with friendly intent.
Very important to be able to read the room on this one. Some people love to talk about themselves, and are turned off if you do not engage with them. Others are very private and don't want to discuss anything outside of work. A fair number of people are right in the middle.
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.
Exactly this. I keep my personal life and work completely separate.
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).
Indeed. I've heard people getting laid off, for other similar personal reasons, first over others because "well, A has kids and B doesn't, B can doesn't have to support anyone so we'll let B go first." One should not give an employer any more reasons than necessary to lay one off over others.
In general, some spend a large portion of that part of their career cleaning up dysfunctional projects.
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
> i.e. the entrenched incompetence and hype-driven career-butterflies left the firm with a smoldering pile of wishful thinking.
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.
This is an amazing response. In particular this.
>> "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.
I'm curious what word was missing from this
> We have an extremely ??? background (3x Founder/CTO + A bunch of other things).
lol...weird brain fart: "similar" was the word i was hunting for
The what not to do section is basically Chesterton's Fence [0], if anyone was curious.
> There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.”
[0] https://fs.blog/chestertons-fence/
This is great advice. The first x days change freeze on anything you'd like to implement / 'improve' is crucial.
Definitely note down everything that you think is a good idea. By time you reach those first few months and you have context you will likely cross most out. See the concept of "Chesterton's fence" for more.
Ask the flip side during #4 as well - what do they love about the work, that would bring great disappointment if it were to change?
Aside from getting more info, it keeps the conversation positive. Nothing brings fear into an organization like a new leader who calls everyone into 1:1s and only digs into the negative.
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.
Notes are extremely helpful, including those about coworkers you meet. Write down every detail during or after your meeting. Use a mind map program (miro works ok).
With the power of LLMs, notes will be even more helpful as we come up with more innovative ways to parse our daily lives.
Notes are important for me.. I write a (private) timestamped diary which I can go back to and find out why I did something at a specific time when asked about it.
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.
On the topic of notes: are there any standard formats you prefer: I've been guilty in the past of ending up with a chaotic endless MD and I'd like a bit more process
Not the OP, but I've ended up on a good note taking pattern that works for me. I create a new folder each week with the week number of my time of employment as the name. Then, all notes for that week get put in that folder. I don't know why, but this works for me. I think knowing there's a place for them that I know I can find them later lowers the activation energy I need to take notes. Also, I put the top-level folder in my `CDPATH`.
It's not a process, but I found this gives some structure to the chaos.
I recommend Logseq if you're taking notes on a computer. Takes a moment to wrap your head around an outliner if you haven't used one, but after a short while notes will fly from your fingertips.
Being able to quickly jot things down and later revisit and expand them is crucial. Logseq also gives you a fresh journal for each day, and you can make and reference your own topic-specific pages as well.
This is a pretty low-level mechanical thing, but your first day/week is the best time to do it...
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.
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?)
> 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,
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.
Well a lot of this depends on context. I've worked at a place where (for reasons beyond my knowledge), there was a pre-existing false conception of my experience and level. In that situation, it was important to disprove that false perception early. Especially in a competitive environment, establishing your cred is important.
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 :)
It is surprising that this still happens, but I’ve had senior engineers (L6-L7 from FAANG) join my teams (multiple examples, different companies) and in the first couple days make extremely superficial but strong arguments on how the architecture of a system should be completely revisited, and how libraries that have been in production for years should just be rewritten from scratch asap.
In virtually all cases the suggestion was extremely naive and coming from a lack of understanding of all the requirements. This did not come from a curious angle “wondering if we could do X?”, it was always based on some ground truth they knew better.
Very calmly, you start explaining to them all the key requirements that they just missed in their grand vision. Upon hearing those, some will decide to double down and come up, on the spot, with increasingly complex and arcane evolutions of their initial proposal (this is always very comical, and painful to witness), while others will quickly get the message and basically say “oh sorry, seems like I lack a lot of context, please ignore”.
And let’s not even talk about their first code reviews.
I truly don’t know what goes in someone’s head when they decide, shortly after joining, to dismiss years of work of a competent team who has objectively solved problems for the business.
I mentioned this in another comment but this is basically the parable of Chesterton's Fence.
My experience is limited to technical teams in technology companies (primarily CA Bay Area based), as such what I've experienced and learned may not be as applicable to what you're getting into. That said, there are some common things I've noticed, and one is that 'new senior guy' is a disadvantageous position to start in. Generally due to the competitive nature of such places there are others in the team who probably feel they would have been a better choice to fill your new role.
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.
Something that has always been really appreciated, and can be an easy "first commit": update/complete the docs. There's always a missing step, something unclear, an outdated link, and undocumented "whys", something to automate, ...
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.
I like this idea a lot. It's a really low-hanging fruit to get yourself committing code immediately.
Figure out the core technologies they use and become an expert at them. Read the documentation of those technologies like a book. Is kafka at the heart of the stack? Learn everything related to kafka and setup a small dummy instance to play around with. This can take some time but after a couple of months you'll be more knowledgeable about the technology than many people on the team who have been there longer.
Assuming not management track:
- 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.
Do your best I'd say. Don't pitch anything half-baked but your environment is ripe for earning understanding. Recalibrate often.
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.
Yep very contextual as replies show!
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.
"earned & lived experienced" - what is an earned experience? How does that differ from a lived experience?
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).
I’ve always treated my first days on any job as “my job is to make the (inevitably outdated) onboarding docs as good as possible.” That way you can contribute from day one, and you hopefully lower the rope ladder some for the next new hire.
Dig in to learn the details of how your systems and software work, do this by getting local dev resources set up, reading docs/diagrams, etc.
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.
Go in, set up your laptop. Take notes, update the welcome docs, and provide it to the team to consider merging in. Don't go in trying to change everything on day 1. Listen. Provide useful advice. Start providing value. Meet everyone, and understand how they like to work and be managed. Do you need to manage up? Down?
I'm starting as a Staff SDE at a new company next week, and this is roughly my onboarding plan:
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.
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.
Hah, good old Gource! I once organized a project completion event with cocktails, Gource projected on the wall and Monolake CERN playing in the background.
Actually a good book: https://www.amazon.ca/First-Days-Updated-Expanded-Strategies...
Just joined a new team as a senior dev last fall and went through this. I simply worked my ass off the first couple of months and asked a lot of questions and banged out some very high quality initial commits to make a strong first impression. Have a zen mind/open mind, things will be different and you may not care for some of the approaches taken. Play the long game and gradually make suggestions and changes as you get to know the landscape. My initial feedback from management was very positive, so this approach worked for me.
There was a discussion about 8 months ago about a "wtf" journal and all of the things that need to be considered about current processes and team dynamics before you start making big (and effective) waves. A lot of the points are already made in the replies here, but it was a good discussion and article you may be interested in:
https://news.ycombinator.com/item?id=40078106
Try and talk to the other seniors? Last time I joined (fully remote) I asked all the other seniors for a 1 to 1 - not all replied but I learnt a huge amount about past projects, what people would have done differently and where the pain points were. Meant I could get a jump on the issues rather than find out slowly. You also get a sense of the weather and who you can vibe with. Oh yeah, taking notes about everything!
In a senior role, you'll spend more time working with people who aren't developers. PMs, designers, managers, etc. In your first few weeks, book a little bit of time to meet them. They'll appreciate the forwardness, you'll quickly expand your network in the company, and it can be the start of a good working relationship that pays off 3-6 months later.
Yeah this is the biggest difference imo. You have to play the game at the senior+ level, that means no more just doing tasks and then sitting back. You have to reach out to people and schedule meeting, you have to be speak up during team meetings, you have to do tech talks and demos.
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.
The optimal strategy was pretty well-documented[0] back in 2016 (nsfw warning: language, humor, mistreatment of eggs)
[0] https://medium.com/feature-creep/the-software-engineer-s-gui...
Building a reputation is important. Can you make a contribution immediately? I was pulled into a firefight where the biz folks were micromanaging the tech folks with twice-daily meetings, with little progress being made. Two or three obvious and immediate fixes later I was able to cut the meetings back to daily and after a few more to weekly.
Set up your dev environment and get the project running locally. This can take anywhere from 2-3 hours to a week. But if it does take towards the longer end of that period, you will have learned tons about the application's architecture, past design decisions, and will probably have made at least 1 git commit to a README somewhere.
To add to what others have said, I would ask every person in my team what's the most important think I need to know.
Also ask the name of someone I need to meet. This helps find the load-bearing people who are sometimes invisible on the org chart.
#1 Listen #2 Listen More and be patient. #3 Resist the urge to fix things that aren't broken. It may not be the way you would do it but recognize this as an opportunity for you to learn. #4 If you do items 1, 2, and 3 you will see where you have an opportunity to contribute constructively.
You're going to enter a complex political environment that has developed over years.
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.
I observe what the company is doing, and from there deduce what needs to be done. Then I execute.
Like any new job in which you are unaware of the context or politics; with your mouth shut.
Listen more than you speak.
Don't be afraid to ask. They know, you know, everyone knows what a release is supposed to be in theory but only _they_ know how _they_ do it.
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?