
Ask HN: How do you become productive in a new project as a senior developer? - sidcool
Additionally, the project is on a new tech stack (for me).  I would like to be productive as soon as possible and help the team move faster while adding quality and better engineering practices.<p>Any tips, help, books?  Thanks.
======
Jedi72
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.

~~~
cubano
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.

~~~
mijoharas
What does IC stand for?

~~~
cubano
Independent Contractor

~~~
roninb
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...

------
melvinram
Sounds like your team needs better onboarding documentation. Make creating
those docs your responsibility so that the next person that joins doesn't need
to do what you're going to need to do.

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.

~~~
baby
I'd add one thing: write a threat model as well. What are you protecting
against? What are you not protecting against? What do you do if X leaks?

X can be user hashed passwords, server's certificate keys, etc...

------
jdmichal
I see a lot of advice about individually contributing. I'd recommend another
path: Figure out how to be a force multiplier for your team. Sure, maybe
you're great at spitting out code and tests. But that's still only one
developer of work. If you have 10 people and make them 10% more efficient...
That's _also_ one developer of productivity gains.

Since you're new, you don't necessarily have all the insight to make this
happen on your own. So ask your team! "What can I do that would make
_everyone_ more efficient."

Also, make it clear that you are available for _general_ questions on
technology, architecture, algorithms, secure coding, etc. I spend one to two
hours each day fielding questions like this, and I don't have a lot of in-
depth knowledge of our code. But all code needs architecture and algorithms
and security best practices. And since I don't have to actually spend the time
coding, I'm multiplying my capacity to make decisions. It's also great for
developer ownership, when I get to say things like, "I can give you general
advice, but you know your code the best. So apply it with discresion."

~~~
hluska
> "I can give you general advice, but you know your code the best. So apply it
> with discresion."

This is an excellent quote and I plan to use it, or a close variant. Thanks
very much for sharing!

------
Falkon1313
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 important tasks.

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.

~~~
awjr
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.

~~~
thr0waway1239
Indeed, it is amazing how many 'soft' things surrounding the software can be
improved without requiring to 'get into the zone' as a developer. Of course,
you also need to do the actual work and not get bogged down in these
peripheral tasks.

~~~
throwanem
I'm starting to think that actually writing code is more the "peripheral task"
in the senior developer role - I find I spend most of my time working with
other devs, doing code reviews, dealing with administrative stuff like our
organization's change management process, and handling larger-scale, higher-
level stuff like making our deployment process sane.

It's unusual these days that I just grab a feature or a hotfix and knock it
out - generally only the ones too big and scary for anyone else to handle, and
my guys are good enough that those are pretty rare.

------
marktangotango
Turns out, this happens pretty frequently, getting up to speed on new code
bases is a skill in itself IMO. After you've done it a few times, it does get
easier, but still very annoying.

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.

~~~
laythea
"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..."

I am interested to know what happened to the "old timers" meal ticket?

~~~
marktangotango
He saw the writing on the wall (so to speak) and moved on. The app was
eventually rewritten in Java.

------
falcolas
IMO, there is no magical formula, and being a senior dev doesn't change the
work involved: you're still developing code, you're still working with your
peers, you're still designing stuff. You're just better at it because you've
seen a lot of it before.

That means you'll get productive in same way you'd become productive as a
junior. Pick up easy tickets and use them to learn to navigate the codebase.
Talk to your colleagues and fill in your knowledge gaps. Help others who are
having issues. Pick up and address more tickets. Get in the thick of things as
quickly as possible.

If the position includes additional roles, such as that of a PM, nail down the
necessary role requirements and start doing those as well. You'll need to work
on your soft skills - honey and vinegar, carrot and stick, etc.

You're a senior developer because of your experience and knowledge in general,
not because you're magically a productivity machine. Assumptions are going to
be your biggest hinderance when coming in to your first "senior" position.
Don't assume that you know more than your peers, even the junior ones; when
you first start they probably know more about the codebase and tech stack than
you do. Don't assume that if a team works differently than what you're used
to, it's automatically worse. Don't assume that their code quality and
engineering practices are poor.

Don't assume; find the reality and _work with your team_ from there.

