I am 1 month into my new position, same position you're in - new stack & straight into senior role. My tips so far:
1) Take over all the admin stuff you can to free up your devs from distraction and pointless tasks. Productivity and morale will immediately go up. My guys were time reporting into 3 different tools (and this is a <10 person startup!), I just started writing a summary of our standups and told them they didnt have to do it individually any more, it was appreciated and mgmt still get the info they need.
2) Start with infrastructure stuff - how do you deploy, what's your build process, can anyone on the team draw an architecture diagram (mine couldn't)
3) Write tests, it's low risk changes to the codebase so you cant really break anything, but it'll give you the black box overview of how everything hangs together, detail will come in time
4) Accept that there's no way to immediately get to the level of familiarity the guys who built the system will have. I can spend 2 hours digging trying to find how widget x gets its props passed in, or I can ask my teammate who wrote it and immediately known which file and line its on.
As I have written in previous post, this is where IMO a step-debugger earns its keep.
As an IC basically my entire life, I have joined large legacy projects many times, and my typical attack strategy always revolves around a large cup of coffee and my trusty debugger. Using 2 monitors, starting at main() or index.php (or whatever of course), I will execute as much of the entire codebase as possible line-by-line.
At first I will blast through the code looking at general structures and entry/exit branches and the like, and note things and often breakpoint sections that seem hairy or where I can note inefficiencies or great design.
Then I slow down the stepping and really examine the heavy-lifting sections to try to become familiar with the style and abstractions being used.
This method has served me well, as more often then not, by the first day's afternoon I can be having intelligent conversations with the existing team, almost always much to their confused surprised.
I suppose it matters much if you are going into the senior position as really strong head-down coder or as really more of a project management liaison.
Not being much into the management side of things, I don't have much advice on that role, and your suggestions sound really smart.
I've tried a similar approach in the past and it just does not work for me. Besides the fact that it is very tedious, I don't retain any of the knowledge because it's like reading a dictionary. It's impossible to absorb that much information, for me at least.
My approach to learning a new codebase has always been to do a general overview of the structure while taking notes. Then just assign myself some easier bugs and start working on them, and then slowly moving up in complexity.
I recently joined a company as a senior developer with a partially unfamiliar stack, and it's very interesting to me how much my style of learning contrasts with others in that way.
I regularly am recommended to "read through all the docs, step through all the code", which might work for some. My brain just wants to switch off whenever I do that.
Instead a day or two of fixing problems - implementing a fix, seeing how/why it doesn't work, trying a new one - suddenly I get it.
One of the things I see in your comment that marks you as more senior is you didn't say "push it out" on the fix but "see how / why it didn't work, trying again". Just because you wrote code doesn't mean it needs to go out, just because a systems isn't to your brain's pattern doesn't mean it needs to be gutted and aligned with your brain immediately upon encounter.
I just wanted to mirror this because often the entry points to various parts of the application is what defines seniority with the particular codebase. The challenges for building how the thing starts and stops as well as the build is something that everyone is currently relying on to do the good work they are doing now. A lot of hard won stability/system issues are solved in that kind of area which dramatically affects what is in the possible vs. something from a wildly different tangent then what's already there.
Really confused as to why you were downvoted as you were the person being asked what IC stood for...
Pretty sure it's because they assumed IC was Individual Contributor but to downvote the "least common answer" is weird seeing as how, in this case, it's the source...
I love this suggestion - using a debugger to walk through as much of a new codebase as possible. Definitely going to try this it next time I need to familiarize myself with a new large codebase.
Great tips, but I would add that those 2 hours spent exploring the code can actually be useful. I often need to read the code a few times before the big picture starts to come into view, so unless I need an immediate answer, I usually prefer to dig for it myself.
I think digging into the code for 2 hours solo is very important. If you still can't find it, ask a senior dev. Actually being familiar with the code is important to be able to nail down how things work abstractly to the actual implementation. Code is the ultimate source of truth. You are going to reach a point where you come to code written by an engineer who has left and nobody else understands. You will also need to dig into an open source project at some point without any help.
I found it easier to get a new project if you focused on support tickets as a new hire. It is quite something to be able to be productive and see some dark corners of the stack earlier on.
I love all of your advice, but I would start straight-away with writing tests. Not only is it low risk, it is the best way to start understanding the code base, and gives you an avenue through which you can start introducing small refactorings. The other important thing is that developers LOVE to have outside help with testing and a pair of fresh eyes to look at the test-suite through.
Start by adding a whole-system black box end-to-end test, if there aren't already any good ones. Ideally fully automated and automatically run for every commit via CI, but don't let the perfect be the enemy of the good, take what you can get for starters.
Benefits:
(1) You only really need to know the system as a user, not the codebase as well, to do this.
(2) Well, #1 was a bit of a white lie. You'll end up finding out about all the (possibly undocumented) runtime dependencies this way, spinning up throwaway VMs and databases, etc. If the project is in production, this will be very useful knowledge, since you're probably the last point of escalation for strange prod issues.
(3) Running this out of CI with throwaway VMs/containers will also force you to fully automate the install and make the damn thing actually work on a generic blessed OS configuration, which might be a huge boon to your team if you currently are in "Works on my machine" hell. I did this somewhere where we had tons of lost productivity because developers used OSX or Ubuntu on their workstations, but prod was RHEL, and the most fascinating deviations would be found by developers chasing the strangest of bugs. Making the install reproducible so we could have CI totally ended this.
(4) If you don't have this already, and you set up infrastructure to gate commits on this test passing, team love and productivity will rapidly go through the roof as suddenly your developers aren't spending half their time fighting each other's build breaking changes.
So yeah, it's just one thing, but it leads to so many benefits it's definitely where I would start.
I've had the same experience. I'm sure it's somewhat context dependent, but if the code amounts to business rules and they are not documented, which is very common, you can only reverse engineer what the system _does_ and then write tests for that.
Of course you can ask people who are more familiar but whether you end up helping or being a distraction then is an open question.
Yeah, whenever new hires complain about the lack of
completeness or correctness of documentation, I'm like: that's a great place for you to start. It also seems to be a great signal of the attitude of the new hire, because the people who kind of groan at that task usually end up having problems.. but that's another topic altogether.
As a (junior) new hire in a group without very complete or correct documentation, I'm not sure I can agree with that. It can be nigh on impossible to try to improve documentation for complex systems without a very deep understanding of the stack. I could spend hours writing documentation but it's not useful when I don't know what is and isn't an intended behavior. I think a fresh face is a great asset to have for writing docs but they need someone with a very good understanding of the system to work with them. Some of the most frustrating times I've had had a junior dev have been documentation tasks for things I did not know very well, spending time poking the system to gain understanding and more time writing clear docs, only to hear that my docs are 'not how it works' and I had either setup and configuration wrong or need to file bugs so it works how it's 'supposed to', even though that is the exact documentation it's lacking. Maybe this is different for projects with less technical debt, where if the current behavior was documented that documentation would be useful. I think this habit of giving documentation tasks to the least knowledgeable people on a project, even though it's reviewed by those with more knowledge, makes the docs suffer.
This is a bad idea. Definitely well intentioned, but has a lot of bad side effects. Especially at big companies, I was instead actively encouraged to dive right in, make very small changes to existing production code & submit it for a code review. That gets you started in the right direction asap, because the feedback is direct - its pertinent to your code that you wrote, so you feel it viscerally & begin understanding the code even though 10 minutes back it was an opaque mudball.
If you become a waterboy, you will definitely be appreciated by the team, productivity & morale will go up etc - But you personally didn't sign up to be a waterboy! You came to be a player. So play.
You can't go from being a standup-summarizer or infra-support-guy to your regular senior developer role. If you are any good at those ancillary roles, you will be playing those roles for a long time. Every day doing infra is a day not doing regular dev - that's just the way it is. I have been there & its not fun. These ancillary roles have a way or morphing into a fulltime job, and soon that's what you'll end up doing.
This isn't WMA/CAA where you start in the mailroom and few years later you become Hollywood's top producer greenlighting 100 million $ movies. It simply doesn't work like this in tech companies.
I think the parent was the lead taking the onus off his direct reports. In such a case, improving your team morale and productivity is more important than closing out a couple of 1 point stories.
On the other hand, if the team were peers in the org chart, I agree with you.
As a senior dev my role is to stay away from doing those tasks as much as possible. Well functioning organizations do not keep senior devs to do the stuff that junior devs can.
My first task at a new team is to have a 1:1 with my manager to set our relationship properly and this includes laying out all expectations.
Typically managers understand that it takes some time to get productive. Do not waste that time by doing tasks that do not increase your productivity. You should be learning the codebase, the development process, etc.
Fixing bugs is one way to do it, but not necessarily the best. You may easily spend a lot of time on this, not gain much insight and actually not make a good impression as your colleague with much more experience will do it in 1/10th of the time.
Also, starting on the right foot with the team is also important for your future productivity so it may be necessary to do some of those tasks anyway, but always remember that at the beginning your job is to build a good base for your future work.
I'd agree with this but I also do 1:1s with the rest of the engineers on at least a monthly basis. They use it as a sounding board, career advice, or general design meetings. The don't often happen but it gets them in the practice of talking to you over issues and other things. It also gets you a lot of insight into their thought processes and general issues of the team. I find this works better than just reviewing every single commit and commenting on them, it lets you get into the meta more. And it gets you there before the code is written so it removes the "but it's real close can't I just push" drive most devs have.
Also I'm assuming this is a web app but taking over a live project is a bit like getting handed a gun, you should check if it's loaded before handling it ;) at the least run a vulnerability scanner over your app to look for security issues
Burp scan, zap scan are two products for penetration testing / vulnerability scans. They mount organized attacks on your web site. They look for stuff like sql injection and xsrf, and all that.
Burp has a broader scope because it does fuzz-style random testing. Zap is more reproducible. (Burp can be a pain in the neck because it doesn't reliably retest stuff it found.)
Be gentle with your new developer colleagues as you present them the results from these tools. They almost always find a couple of more-or-less silly vulnerabilities.
The existing devs will hate you. They already knew how it worked - now they may not even you've finished - and unlike normal refactoring you never knew how it was supposed to work.
This is a good way to cut the velocity of whole project so you don't look as lost though.
I don't think the point is to move the refactor into production. The refactor is a learning exercise. But if you start on the least understood, ugliest parts of the code the devs might welcome a refactor of those bits.
Note, I did not say "commit to Production". Just set up the feature branch and tear it apart. Most code out there has 0 comments and uses conventions from when it was written (god help you if it's a legacy product)
In that case this is a good idea... I apologize for my skeptism. I've experienced the someone doing this and then committing to production though - I left that team as soon as possible...
Nah, I usually just do a feature branch, refactor items with better stuff and we can then cherry-pick anything that's sexy and still fits our business needs once we've talked it over.
regarding 1), isn't there a danger that you can end up being seen as an admin monkey by the rest of the team leading to them undervaluing your technical knowledge?
I'm sure that they appreciate it, but that's not necessarily the same thing as it's good for the team in the long run.
The trick is that then he is the throughput of his team into all the systems. So he can see if someone is having trouble with a bit of the code i.e. they haven't finished a part of the project. The Senior Dev can then pair code etc to help out. This will assuage the admin monkey syndrome when an answer comes up.
But the answer is brilliant cause it also gives him the ability to see what his team is working on and how they are working on it.
Also talk to your QA and make sure they understand the level of throughput possible for your team. QA can unintentionally kill a struggling project by overloading the tracker with bug reports.
"burning condition" should not be a persistent state. Job #1 should be getting it back to a healthy state, where people feel comfortable working normal hours.
>> I just started writing a summary of our standups and told them they didnt have to do it individually any more,
>> it was appreciated and mgmt still get the info they need.
I'm skeptical that management would need a daily status.
You don't need nightly builds either - but they can be useful. Shorter feedback cycles / faster iteration has a lot of benefits. Also depends on how far up the management chain you're going.
If you've got critical bugs live in production, "management" may be the ones ensuring all the hot potatos are in fact being handled by someone - that nothing is falling through the cracks, that everything is being addressed, that QA is on top of testing hot new changes that need to be rolled out ASAP. Daily isn't frequent enough in this context.
Burning through the QA backlog leading up to a big release in ye olde milestone driven waterfall style schedule? Daily might be frequent enough.
Long term feature work? Might be able to go weeks between updates - but a daily ping of "still working on X, still on schedule" takes what - 5 seconds to email, 5 seconds to read? Helps keep the mental burden of juggling everything in your manager's head down, maybe helps reassure them you're not going to pull a "so yeah, we've still got a month of work left at least" on delivery day when they're reporting up to their management. They might not be able to help you get your task done faster, but they might be able to rearrange other parts of the schedule to keep their stakeholders happy (e.g. X is running into delays, but we can give you Y ahead of schedule). Even if they can't do anything to help the schedule, they can start managing expectations ahead of time, prevent unseemly "surprises."
And hey, daily status reports are better than daily status queries.
Keeping management informed via daily email does not scale. Nor via phone or meetings. All this daily distraction nonsense.
Have a high-overview webpage where they can look it up by themselves if they need to.
This is faster than daily and gives much better and accurate info. It's your task to communicate
the metrics, scheduling problems, cost overruns and feature creep.
> Have a high-overview webpage where they can look it up by themselves if they need to.
Who keeps this up to date and well maintained? I see little fundamental difference between pushing metrics/status via JIRA and pushing via email. Both scale (or don't) just as badly. Both require distraction from your development tasks to properly estimate or summarize status/problems.
Don't get me wrong - keep the daily distraction the hell in check. But there's no magic bullet to make good communication free, and there are plenty of people and contexts where words and language work way better than attempting to abstract things with stats and metrics.
> This is faster than daily and gives much better and accurate info.
Maybe for you. Maybe for me. Definitely not for a lot of coworkers I've known. They do not context switch from "this is harder than I thought" to "track down the JIRA task and change my estimates". Getting some of them to even log work done is like pulling teeth. Hence hacks like the daily standup - poll, use words, get the real status.
Having worked for a company that used daily status reports via email, I can say that they are an absolute pain in the ass, but clients were delighted by them when done properly. Those status provide a clear hand written description of what your team did and next steps to take. I can honestly say that those reports did as much as the quality code to show us as a professional team in which the client could trust.
And yes, if you couldn't write your own status for each day, even after training and guidance to do so, you weren't a fit for the company.
It was one of the best companies I've worked for and where I learned the most.
It depends on the local environment. The way I think of it is: if I hire senior talent at $OMG annual salary, maybe more than managers make, I want to know they're DOING something. So daily status makes more sense. Then when a level of trust is established, should go to weekly, if management is at all competent.
The thing is, it's all about visibility. Can management look at your sprint board, either physical or online, jira agile board for example, or in some other tool, where they can see what's going on? That's a good place to start.
This is actually the case and I probably misused the term, mgmt is actually the founders trying to find out if the features are going to be pushed before the next client meeting 90% of the time
1) Take over all the admin stuff you can to free up your devs from distraction and pointless tasks. Productivity and morale will immediately go up. My guys were time reporting into 3 different tools (and this is a <10 person startup!), I just started writing a summary of our standups and told them they didnt have to do it individually any more, it was appreciated and mgmt still get the info they need. 2) Start with infrastructure stuff - how do you deploy, what's your build process, can anyone on the team draw an architecture diagram (mine couldn't) 3) Write tests, it's low risk changes to the codebase so you cant really break anything, but it'll give you the black box overview of how everything hangs together, detail will come in time 4) Accept that there's no way to immediately get to the level of familiarity the guys who built the system will have. I can spend 2 hours digging trying to find how widget x gets its props passed in, or I can ask my teammate who wrote it and immediately known which file and line its on.