31–40 of 186 posts
Earlier quoted context omitted.
1.5) convince mgmt they don't need a daily update any more
1.5 b) convince management that don't need a management anymore in a <10 person startup.
Earlier quoted context omitted.
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.
Some times tests, but sometimes I start writing/improving the docs and tutorials, if they are in a bad shape. Mostly they are. Plus of course improving the infrastructure. This is also mostly in the same poor shape as the docs.
Start by having someone on the team give you a brain dump. Record it. It doesn't need to be high quality. Use Quicktime and your laptop's webcam.
After the braindump, write out everything that was said and make the following diagrams:
- Architectural diagram showing the components involved.
- Infrastructure diagram that shows where things run.
- Deployment pipeline that shows how code gets from git commit to production.
- Data flow diagrams for the most common usage patterns. This one might come a bit later as you're more hands on in coding.
Show the diagrams to your team members as you create them and ask them to verify that it's accurate. If it's not, understand why and fix your diagram.
Add the above to your onboarding docs. If none exist, create it somewhere.
Add a page to onboarding docs that describe how to access logs.
Add a page that describes how monitoring in the system works.
Add a page that will act as an index for recipes on how to do useful things. From that page, create a bunch of useful scripts that you gather as you learn stuff daily. Encourage others to do the same.
I think you get the picture. Add a page for everything you need to know in order to be productive. Think about all the things you knew how to do in your previous position. Try to document how to do all those things in your new position.
Soon, before you know it, you'll be productive and you'll enable your team to be able to onboard new team members more efficiently.
In addition, write code and review PRs. Ask a lot of questions in PRs. Investigate how things work. Get curious.
Tackle the backlog - those bugs that have been just sitting there for months or even years because other things keep getting prioritized above them. They may be minor, low-priority fixes, but when you solve them, what people will think is "Wow! This developer fixed a bug that no one else could in 3 years! That's always annoyed me but now it's finally fixed!". Next thing you know, they'll be giving you the most import…
I'd also add that one of the big things to look at is the documentation and start improving it as a way for you to understand the systems.
If you are the bridge between business and dev, you have to manage business expectations and point what needs to be changed. If you are the technical guidance of the team you have to be on top of code quality and architecture.
In the end, the role name doesn't really mean a thing, it's what is expected of you and your legroom that matters. Both are dynamic. In fact, every team member is free to suggest improvements, how fast they are implemented just depends on who approves them. Senior normally just means you don't need alot of supervision.
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…
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
Earlier quoted context omitted.
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…
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.
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.
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…
Super useful. Thanks. The project is also in burning condition, viz. Tight deadlines, pressure etc.
Earlier quoted context omitted.
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 distracti…