------
perlgeek
"Clean Code" by Robert Martin can certainly help with better engineering
practices. Other books that come to mind are "Continuous Integration" by
Duvall and Matyas, and "Continuous Delivery" by Humble and Farley.

Apart from that, I can only recommend to play with the tech stack in a throw-
away prototype before using it for real, because the first decisions you make
in a project tend to be those that are hardest to change later on.

Approach the task with humility. First observe, participate and learn, then
come up with improved practices.

------
gorpomon
Like a few others here, I just had to onboard to a project as well. I made a
lot of mistakes, but learned a lot.

Mistake 1 - Was too focused on committing code and getting my first PR merged.
I wanted to prove I could commit code quickly, and that PR is missing a lot of
things and had to be patched later.

Mistake 2 - Not asking for (enough) help. I did a short pairing session that
got me up to speed, I should have asked for a few more. I also should have
asked "What's important in this code?" I had to learn that the hard way.

Mistake 3 - Ignoring the full release lifecycle. On day 1 you should first
learn how issue management works, and then how the software is released to
production. Releases caught me by surprise, and I ended up having to put
hotfixes in.

Mistake 4 - I let QA become a second class citizen. Find out who and how your
code will be QA'd, and try and be active in that process.

Mistake 5 - Ignoring important "sub-systems" as they didn't seem to directly
pertain to my work. For instance, I knew we had a feature toggle system, and I
was told I didn't need to use it for my work, but looking back, it would have
been nice to know and use. I also was told to ignore end-to-end tests since my
work was so small. Well guess what held up release because my code broke it?
Yep, end-to-end tests.

Mistake 6 - Modifying code without reading tests and understanding the
underlying data. A lot of people have mentioned this, and it can't be
emphasized enough. A lot of tests have mock data at the top, why ignore that,
it tells you what the code is working with. 'Describe' blocks tell you exactly
what methods are supposed to do and what's important about them.

So, I made a lot of mistakes it seems, but the most important thing I did
right was this:

Whenever I realized a mistake, I fixed it and I moved on. I didn't let it get
me down, and I won't make that mistake again. That's ultimately what a good
dev is, someone who can red/green/refactor their mistakes with minimal
oversight.

------
developer2
The other replies here are misguided. A senior developer's job is not to take
over as a know-it-all dictator at the end of their first week. You don't write
unit tests for existing code, refactor other developers' work, take over the
role of architect or sysadmin, make sweeping changes to existing processes, or
take any other "heroic action". The number of comments here essentially saying
"assert your dominance by introducing the 'right way of doing things'" is
unsettling. Shame on anyone who strolls into a new team with this mentality.

Your job is simple: get to work. You don't invent "important senior work" for
yourself as a way to prove your merit with your ego, before you have settled
in and _earned_ your title. You pick up existing tickets from the queue. The
only way to get acquainted with the project and its stack is to begin working
on real tasks that require minimal modifications to the codebase. That's your
goal: commit and deploy small chunks of code that accomplish something useful
for the business. You need to take the time to organically discover each
subsystem, one at a time, as you complete tasks that actually close tickets. A
senior developer's _initial_ job is to be a "junior developer" who knows
nothing about the project, taking the time to learn the system bit by bit.

Progressively pick up enough knowledge in order to _eventually_ be in a
position to assist other developers and make decisions about the project's
future. After 1-3 months, depending on the size and complexity of the project,
you will have touched a majority of subsystems while working on tasks. You
will then have a comprehensive understanding of the system as a whole, and may
be considered informed enough to take some amount of control over the future
direction of the project.

tldr; Your job as the newest senior developer on a team is not to be
_perceived_ by others as a senior developer. Your job is to _act_ like a
senior developer, and that means taking the time to integrate yourself at a
reasonable pace. The "Senior" prefix to the title does not kick in until
you've worked on the codebase long enough to fully understand it.

~~~
sidcool
Your view is quite different from the others​. But very insightful.

~~~
developer2
Thank you. Other top-level comments are preoccupied with _portraying oneself_
as a senior developer, rather than _behaving as such_. The difference is
substantial.

~~~
sidcool
Spot on. I would like to be the latter.

------
itamarst
A lot of being productive as you gain more experience is by working on the
_right_ things, so you produce more with same amount of effort.

