Ask HN: How do you become productive in a new project as a senior developer?

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.

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!