What's the first thing you do with a new code base?When you join a new dev team or company, where do you start?
When you join a new development team or company, where do you start?
Here are a few things I usually do, to give me a quick at-a-glance sense of where I am. These things don’t require any special onboarding or knowledge-sharing session. You can do these things as soon as you have access to their systems, to begin learning.
I run a static analysis/linter tool against the codebase.
My goal isn’t to fix any problems at this stage, just to get a sense for whether the broken window effect is strong here.
Execute the test suite.
Is there a test suite? How complete is it? Does it work?
Navigate the code manually.
Start in a random spot. Or start at the top of the application and work your way down. Doesn’t really matter. Spend half an hour doing this, and take (mental) notes. Is the code easy to follow? Can you tell what it’s doing? Do you know why it’s doing it?
Look at git history.
Are the commit messages clear and well-written? Are the commits appropriately sized? Does each commit do one thing and one thing only (i.e. not mixing a bug fix with a new feature)?
If the team is using GitHub or similar, also look at their pull request history. How long does a pull request tend to live? How large are the pull requests? What does the approval process look like?
Finally, through all of this, I encourage you to take private notes about your observations, and anything you think should change. I say private, because it’s too early to start complaining about these things. Just because your new team does something that seems odd to you doesn’t mean they don’t have a good reason. So keep notes of any complaints, then see if you can learn the reasons for these complaints naturally. After a couple weeks, if the reason for something is still unclear, feel free to ask. But of course, do it in a non-judgemental way.
My Funny Habit: Code Review for Solo Projects
I have a funny habit. Well, I guess it’s a funny habit. I never thought of it as funny. Then people started pointing it out to me, and asking why I did such a funny thing. A little over a hear ago, this funny habit came up during a job interview: “It’s funny how you make pull requests for your own projects on GitHub.” Yes. That’s right. My funny habit is that, even on solo projects (and yes, even the private ones I never publish), I create pull requests.
Adventures in DevOps 123: Standing Out in the Job Search Process
Strategies you can implement to stand out in a crowded job search process.
Improve your software delivery