What this means is you want to start with figuring out goals. What is the
project's goal? What are the constraints? Why are things being done the way
they are? What does success mean?

Once you know that you can start doing tactical stuff (and since answering
those questions can take a while you can probably do lots of other stuff in
parallel, as discussed in other comments).

Two relevant practical talks, from PyCon that was this weekend:

1\. I gave a talk on how to choose how and where to test your software
([https://www.youtube.com/watch?v=Vaq_e7qUA-4&t=63s](https://www.youtube.com/watch?v=Vaq_e7qUA-4&t=63s)).

2\. Awesome talk on how to structure documentation - prose version at
[https://www.divio.com/en/blog/documentation/](https://www.divio.com/en/blog/documentation/),
video version at
[https://www.youtube.com/watch?v=azf6yzuJt54](https://www.youtube.com/watch?v=azf6yzuJt54)

------
FindMySocks
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 a senior, you may not know the platform, but you can get to know how the
team works, offer suggestions and identify probable pain points. There might
be entire sections of code you can work out that needs to be written which
don't necessarily require knowledge of the platform.

All this will take time, be incredibly useful for everyone and in your spare
time you can learn about the platform.

~~~
sidcool
Yeah. The team is 11 devs, QA, BA.

------
rb808
I think most of the replies are solely technical. Sure that is important, but
I'd say you need to also spend time with users, customers, management,
marketing etc to find out what they want out of the system. Also HR issues -
can you hire & fire people? Get money for resources? Bring in new tools?

Its often easy to dig into the code as that is familiar but that probably wont
be what you'll be judged on down the track.

------
narag
I'm a little confused by both the question and the current answers. Maybe
because, when I've had that position, there was a project manager that or
similar that dictated what should I do and what was expected from me.

Also being new with a tech stack is enough of a handicap to keep me busy
getting to speed, so adding quality and better engineering practices had to
wait.

Actually, the first time that I found myself in such a situation, I later
regretted I had not invested much more time in learning the framework so I
could had detected bad design that later slowed us.

~~~
sidcool
True. Learning the framework and its idiomatic style is very important.

------
al2o3cr
Start reading the code. Ask "why" a lot - the code can tell you "what" and
"how", but "why" isn't always there and is the most important piece of
information. If the codebase has been around for a while, this may also
surface places where the reasoning no longer aligns with reality; these are
great targets for refactoring.

There's an interesting side-effect of this practice if you've got less-
experienced devs on the team: it can encourage them to _also_ ask more
questions more confidently.

------
chiefalchemist
Your team, especially if their morale is subpar, is your number one asset.
Code and deadlines will come and go, but the team, or the lack there of, is
(in reality) all you have.

If you're not actively engaging them for input, insights, etc. then you could
be short term smart and long term foolish.

Even as a serious dev you're still 75% manager, and, at best, 25% leader. Your
duty is to put your people into a position to succeed. And until you know it
all (sarcasm), they're going to have thoughts and feelings on what that future
looks like.

------
mping
Depends on what is expected of you, as well as your margin for manoeuvre. Some
seniors are supposed to do one feature and then guide the juniors to replicate
that feature, others will have more responsibility, etc.

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.

------
JustSomeNobody
Starting with a new (ish?) machine, write down everything you need to do to
get your development environment set up and building the code.

Now, take a step back. How easy was this? It should ... must... be absolutely
frustration free. If not, fix that.

To come up to speed on the tech stack, go sit with the other developers. Get a
feel for how they are using the technology. Then, start picking off some
smaller issues from the backlog and try and fix those.

Don't make assumptions. Learn the tech without an opinion. Sure, you won't
like some of it (nobody likes everything), but find out if the team likes it.
If they do, don't try to change that.

------
LoSboccacc
Start fixing long standing bugs nobody wants to address because too complex

~~~
afarrell
Note to junior engineers reading this: If you don't already know the codebase,
this can be a terrible way to get to know it because you get sucked down
rabbit holes and end up having spent 2 weeks with not much to show for it.

You need to exercise skill of being able to do an organised exploration of the
codebase, probably producing documentation along the way.

------
agentultra
I always start with the test suite.

If I'm unfamiliar with the code base I start by trying to break things. When I
do this I'm looking for missing assertions, invariants, or incorrect
assertions. I create tests for those. I fix them. If the project I'm working
on is smart enough to use property-based testing I look for weak invariants,
serializability, or missing assertions. The end goal is to understand the
module by exercising it and adding value at the same time.

If the code base isn't using property-based testing or has no tests at all I
will find a way to add them. It gets the ball rolling for adding some issues
to the tracker and provides real value.

Keep a journal of your experiences coming up to speed. Once you've grasped a
certain corner of the code base review your notes and build some documentation
for that code. It will help on-board new developers the next time they come to
that code base.

As for introducing best practices, as a senior developer, you'll have to build
consensus with the rest of the team. In my team the difference between a
senior developer and a team lead is the ability to communicate ideas and build
consensus around them. Learning how to influence people is the hardest part
about building your skill as a senior developer. Senior developers become
leaders when they can communicate a proposal and immediately build in feedback
from the team and turn that into a real change to the code base, product, and
business.

------
ljw1001
This is a symptom of a problem you might help to address. companies spend a
fortune on recruitment and next to nothing on on-boarding. The problem is
multiplied when there is a lot of technical debt or weak infrastructure,
because they make onboarding harder.

Often, the people who grow up with a mess don't see the issue because they
learn it a little at a time as it's being created, but bring a new person in
and require that they understand it all to be successful and you have a real
problem.

------
joelbirchler
My approach is to learn the stack (read books, sketch/prototype).

Get the team to whiteboard the architecture with you. This is better than
existing documentation because you will get the full commentary and start
building a mental model of the software.

Ask the team about problem areas.

Don't push on major stack/architecture changes until you know the
stack/architecture.

Make sure the base engineering practices are there. You should have a seamless
workflow from pre-merge code reviews, testing, and deploy.

------
Communitivity
A step debugger has been suggested below by cubano. In my experience using a
debugger as a broad lens to learn a codebase takes too much of my time. I can
take a module to walk through the code in my head, paying special attention to
conditional branches. Any place where I can, I ask 'What if..?', e.g. 'What if
the value is null?', 'What if the network is down?', 'What if the program is
being run for the first time?', 'What if an exception gets thrown here?'. For
each of those what ifs, if the particular corner case is not handled then
write a unit test to see what happens.

That brings me to another thing a senior dev can do, refactor code to be more
testable, one small piece at a time.

Thing is though, your job as a senior dev is to make sure the code, and the
coders, work smoothly together. A good chunk of your work will be mentoring
the junior developers, fostering tech exchanges, leading design discussions,
etc., and if done right the value in this far outweighs any individual code
contribution you can make. In my opinion a true 10x developer is not
necessarily one that produces 10x as much code, but one who maybe produces 2x
as much, but enables the team around him to produce 5x as much.

------
Illniyar
I'd just pick a bug/feature that seems short and relatively contained and
isn't urgent, probably from the backlog.

Inform management, and make sure it'll be deployed when you fix it - you want
to learn the entire process of development and not just the code.

Start learning the architecture, stack and development process with the goal
of fixing that single bug. You don't have to learn the entire
stack/architecture to fix that single bug. Try not to refactor the entire
system while your fixing a bug - the point is to learn how the system works,
not to redesign it.

Make notes of the pain points you have - from setting up a dev environment, to
lack of documentation or even communication problems.

When you finish, do another bug, perhaps something more challenging.

If you feel that you need to read a book, or do a tutorial on part of the
stack you don't know to fix the bug, then do so.

When your done with a few bugs, you are in a position to know and prioritize
what quality and changes could be helpful, try and implement them.

------
vii
I've had several (previously) senior developers join projects I've led or
worked on. It's really hard to get them up to speed and contributing
effectively - some never succeed :(

Firstly, accept you're not going to be productive immediately as you don't
have the project and business context. This is fine. Resist the urge to
redesign everything, bring in new technologies and practices until you
understand what is going on. Your instant reactions and conclusions will not
be attuned to the needs of the project - so practice humility. Socially you
may be used to knowing more than anybody else about the system you work on.
Don't forget how much hard work this was to achieve the first time and get
ready to do that again - but better :)

Secondly, understanding you won't be contributing at a senior level to the
project immediately, focus on learning the stack. One senior developer we had
whose task was to do an integration of an open source program, got bogged down
for months due to disliking the scripting language most of the backend was in.
To learn a stack, make your own throwaway end-to-end projects. If you don't
understand the stack, you won't contribute at a senior level.

Thirdly, make sure to regularly commit code to the project. Of course, you
have to talk to surrounding teams, customers, etc., and learn to cut releases,
and so on, but most important is regularly contributing so as to get a feeling
for who on the teams understands the system and what the real development
process is like. Easy ways to make quick code changes beyond bugfixes: improve
logging and metrics (also great for getting an overview of how things work).
To support your suggestions for new practices and stacks: gather and document
data about the real issues (regular causes of incidents, etc.) and build
relationships. In time, the value of an experience transfer is huge - but the
value of scattershot rewrites without context is hugely negative. Good luck!

------
rdsubhas
Pair program with a few people half a day for a week or two, and you'll become
productive both with codebase and with your team mates (as long as you didn't
capture their keyboards). Spend rest of the day on everything else mentioned
in @Jedi72's comments and get the larger context.

~~~
maio
Agreed that pair programming is great to get productive ASAP. That's what I
did in my current job. Instead of working on some minor things alone I asked
my team-mate to pair with me on a task which was most important/valuable at
the time. We spent few weeks working together on various things, and they were
quite surprised that I was able to get up to speed so quickly.

If you are fan of pair-programming this may be really good opportunity to
introduce this technique to your new team. Since then, we use it whenever we
feel it will help.

------
phd514
I'm similarly one month into a new senior development role. Although I am
familiar with the tech stack, the system's functionality, deployment
environment, and points of interface with other systems are fairly complex.
The other devs on the team will answer specific questions but are pretty
stingy with their time when it comes to something like an overview of the
system. I could (and have) read through a fair amount of the code, but IMO,
that is very inefficient and potentially misleading way (you might be able to
see what is happening but not necessarily why, something that is important for
senior devs to understand) to come up to speed on it. Oddly enough, the
organization has a very structured onboarding process for everything except
coming up to speed on the specific details of their product's functionality.
Frankly, learning everything about their expense reimbursement policy and the
health insurance website by day two is nice, but not nearly as useful as
coming up to speed on how their product works. I'm finding it pretty
frustrating.

Both here and in previous roles, I start with the data model and work my way
backwards. If you don't understand the data, it's nearly impossible to
understand what the system does. In previous roles, I'd also browse through
the production environment (e.g., AWS) and look at the monitoring pages for
the different components (databases, EC2/ECS instances, queues, etc.) in order
to get both a sense of the topology of the production environment and where
bottlenecks might exist. In previous roles, I've been able to make some
significant improvements early on as a result of that. In my current role,
utilization is <5% on almost everything, so that hasn't been helpful.

Earlier in my career, I had a team lead who hired me into a role on a complex
system and he scheduled one hour per day with me for a full month to walk
through various aspects of the system. Obviously that was a pretty significant
time commitment, but I think it paid off for him in that I came up to speed
pretty quickly and was quite productive. That always stuck with me and when I
became a team lead, I always budgeted a significant amount of my time to bring
new members of my team up to speed. I'm pretty frustrated in my current
situation as an unproductive senior developer due to unfamiliarity with the
functionality of the system and confused as to how its beneficial to the
company to operate this way since I am rather well-compensated. I think it's
quite penny-wise and pound-foolish for organizations to hire developers and
invest as little time as possible in bringing them up to speed.

~~~
davnicwil
> I'm pretty frustrated ... and confused as to how its beneficial to the
> company to operate this way

It's very likely not a considered strategy; rather the total opposite.
Technical managers and by extension teams are, generally, really bad at
onboarding.

It's nobody's fault per-se, just an unfortunate artefact of giving people
responsibility for something they never trained for, usually without any
formal plan, and expecting them to just figure it out on instinct.

Of course, most don't. Some do though, really well, and if you find one you've
found a gem! It's unfortunately not the norm. Don't frustrate yourself
thinking that it is.

------
suls
As always, it depends on the context.

Do you know why you were hired? You mentioned "10 devs, QA, BA" .. maybe a
good chance to talk to everyone and write down and later agree on a roles &
responsibilities matrix. Same goes with process. Talk to everyone and find out
what they actually do, write it down and then have an objective discussion if
all this is still the best way of doing things / working together.

As for the coding side of things: using cloc [1] and cpd [2] proved to be
super helpful every single time for me. When talking to current devs you are
likely to get a glimpse if what they worked on recently or will work on in the
next few weeks. Cloc gives you the whole story from the beginning. Maybe it's
a new stack -- but how come there are 1000s of lines of perl code in the repo?
Always a joy to dig deeper and learn about the history. Cpd is a great helper
to gauge what your devs actually do vs. what the say. In the heat of deadlines
it is often the case that stuff just gets copy and pasted rather than
refactored -- which will turn into a nightmare sooner or later. Bonus points
for lots of copy/pasting in your test suites and automating cloc & cpd runs ..

Also, if everyone is busy adding code/features, be the one who removes stuff
that isn't needed anymore.

On the learning side: you said you are not familiar with the stack. Are you
sure your team is? This is a great opportunity to start a learning/ book
reading activity for your team.

Last but not least, always assume best intentions. A lot of things probably do
not make sense anymore but they did in the past -- find out about the history
and you'll earn the trust required to make an impact in the future.

[1] [http://cloc.sourceforge.net](http://cloc.sourceforge.net) and
[https://github.com/AlDanial/cloc](https://github.com/AlDanial/cloc) [2]
[http://pmd.sourceforge.net/pmd-4.3.0/cpd.html](http://pmd.sourceforge.net/pmd-4.3.0/cpd.html)

~~~
sidcool
I have been a part of this org since 2 years as a Senior Dev, but worked with
other Senior Devs on project, never been the only Sr dev.

I have started having conversations with people on their experience,
expectations etc. I am new to the stack but aware of what it is. The team is
ramping up and certainly know more about it than me.

The links are very helpful, thanks.

------
mattmanser
Me go-to for learning a new code base is fix bugs, fix performance problems.

The bugs give me an overview of the system and let me develop my mental map of
the code base, the performance problems give me an overview of what's been
done wrong.

------
welpwelp
Get into the project by working right away on implementing a new feature or
fixing an existing bug. Then spend additional time from your spare time
learning the new stack. Bam, productive by end of week 1, 2 at the latest.

------
xrd
When you say "be productive," whose judgement will be making that assessment?

I ask because if you were hired to come in and right the ship, writing tests
might not be perceived by your manager as the right thing to do. If you need
to impress the other developers, that might or might not be the right choice.

If you are trying to communicate progress upward, then I would make an honest
assessment of the challenges and write down a plan for your manager.

If you are trying to impress downward, then that's probably a cultural
challenge and you can figure out what to do from the comments here.

It really depends who cares about your progress.

~~~
sidcool
The judgement will be of the team. I need to comfort other developers in team
that I can handle tough conditions, the project is in a bad condition and
developers are overworked and groggy. I want to help them as much as possible
and not be a boss, but a servant leader.

------
LanceH
Allowed freedom of choice, I'll start as follows.

1\. Build on my machine

2\. Reproduce issues

3\. Fix bugs -- even typos or refactors

4\. See the fix code review/merging/deployment to qa/dev/whatever

When I start a new project I'm most concerned with reproducibility of the
process of development. A lot of time other people are blind to the little
tweaks that have occurred over the years that enable them to build, test, and
deploy a system.

Those tweaks often give a lot of insight into what is going on. The ability to
push-button deploy is also a bellwether of what is to come.

------
threeseed
Fix bugs.

It will help you to learn the system and technology better than any
documentation will. Also it keeps you of the way of the other developers who
frankly have better things to do than babysit you (just being honest) but also
gives you regular opportunities to chat with everyone as you work through
different issues.

Either that or improve monitoring/supportability. Gives you an opportunity to
build relationships and earn brownie points with your DevOps/SysAdmins.

------
baby
A lot of advice here are the same you could find in CONTRIBUTING.md files of
open source projects on Github :)

* read the docs

* document what is not documented

* write tests

* look at small issues/todos and write code for them

------
zghst
First thing is first, you are learning a new stack, you probably have
coworkers that know it better than you, so you have a golden opportunity to
kill two birds (gain favor w coworkers & learn fast) with one stone!

Do not bother your coworkers with endless questions or interruptions, but try
to use __scheduled times __to discuss how you 're going to build things. In an
ideal company, you shouldn't be building things in a bubble, there should be
multiple team members ensuring quality instead of one or two brains. (Also
ideally coworkers should be trying to learn how you think so they can best
tailor tasks to you)

The hardest part is continual, backbreaking improvement. It becomes easier as
you keep doing it. I recommend getting a twitter and following everyone vocal
in the area of the tech stack you're working on AND people who work on the
same problems as your company (double reinforcement of shared knowledge in
your industry). That way you're aware of the current problems that may arise
(instead of being left in the dark), trending new ways to do things,
counterpoints of why you should avoid some new trends, etc. Scour the internet
for resources, such as HN of course, but also popular see sites, subreddits
related to the stack, IRC channels, and follow the Github projects of the tech
stack if possible (lots of discussion and examples are there!).

I like books. I spend thousands of dollars on books a year, but books on a
tech stack rather than development practice will become quickly outdated, and
can learn just as much online as you can in a book on a tech stack. I will
only buy a tech stack / programming language book is if the language is hard
core or if it is new & emerging with a smaller community.

I'd also recommend taking extra time to analyze and plan before diving in.
Just sitting for maybe an extra 3 minutes allowing your mind to clear so you
can put things together in the right way. Your goal is to become opinionated
and knowledgeable faster, so taking the time to get it right early on is
permissible.

Finally I recommend something that others won't tell you. It's to become a
super fan of the stack (how) and company's mission (why). Your newly found
enthusiasm would be a superb speed boost to your goals and add increased
visibility to your efforts.

You will not instantly become productive or enlightened, but the fact that
you're seeking to be better (yay enthusiasm) does increase the likeliness that
you will succeed.

~~~
sidcool
Very interesting insights, thanks.

------
jakeblues
Refactor code as you read it. If you see a method that doesn't make sense to
you, change it. Even if you don't merge your changes, the exercise of trying
to solve the same problem the original engineers were trying to solve is, in
my opinion, the fastest and most effective way to get up to speed with a
codebase.

~~~
falcolas
Err, I would advise to absolutely don't do this as a new employee. Ever.

If you see a method which doesn't make sense to you, ask about it. Why is it
running the way it is? What corner case prompted it? Is there testing which
covers it?

Only once you're sure that the code really is problematic should you refactor
it. Otherwise, you're begging for regressions, new bugs, and conflicts with
people who wrote the code in the first place.

Understand the impact of codebase you're looking at before you try and change
it.

------
abhikandoi2000
I did this:

\- got a broad overview of the code from my team

\- agreed to be the on-call just after two weeks of time; learned a lot
because I had to move fast to fix issues (also call people)

\- asked the starting point and the core part of the entire codebase (helped
me understand code at least 3x faster)

\- deployed a feature within 2 weeks of joining

Note: I am not a senior developer, but a software engineer.

------
DaSilentStorm
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.

~~~
marktangotango
I don't favor this because then you get someones outdated view of the product,
if at all. In an ideal world, yeah, you should get onboarding, and some walk
throughs from the current developers. In reality this rarely happens in my
experience. The code deployed to production is the ultimate source of the
truth.

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.

------
vurso
Find out what all the blockers are. What is stopping all the dev's from being
productive consistently.

Find out what are the black holes (the problems that will pull you in and not
let go).

Introduce one improvement to the exsiting processes (automation, documentation
e.g. wiki, lunch & learn/brown bag/dev days etc)

------
davidjnelson
A few high level things are to choose projects that have the highest impact,
and to find out or establish what the key business metrics are and work on
monitoring them better and improving them.

------
khaki54
Write all the unit tests the team has been slacking on. By the time you are
done, you will understand all of the code and have full test coverage

------
emodendroket
Don't think it's really different from how you'd accomplish the same as a
junior developer.

------
jkingsbery
I've onboarded as a senior developer onto a new project few different times:
twice at a startup, once at a largish company, once at a very large company,
and once at a coming-out-of-startup phase company (that time as a hybrid dev-
manager). A few pointers:

1\. First thing is to come up with a ramp-up plan. Before you touch any code,
before you fix bugs, make sure you have a 30- and 90- day plan for where you
need to be and what you need to know. That plan should include with coming up
with questions for people and meeting with them to ask them, understanding the
company's strategy at a sufficient level, and, yes, understanding the code
base and development procedures.

2\. As a Senior Developer, it's good to know where the project is now, but
people are looking to you to know where the project will be in 6-9 months. So,
while fixing bugs is good, don't get bogged down in that - after some initial
familiarization, take up tasks that let you focus on big picture architectural
and process issues.

3\. Take time to get to know your colleagues. Have lunch with them. Have non-
work conversations. Start to learn what interests them. Without explicitly
asking, pay attention to clues about career goals and what they find
challenging. As a senior developer, demonstrating that you are genuinely
interested in your colleagues goes a long way towards earning trust and
getting embedded into the team faster.

3a. Get a sense of the team's culture. Are there cultural norms you're not
used to? Are these norms good/bad/indifferent?

4\. Given that you are a Senior Developer, you should make sure your team is
hitting a lot of basics. Are there feedback loops, both business-wise and
process-wise to your team? If not, you should work on getting these in place
(or at least making sure that it happens). Business feedback loops should
include some kind of KPI report, adoption report, etc. Process feedback loops
usually include regular, honest and constructive retrospectives. Usually if
you're hired as a senior developer on a team, most of your teammates will have
limited experience in these.

5\. Whenever possible, share your perspective. One of the big differences
between a senior developer and non-senior developers is that you've seen a few
projects, and you've probably seen pitfalls along the way. That's probably a
big reason why you were hired. A great way to add value to a team when you
still don't know the nitty-gritty is being able to say "It sounds like we're
doing X. I was on a team once that did X, and A, B and C happened." Of course,
always do it from a point of view of humility - there might be new constraints
that you didn't know about.

Beyond that, a lot of it will depend. If you're joining a large company, you
should spend some time doing "company networking," i.e. , meeting other senior
developers, project managers your team works with, understanding not just your
project but other projects near you in the org. If you're joining a start-up,
chances are there is a deadline in a few months, so the emphasis will be much
more on delivering something immediately. Writing documentation can sometimes
be helpful, but if you're at a startup that now has hired its full allotment
of engineers, writing a ton of documentation about how to get up to speed is
of limited use. Fixing bugs can sometimes be a good approach, but sometimes
for teams that didn't have a senior developer before, the proper fix involves
a design change. Is there someone else who is also interested in raising the
bar for engineering practices, but doesn't know where to begin? Work with that
person, since you have the experience as a senior developer, and that person
understands the specifics of the team.

------
AngeloAnolin
Have the mentality and an unparalleled drive to execute and continuously ship
and deliver tangible business value.

------
xenonite
Bv

------
noway421
I think it is a little bit of exaggeration to claim Senior Developer title on
a project with unfamiliar tech stack.

~~~
sverhagen
Every place has its own names for things, but I often see "senior" refer to
your interchangeable seniority in the field, not just in the one company/code
base. Then for people to grow into "lead" or "principal".

~~~
johan_larson
Senior Developer is typically either a junior or intermediate title.

In some places, the title progression for technical professionals is (dev,
senior dev, staff dev, principal dev, arch, senior arch), meaning Senior is
actually a junior title.

In other places, the title progression is (dev I, dev II, senior dev, staff
dev, senior staff dev, principal), meaning Senior is an intermediate title.

There is of course some variability across companies, but it's safe to say
that "Senior Developer" is never an actually senior position. People holding
it are never in charge of big things.

~~~
falcolas
It's worth noting that most non-enterprise companies (i.e. not Microsoft, IBM,
or Oracle) don't implement staff or principal prefixes, making senior the top
of the list. I haven't had a principal prefix since I worked for Oracle (and
got there via an acquisition where I was a senior), yet I'm always at or near
the top of the development ladder for my department.

As always, you need to ask questions, not make assumptions.

