21–30 of 186 posts
Do you have Team you're overseeing or working with? I'd take the time to ask each member of the team, what they are working on, what problems they are having, and how you can assist them in some way. The product your company/team is building will have a roadmap of features to be delivered, spend time with members of the Dev team talking through each of those features, what is required, how they plan to build them. As…
Earlier quoted context omitted.
>> 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.
1.5) convince mgmt they don't need a daily update any more
I think it is a little bit of exaggeration to claim Senior Developer title on a project with unfamiliar tech stack.
much of the knowledge in one stack translates to another. you can know RDBMS, and pick up, say, spanner. you can know IIS, and pick up node. I never cared about what stack someone uses.
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…
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.
Plus of course improving the infrastructure. This is also mostly in the same poor shape as the docs.
Earlier quoted context omitted.
>> 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…
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.
I try to go in with an open mind and assume the developers who went before were at least competent and had good reasons to do things the way they did. Sometimes this charity is unfounded, and the code truly sucks, but usually some poor decisions can make sense when you have more context.
Ultimately, I just dive in and start fixing bugs or implementing features. I'll start with the build to understand what the project actually consists of, then I rely heavily on shell tools like grep and find to explore the code.
I once inherited a fairly large c++ application that could only be built on THE dev box, or a copy of it. Only one old timer understood it, it was his meal ticket, and he wasn't talking. It used auto tools so I converted it to cmake so I could build locally. Then I spent about two weeks just reading the code, started at main() and wrote everything down in an architecture doc on the wiki (file and method level, only document method internals that were really hairy). Then as enhancements or bugs came up I'd flesh out the doc some more.
Another time I inherited an old IE6-7 app that had to be modernized. Besides the MS specific stuff, it was a mess of javascript spaghetti. Again here, I had to figure what files where actually used by the app, so I grepped log files and browser network logs to figure what was actually loaded, and just read the code. The first major project I did was to remove many hundreds of unused files.
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.
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.
Along the way, you'll of course need to talk to people to understand both the code that has the bugs and what is expected of it, and you'll learn years of history from both the development side and the product side, which is invaluable.
Well, first of all, talk to the team. To every single person involved. Be it the CTO or the intern. Have someone who has been on the team for some time onboard you and find out what the current obstacles are. Then just grab one task and start working. You'll find the place you're needed most automatically.
I recently witnessed an instance when a senior develoer heavily relied on others for information as you suggest. The team was failing to deliver the manager was incompetent. This senior developer I hired on with was made a scapegoat and blamed for slowing down the team and causing missed deadlines. This was absurd of course, but she got away with it, and he was fired.
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…