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.
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.
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.
I've tried a similar approach in the past and it just does not work for me. Besides the fact that it is very tedious, I don't retain any of the knowledge because it's like reading a dictionary. It's impossible to absorb that much information, for me at least.
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 recently joined a company as a senior developer with a partially unfamiliar stack, and it's very interesting to me how much my style of learning contrasts with others in that way.
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.
One of the things I see in your comment that marks you as more senior is you didn't say "push it out" on the fix but "see how / why it didn't work, trying again". Just because you wrote code doesn't mean it needs to go out, just because a systems isn't to your brain's pattern doesn't mean it needs to be gutted and aligned with your brain immediately upon encounter.
I just wanted to mirror this because often the entry points to various parts of the application is what defines seniority with the particular codebase. The challenges for building how the thing starts and stops as well as the build is something that everyone is currently relying on to do the good work they are doing now. A lot of hard won stability/system issues are solved in that kind of area which dramatically affects what is in the possible vs. something from a wildly different tangent then what's already there.
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...
I love this suggestion - using a debugger to walk through as much of a new codebase as possible. Definitely going to try this it next time I need to familiarize myself with a new large codebase.
Great tips, but I would add that those 2 hours spent exploring the code can actually be useful. I often need to read the code a few times before the big picture starts to come into view, so unless I need an immediate answer, I usually prefer to dig for it myself.
I think digging into the code for 2 hours solo is very important. If you still can't find it, ask a senior dev. Actually being familiar with the code is important to be able to nail down how things work abstractly to the actual implementation. Code is the ultimate source of truth. You are going to reach a point where you come to code written by an engineer who has left and nobody else understands. You will also need to dig into an open source project at some point without any help.
I found it easier to get a new project if you focused on support tickets as a new hire. It is quite something to be able to be productive and see some dark corners of the stack earlier on.
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.
Start by adding a whole-system black box end-to-end test, if there aren't already any good ones. Ideally fully automated and automatically run for every commit via CI, but don't let the perfect be the enemy of the good, take what you can get for starters.
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.
I've had the same experience. I'm sure it's somewhat context dependent, but if the code amounts to business rules and they are not documented, which is very common, you can only reverse engineer what the system _does_ and then write tests for that.
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.
Yeah, whenever new hires complain about the lack of
completeness or correctness of documentation, I'm like: that's a great place for you to start. It also seems to be a great signal of the attitude of the new hire, because the people who kind of groan at that task usually end up having problems.. but that's another topic altogether.
As a (junior) new hire in a group without very complete or correct documentation, I'm not sure I can agree with that. It can be nigh on impossible to try to improve documentation for complex systems without a very deep understanding of the stack. I could spend hours writing documentation but it's not useful when I don't know what is and isn't an intended behavior. I think a fresh face is a great asset to have for writing docs but they need someone with a very good understanding of the system to work with them. Some of the most frustrating times I've had had a junior dev have been documentation tasks for things I did not know very well, spending time poking the system to gain understanding and more time writing clear docs, only to hear that my docs are 'not how it works' and I had either setup and configuration wrong or need to file bugs so it works how it's 'supposed to', even though that is the exact documentation it's lacking. Maybe this is different for projects with less technical debt, where if the current behavior was documented that documentation would be useful. I think this habit of giving documentation tasks to the least knowledgeable people on a project, even though it's reviewed by those with more knowledge, makes the docs suffer.
This is a bad idea. Definitely well intentioned, but has a lot of bad side effects. Especially at big companies, I was instead actively encouraged to dive right in, make very small changes to existing production code & submit it for a code review. That gets you started in the right direction asap, because the feedback is direct - its pertinent to your code that you wrote, so you feel it viscerally & begin understanding the code even though 10 minutes back it was an opaque mudball.
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.
I think the parent was the lead taking the onus off his direct reports. In such a case, improving your team morale and productivity is more important than closing out a couple of 1 point stories.
On the other hand, if the team were peers in the org chart, I agree with you.
As a senior dev my role is to stay away from doing those tasks as much as possible. Well functioning organizations do not keep senior devs to do the stuff that junior devs can.
My first task at a new team is to have a 1:1 with my manager to set our relationship properly and this includes laying out all expectations.
Typically managers understand that it takes some time to get productive. Do not waste that time by doing tasks that do not increase your productivity. You should be learning the codebase, the development process, etc.
Fixing bugs is one way to do it, but not necessarily the best. You may easily spend a lot of time on this, not gain much insight and actually not make a good impression as your colleague with much more experience will do it in 1/10th of the time.
Also, starting on the right foot with the team is also important for your future productivity so it may be necessary to do some of those tasks anyway, but always remember that at the beginning your job is to build a good base for your future work.
I'd agree with this but I also do 1:1s with the rest of the engineers on at least a monthly basis. They use it as a sounding board, career advice, or general design meetings. The don't often happen but it gets them in the practice of talking to you over issues and other things. It also gets you a lot of insight into their thought processes and general issues of the team. I find this works better than just reviewing every single commit and commenting on them, it lets you get into the meta more. And it gets you there before the code is written so it removes the "but it's real close can't I just push" drive most devs have.
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
Burp scan, zap scan are two products for penetration testing / vulnerability scans. They mount organized attacks on your web site. They look for stuff like sql injection and xsrf, and all that.
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.
The existing devs will hate you. They already knew how it worked - now they may not even you've finished - and unlike normal refactoring you never knew how it was supposed to work.
This is a good way to cut the velocity of whole project so you don't look as lost though.
I don't think the point is to move the refactor into production. The refactor is a learning exercise. But if you start on the least understood, ugliest parts of the code the devs might welcome a refactor of those bits.
Note, I did not say "commit to Production". Just set up the feature branch and tear it apart. Most code out there has 0 comments and uses conventions from when it was written (god help you if it's a legacy product)
In that case this is a good idea... I apologize for my skeptism. I've experienced the someone doing this and then committing to production though - I left that team as soon as possible...
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.
regarding 1), isn't there a danger that you can end up being seen as an admin monkey by the rest of the team leading to them undervaluing your technical knowledge?
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.
The trick is that then he is the throughput of his team into all the systems. So he can see if someone is having trouble with a bit of the code i.e. they haven't finished a part of the project. The Senior Dev can then pair code etc to help out. This will assuage the admin monkey syndrome when an answer comes up.
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.
Also talk to your QA and make sure they understand the level of throughput possible for your team. QA can unintentionally kill a struggling project by overloading the tracker with bug reports.
"burning condition" should not be a persistent state. Job #1 should be getting it back to a healthy state, where people feel comfortable working normal hours.
>> 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 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.
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 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.
Having worked for a company that used daily status reports via email, I can say that they are an absolute pain in the ass, but clients were delighted by them when done properly. Those status provide a clear hand written description of what your team did and next steps to take. I can honestly say that those reports did as much as the quality code to show us as a professional team in which the client could trust.
And yes, if you couldn't write your own status for each day, even after training and guidance to do so, you weren't a fit for the company.
It was one of the best companies I've worked for and where I learned the most.
It depends on the local environment. The way I think of it is: if I hire senior talent at $OMG annual salary, maybe more than managers make, I want to know they're DOING something. So daily status makes more sense. Then when a level of trust is established, should go to weekly, if management is at all competent.
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.
This is actually the case and I probably misused the term, mgmt is actually the founders trying to find out if the features are going to be pushed before the next client meeting 90% of the time
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.
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."
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.
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.
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.
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.
"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?
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.
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.
Thank you. Other top-level comments are preoccupied with portraying oneself as a senior developer, rather than behaving as such. The difference is substantial.
"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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
This kind of attitude is really unhelpful. Of course this sort of situation is undesirable, demonstrably, but it's not necessarily a case of idiocy - it's actually very easy for non-technical founders to get into this situation: let's say the developers want to use JIRA, but the non-technical staff find JIRA impossible to use (totally reasonable), so they want to carry on using Trello; straight away you've got tasks spread across two disparate platforms. Then let's say that a manager has an embedded belief from a past (probably non-startup) life that time-tracking by the hour is incredibly important, and they have a preferred tool for this (because, while JIRA has this functionality, it's pretty horrible, and Trello doesn't do it at all), and boom, you've got two different tools for tracking work and a third tool for tracking time.
Sorry, an hour a day doing busywork (like entering hours) in a startup is utterly indefensible. I've done a bunch of startups and not only did this never happen, it would not have been tolerated. Even at <<<several large software companies>> I never spent more than about ten minutes a day doing tracking; during heavy bug crunches, maybe an hour doing detailed writeups within bugs for other groups, for communication purposes. In a small team in a company with a short fuse, you can't afford this.
Either you have people who can do the work and coordinate, or all the tracking in the world is not going to help.
(Time tracking by the hour . . . I can't even . . . it's time to get a new manager by firing the current one or finding a better job elsewhere. Totally serious).
The indignation seems misplaced. Time tracking seems pretty common in the industry, whether it be mandatory or voluntary. Several places I worked had detailed time tracking, and it was pretty informative/helpful as a tool to manage your own task prioritization. It can be pretty eye-opening to sit down at the end of the week and actually take stock of how much time you spent coding, thinking, in meetings, getting coffee, screwing around, etc.
How is that a difficult idea to get around? As a contractor I'm expected to keep track of my hours and what I'm working on. Lucky it's just a chrome extension that I click to start and click to stop. Boom, tracking by hour of what I work on.
It's not a difficult idea. Mindfulness of how you are spending your time is quite useful.
What results from it is, however, difficult. Nearly without fail I have seen these tracking systems degenerate into blaming, micro-management and tools for destruction ("Figby is working two hours a day more than you are, what's up?")
So no, not difficult at all. Easy to do. Much, much harder unless you want a culture of fear and overwork in your company, and screw that, I've been there.
While crude, I do think raverbashing has a point here. If a 10 person startup already requires their devs to use 3 different reporting tools that startup has a problem. If you can't streamline at a small size like this you won't stay nimble and you won't make it.
>time-tracking by the hour is incredibly important
As someone who does the R&D tax credit for a lot of tech companies, let me tell you that it really, really is. It's worth somewhere around 10% of all your developers' salaries if the company is profitable. As in, if they work 10 hour days, entering data into a time tracking system is a net benefit even if it takes up to an hour a day.
I'm wondering how widespread claiming "R&D tax credits" actually is.
To think that most companies could/would seems preposterous (how many are truly doing something worth of the monicker R&D?)
I'm seeing an ecommerce business applying for R&D credit, and that seems absurd, since
> Your company can only claim for R&D tax relief if an R&D project seeks to achieve an advance in overall knowledge or capability in a field of science or technology through the resolution of scientific or technological uncertainty - and not simply an advance in its own state of knowledge or capability.
Well I'm in the US, so I can't speak to the UK's regs with much expertise, except insofar as I know most of the world's R&D credits are based on ours. But in the US, most web dev qualifies, including fairly run of the mill ecommerce site.
Just judging from what you quote here thought, the US rule is less rigorous. Taxpayers must resolve technological uncertainty just as in the UK, but it's a taxpayer centric test. Meaning, that uncertainty can be "simply an advance in its own state of knowledge or capability."
Honestly, I shouldn't say this because it's very much against my own interests, but the US regs are way too loose and permit credits for work that just does not seem to me to be worth subsidizing. But for a normal development company, it's worth tracking hours to gain that subsidy because the IRS primarily challenges us on the validity of the underlying data at this point rather than the qualification of the activities themselves, because a large amount of litigation has settled most of the questions in that area in favor of taxpayers.
Couldn't do it personally (I doubt I could be productive for that long in a row), but presumably it works for someone. The research on work hours I've seen is mostly about week-work length, but I imagine there's some research on workday-length as well.
I see in one of your sub-replies further down that you are in the US, but even hearing you mention "R&D tax credit" makes my blood boil. At least in Canada, the "Scientific Research and Experimental Development Tax Incentive Program" (aka SR&ED) is a complete scam.
Every development shop in Canada claims credits to recoup a significant portion of employees' salaries. Yet not a single one of my companies has ever performed R&D. The analyst comes in and spends a week getting every employee to lie about their work, enticing them to rephrase how their mundane copy-paste-from-Stackoverflow work somehow qualifies as "R&D". The majority of taxpayers' dollars paid to corporations through the SR&ED tax program is fraudulent.
Yeah, I felt that way too when I started this work. What I've come to realize is that the tax credit is not about conducting science in the strict, academic sense of the word, a la Karl Popper and the received view. The systematic evaluation of hypotheses just doesn't happen that often outside the academy.
Instead, the tax credit is really a political compromise crafted to appeal to both sides of the political spectrum. It's about subsidizing high paying, professional, white collar, technical jobs so that employers don't outsource them. That makes the credit an anti-free market subsidy designed to protect jobs but disguised as a pro-science, pro-innovation policy whose main beneficiaries are large corporations.
And honestly, even in the most "sciencey" firms, most of the R&D going on is dreadfully repetitive and unimpressive. Just as you cut and paste SO code, pharma researchers are just "cutting and pasting" the nth iteration of a chemical formula. They're not unlocking the secrets of the universe, they're just trying random shit until it works. Which, interestingly, is part of how the tax regs define a process of experimentation. Instead of "trying random shit until it works," the regs call that strategy "a systematic trial and error methodology."
Your issue is that you have a mental definition of R&D but the tax codes of the US and Canada do not define R&D in the same way, which to you seems dishonest. But you need to remember that, from a tax perspective, the definition isn't important except insofar as it helps or hinders the underlying policy objectives. Your definition may be closer to a colloquial or idealized definition of R&D, but it's not necessarily the definition which best achieves the policy objectives of the governments in question.
The quality of your data dictates the probability of getting an accurate, audit defensible credit calculated. More detail makes it easier to defend. We can work with "R&D work" level of detail, but it is less defensible and it will cost more to have us (an accounting or consulting firm) calculate the credit for you. It also makes it much harder to calculate in-house or using paid self-help software tools.
Particularly because IRS rules require that the wage costs be allocable to a "business component." Business component is a technical term of art specific to the R&D credit, but roughly it corresponds to projects, and more specifically to a (1) new or improved (2) product, process, technique, formula, or invention. It must be one and only one of those, no mixing of new and improved or product and process. So if you have a new product and a corresponding new production process, they must be separated in the reporting of qualified research expenditures, even if you as a taxpayer have classified the two BCs as a single project.
So when you have time tracking, it is best when it allows us to tie specific hours worked to specific projects and tasks. We can then work out from the project list how to combine or split up your projects into business components and map the costs that way. From your activity codes, we can set a very specific and defensible qualified percentage to each employee's time, without having to disrupt your business by surveying your employees (plus the IRS does not respect self-reported, non-contemporaneous survey data much if at all).
As an example, I walked into a software dev client's offices a few weeks ago to sit down with the CFO, comptroller, and their head of development. I walked out with highly detailed project tracking data and spent four hours processing it using our internal software tools, calculating a $2m benefit with a high degree of accuracy. At other firms with lower quality data, it can take hundreds of man hours to achieve the same benefit. So we gave the software client a massive break on our fee (and actually still profited more than we would have with a less prepared client) and everyone walked away happy.
And this does not necessarily require everything to be done by the developer
Even if the value that can be obtained by this is higher, it seems to me it's cheaper (in general) to have someone track the effort in this specific way than make developers do it. (Also if your developers are unhappy or busy no tax credit can save you)
I think that you're not necessarily considering the side effects of (A) working 10 hour days, and (B) spending an hour on paperwork. People will often start to wonder why they work so hard if the company doesn't take their time seriously. This can negatively impact morale, and that has a real, if hidden, cost.
I picked those numbers to make the math easy. No one should or will spend anywhere near an hour entering time into a time tracking system, unless it is horribly designed.
>People will often start to wonder why they work so hard if the company doesn't take their time seriously.
This is a failure of communication. People tend to get frustrated with paperwork when they do not understand its purpose or importance. Those employees who are discouraged by hours tracking paperwork don't realize that the company is being paid by the government to have them fill out that paperwork. Management needs to communicate to employees that there is a very significant impact on the bottom line from them properly filling out that paperwork. That impact increases their wages and the company's ability to survive and thus to provide them continuing, stable employment.
Now, if you think its pointless that the IRS requires them to fill out this paperwork, well that's another discussion, but I can offer you arguments in favor of verifying R&D activities before granting public subsidies for them and in favor of the subsidies themselves.
I am at a 13 person startup. We use Confluence, Bitbucket, Google Apps, and we also use Asana (instead of Jira). It is a nightmare... Information is spread out all over these platforms. We can't stick to only Atlassian tools because the CEO thinks they don't allow you to collaborate... We spend a lot of time looking for where information lives and debating where it should live, complete waste of time. In a smaller company this sort of behavior can be catastrophic.
>> We use Confluence, Bitbucket... Asana (instead of Jira)
This is the thing with the Atlassian ecosystem. Whether you are pro-Atlassian or anti-Atlassian, there are only two sane options: you either all-in with everything Atlassian, or you are better off with nothing Atlassian. Mixing and matching products when Atlassian is involved is the wrong choice, every time.
The Atlassian suite as a whole is fantastic when the integrations are set up properly. If you dislike Atlassian's licensing or even one of their products, then you should not be using them at all. Don't take on 1-2 of their products, and then replace one of their other core products with an unintegrated competitor. Having a partial Atlassian setup is frustrating as hell to work with.
I dunno, JIRA works reasonably well as a standalone and integrates with everything under the sun. However I definitely see your point in replacing JIRA w/ Asana as it's really gutting the core of the suite.
I totally agree, and I think a lot of people will have been in this situation too.
There is, unfortunately, no simple solution other than the very obvious one, which is to use the right things for the right job, and as few of those things as you can. The really crushingly miserable situation is one where the documentation is in Confluence and Google Docs and some random files in Dropbox before they started using the first two and some files that someone shared on the Slack channel and a few things that are just in the CTO's inbox which he was sent by the CEO in PowerPoint and... it's utterly toxic.
This proliferation of excellent tools we have today should be a good thing, but really we are all victims of our own best intentions sometimes (in that horrible chain of misery, even the CEO honestly thinks he's being helpful by emailing a PowerPoint rather than just telling someone over the phone).
Highlighting a table in Confluence, right clicking and turning each item into a JIRA ticket makes my life so much easier.
Similar with Bitbucket. Auto issue transitions means the devs don't have to muck around in JIRA as much. As soon as they start working on a branch (with one click in JIRA) the issue automatically transitions to the in progress column on the board, etc etc.
Reveal: I work for Atlassian and I work using Atlassian tools daily. Asana is a great tool but JIRA is built to help address the issues you are seeing. JIRA functions like a center of gravity to organize your work and many other tools (e.g. ~1000 integrations in the Marketplace connect into it.) We are working on some similar integrations for Trello and have shipped a few already.
If the non-technical staff wants to use Trello, that has nothing to do with the technical staff (though it might be painful for the people caught between the two).
In my opinion, detailed time tracking is pointless. I've worked for companies that required it (only small ones required this), and it was just a painful distraction that never had any perceivable benefit. In larger companies, most people just write 8 hours a day for their project, and that's it. No need to make it any more complex than that.
And Jira is not a reporting tool. It helps you keep track of the work you need to do, and roughly estimate how much work that is, but it's not suitable for detailed reporting. And for a small startup, you don't need detailed reporting. If the boss wants to know what people are doing, he just needs to drop by at the standup meeting.
I wouldn't go and say this is due to stupidity but as a senior professional that would sure be my starting point. That company is in a less than desirable situation, how many other gaffes are there?
Although it is understandable how someone could make this mistake, mandating redundant reporting is a very bad sign in a startup. It shows the manager does not comprehend the difference between a giant company where such large overheads are necessary, and a tiny startup where nimbleness and intimacy and the very thing that gives the company a chance to succeed.
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".
Yeah, I think seniority in field means knowing the interchangeable parts of the stack. Even if the particular technology might be unknown to you, you still know the challenges each part might be representing and how to overcome them/what you should be aware of.
It might be that I read the question wrong. OP says that the tech stack is unfamiliar, and I guess it comes down on whether they've been familiar with a similar tech stack or something is architecturely different.
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.
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.
Same here, s an example, all ORM's have to model the same abstractions for example, so after you've worked with one, the next is MUCH easier to pick up. Same with MVC frameworks, etc. There's a lot of convergence among languages and frameworks now.
To the contrary, I'd say the ability to pick up a product in an unfamiliar tech stack and be productive relatively quickly is one factor that would make you more deserving of the "senior" qualification.
There is no such official role in my organization. But the expectation from me, owing to my experience, is to ramp up fast and lead the engineering aspects of the team.
I agree with you, but as a Senior Developer, I am expected to pick up the tech stack quickly, and help the team learn good engineering practices, which are pretty much applicable to all stacks (DRY, SOLID, KISS etc.)
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.