Senior Developer
Posted by BuilderNo3217@reddit | ExperiencedDevs | View on Reddit | 47 comments
Hi all!
I want to hear your thoughts. What would be your expectations for a Senior Software Developer in a span of 1-2months after joining the company (newly hired) ?
bbaallrufjaorb@reddit
i always find it annoying when new people come in and start dropping novel length proposals for sweeping changes, because “that’s the way we did it at TechWorkly”. i’d say don’t do that. instead, assume, at the start, that things are the way they are because everyone made the best decisions with the information they had at the time.
if you see things that don’t look quite right, definitely ask questions, people are usually more than willing to share how things got in that state.
once you know more of the full picture, and have more domain knowledge and code base familiarity, then you can propose changes.
there’s a good chance what you propose is already something that’s been proposed or tried.
boyarkate@reddit
We had a senior engineer join who is maybe 2 months in. They started doing this in month 1 and it’s been driving me nuts. I suspect it’s out of wanting to work in what’s familiar. I just shared with them that I appreciate questions and feedback, but they’re trying to boil the ocean and it’s overwhelming for the folks receiving the ideas.
bbaallrufjaorb@reddit
it’s funny how common it is, i’m 14 yoe and it’s been consistent the entire time, although i probably didn’t notice it as a junior.
i’ve discussed it with other dev friends and we think it’s like needing to prove yourself, or to show how smart you are, that you know there’s a better way. especially when it’s someone who’s been hired into the most senior role on the team (like a sr dev joining a team of jr and intermediates)
but yea, everywhere i go, i see this. not everyone though, but id say at least half
ColonelKlanka@reddit
100% a person wanting to prove themselves and make their mark. Probably alittle fear thing too.
vladvlad23@reddit
There needs to be a distinction between trying to change flows for your familiarity and changing them because they are plain wrong. People need to speak up if something fails.
What I would like to add here: yes, it’s true that doing this is in bad taste. However, as an experienced developer if you notice something not ok, you should speak up. You have that experience for a reason. This is why you are paid more than your junior counterparts. If the others tell you (in a polite, corporate way) “shut up, we thought of this, it doesn’t work”, you back up. However, it has been my experience that oftentimes if you come up with an improvement of the processes and you are right, it will be appreciated (and, more importantly, make your job easier which is the sole reason you should do it anyway).
GumboSamson@reddit
Showing up for work on time, consistently.
Asking good questions.
Learning everything they can.
Participating in code reviews.
Gaining trust with the team.
Producing useful work would be a bonus, but not expected.
TimMensch@reddit
I believe you that this is accepted in a lot of places. But.
High performing teams have much higher expectations.
I don't think I've ever joined a company and not had a commit/PR approved inside of two weeks. This includes my very first job out of college. Most jobs I have start, I've started being useful within days of going through the mandatory trainings and getting my laptop configured.
I do short term consulting contracts where my entire contract may be only two months long, and during that time I'll make major changes/improvements in whatever area they've hired me for. Sometimes I'll have my first commit done within a few hours.
From my point of view, I don't even understand what could possibly take that long to learn that would prevent them from making positive contributions for that long.
Like seriously. What can you possibly be learning that doesn't involve doing useful work? Even if you're doing it slowly, and partially wrong, and getting help from other developers for various parts? I can't even imagine legit "studying" anything and having it actually be useful learning without the doing part to make it stick. Even if there's another dev there holding your hand for your first commit, you're still working on something real, yes?
I feel like this entire comment section is a wishful thinking fantasy bubble. Sure, it would be nice to have months to slowly learn how to contribute at every new job. But unless the company is legit preventing you from getting work done by not giving you what you need to get started, an experienced developer shouldn't take that long to start contributing to a new code base.
ColonelKlanka@reddit
Key difference here is you are a contractor/consultant - we need to hit the ground running as there is expectation (rightly or wrongly) that contractor knows their stuff from day 1. Client often parasutes you in for short periods tonfiz things.
Ofcourse the reality can differ - Ive seen 1 week expectations of being awesome and alao I've seen clients happy for contractor/perm for 2 months before expecting fully up to speed and productive.
shifty_lifty_doodah@reddit
Jobs vary a lot.
In mature big tech orgs, your primary value might simply be your accumulated knowledge, not anything you produce. The one or two days a year you debug a big customer issue pays your salary.
These complex, mature systems have very low marginal productivity, and most of the value is figuring out what to do that customers might actually pay for
VizualAbstract4@reddit
Our goal is in the first few days, helps sort out any issues straight away. But you have a buddy for the first two weeks working with you on everything and shadowing each other.
TimMensch@reddit
Sounds entirely reasonable.
A buddy system has worked at a couple of places I've joined in the past.
GumboSamson@reddit
A high-performing team is much different than a collection of high-performing individuals.
Any time you add or subtract a team member, expect to go through Forming-Storming-Norming-Performing again.
By definition, a team who just got a new team member 4 weeks ago is not going to be performing at their best. And people shouldn’t expect them to.
Ratslayer1@reddit
not performing at their best != "not producing any useful work"
I onboarded ~5 engs, all senior, in parallel early last year, and they all had their own projects they were mostly leading by themselves within a quarter. Granted, they still needed to ask me for stuff now and then and my area did not have a huge preexisting codebase (ours was rather small), but we still needed to interface with all the infra of the company and they still managed to push their projects along.
IMO your goal should be to have them write code on day 1 or day 2 at the latest, so they learn how to build, run and test your service (manual and automatic), the development environment, code review process, deployment, etc. Otherwise they're gonna "read the docs/code" for 2 weeks and still need handholding whenever they actually do anything practical.
For the actual question, I'd hope they have either fixed the errors in or created an onboarding handbook, have met the relevant people, have a rough understanding of your service(s), relevant partner teams, your team's roadmap and goals, and shipped a few features, made new tests, or improved the codebase in some manner. After 2 months I'd expect them to be able to implement medium size features without much handholding.
TimMensch@reddit
Bingo.
I made no claims about relative productivity. Only that productivity should be greater than zero after two months. Really after two weeks.
Material_Policy6327@reddit
Wish to was like that at my company. They seem to expect new seniors to somehow be magical and instantly know what’s going on
rcls0053@reddit
This happened to me. Joined a project a year ago on a completely new domain (public sector), platform, codebase, and my predecessor gave me no training or guidance. Documentation was absolutely horrible or non existent (at least in the codebase). Somehow I immediately had to wear the hat of an architect, developer, scrum master and also a PO. And my time was split between two projects.
Customer expected I know everything from the start. Wanted answers from me. It took me six months to be comfortable in that position and the customer is really difficult. The onboarding process is really bad in some places, and expectations really high.
psaux_grep@reddit
Hope you’re being paid right
Hoizmichel@reddit
In my Job, ist's the other was rund. The "architect" ist not even a Senior Developer in my eyes, got the role just because He works the longest time of all team members in the company.... Let's say, that's a bad reason...
MaleficentCow8513@reddit
Management or peers? I started a new job as a senior last year and got that from a few peers, especially people a step below
VRT303@reddit
Two weeks 100% full time technical, domain and process onboarding with a mentor. After that should be taking a few easy tickets. By 1 month at least as productive as a mid level that's in the team for a while and by 6th month keeping up with every other senior and supporting those below and communicating with the business side and other teams to make informed decisions.
obelix_dogmatix@reddit
Nothing. Absolutely nothing, other than learning. We don’t even let a Senior engineer implement anything unless they have shadowed someone for 3 months.
BunchCrazy1269@reddit
Jesus.. I can tell ive joined a start up. I had a PR in production by day 2
BuilderNo3217@reddit (OP)
How I wish I’m part of your company. Lols
fued@reddit
yeah, I would say 80% of companies expect value delivered week 1 lol
Oakw00dy@reddit
Regardless of your skill level. months 1-2 should be onboarding, learning how the shop does business, getting familiar with the application domain and gradually getting more involved in production work.
Ok-Discipline-8923@reddit
true, growth often hides a lot of issues
anotherleftistbot@reddit
Start to learn the domain.
Start to learn the parts of the codebase that matter to your job. Just the modules and relationships. coding standards, prefer architecture.
Pick up some stories and bugs.
Contribute to team meetings (if only by asking questions)
Have 1:1s with the entire team.
Show them why they hired you and that you have the potential to operate at a team level and bring some good knowledge form your previous experience.
BuilderNo3217@reddit (OP)
The challenge is, they dont have coding standard, documentation about the applications and the people are not responsive. The worst part is, you’ll be tagged as underperforming because of not meeting their expectations for a senior in a span of 1-2 months.
Their expectation is unrealistic, to be honest.
anotherleftistbot@reddit
Sounds like a shitty environment but unless you want to be back in the job market, you'll need to figure it out.
Given that you don't have those things, what can you do to proactively jump in and make an impact?
Are you able to use AI to explore the codebase? To extrapolate common architecture patterns?
Onedome@reddit
Pretty spot on
OhNoItsMeAgainHaha@reddit
At Amazon - don’t get fired.
Material_Policy6327@reddit
Think you meant hired? Lol
OhNoItsMeAgainHaha@reddit
I said what I said
Teh_Original@reddit
Can't get fired if you don't get hired. https://en.wikipedia.org/wiki/Roll_Safe#/media/File:Roll_Safe_meme.jpg
OkChannel5730@reddit
Nah he meant fired**, that sounds about right!😂
BuilderNo3217@reddit (OP)
The challenges are, they dont have coding standard , documentation about the applications and the people are not responsive! The worst part is, you’ll be tagged as underperforming because of not delivering the tasks immediately and that’s how they measure the seniority of a dev. Like, wth?!
Is their evaluation acceptable?
Objective-Feed7250@reddit
Make one change, break three things, learn a lot.
SplendidPunkinButter@reddit
I have worked at several companies in my career and never really felt like I knew what I was doing until I was there for 2 years or so. Usually I’m reasonably confident by 1 year, and well on my way by 6 months.
The fact is any company just has a bunch of random stuff you need to know that’s specific to that company, and there’s no possible way you can learn it other than working there for a while. Saying you should ask questions is all well and good (you absolutely should do this) but usually there are important questions that you won’t even know to ask until you learn more about the weird random stuff.
Jazzy_Josh@reddit
Y'all please stop engaging with the obvious LLM model farming
Ambitious-Garbage-73@reddit
The red flag for me is when people hear "senior" and translate that into "should be fully effective in 3 weeks." In the first month or two I'd expect a good senior to figure out where the real risk is, ask the questions that expose how the system actually works, and start making small decisions that other people trust. Shipping something useful is great, but if they're still mapping the people, codebase, and hidden constraints, that's normal. The weirder expectation is instant certainty
onar@reddit
It also depends so much on the devex quality of the company. At Google you can start committing code in the first week, because every kink is smoothed put. At some legacy embedded company, it can take a week just to get to building the code.
Goodie__@reddit
Depends on how good your on-boarding process is, and what your code base looks like.
Horrible code base? No on-boarding help? They might barely be anywhere.
Reasonable code base? Good on-boarding? They could have rewritten half the app by then.
AsciiMorseCode@reddit
Understand why the weird decisions were made as it relates to your immediate domain, ship something useful, take lots of notes, ask lots of questions but only ask each question once, understand where you need to grow, have a top level understanding of the areas outside your specific role's domain (it not be a black box), and be able to at least understand the basic syntax of whatever language any part of your teams responsibilities are written in so you can at least dig slightly deeper than "your API won't work" or "your form is sending bad data"
vanritchen@reddit
Not being a dick
bigorangemachine@reddit
Depends.
If you got a experienced team you jumping into you best to hang back and read the room. Be receptive to feedback, ask a lot of questions, read a lot of code and shadow PR reviews
If you are on a team with direction and no technical leadership I'd be making recommendations left right and center.
For example I was brought onto a team with a lesser experienced dev as lead & project manager. Right away I had no tickets, I was idle/blocked and I'm like "Okay... does my consultancy have capacity for a PM" turned out we did... we got a PM to help them fill out the backlog... boom I'm unblocked and the consultancy is happy because I got some capacity used
Now we got the lead free'd up I'm teaching them typescript and running an agent to get the code updated. Now I've made several audits identified some basic security issues and show up to mob programming session asking "how do we know that" which often helps lead to people troubleshooting step by step rather than jumping to conclusions.
nyckulak@reddit
Expectations are higher than they’ve ever been. You really need to have delivered something within that span.
ElLargeGrande@reddit
They don’t come in expecting everything to change. They come in, learn for ~6-8mo, then start proposing change