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.
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 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.
Everyone's different.
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...
* How important the code path is. It might really be some boring code that you will never touch or don't need to understand anyway.
* How much time you have. This point is really important if you're reviewing some code.
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.
EDITED: Added an item to the list
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.
Ask on your team's IRC channel.
Plus of course improving the infrastructure. This is also mostly in the same poor shape as the docs.
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.
On the other hand, if the team were peers in the org chart, I agree with you.
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.
Seriously, the most useful thing I've ever done is just refactoring half of a project to see how it works.
This is a good way to cut the velocity of whole project so you don't look as lost though.
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.
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.
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.
I'm skeptical that management would need a daily status.
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.
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.
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.
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.
They really have no idea what they're doing.
How are these deadlines getting set?
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.