#tl;dr

Regardless of how long you stay with a company/team always leave it better than you found it.
Requirements Gathering, Paper Prototype, MVP, UX-testing, Docs, Tests, Linting, Static Analysis, Git/GitHub Workflow, Team/Personal Learning, Code Quality, CI/CD, Pipelines.

#longform

Assuming the company is new to me but has already been writing/shipping code for before I arrive ...

I ask clarifying questions to get "up-to-speed":

1. What is the Problem? - Understand what problem they are trying to solve, do users actually realise they have the problem or is it a case of "build it and they will come"...? (it's vital to know why we are building something to avoid wasting lots of time on something people don't want!
see: Bill Gross "Why Startups Succeed": https://www.ted.com/talks/bill_gross_the_single_biggest_reas...
or Paul Graham "Make something people want": http://www.paulgraham.com/good.html
A "red flag" is when there are no clear "personas" for prospective users. see: https://www.interaction-design.org/literature/article/person...

2. Workflow? - Is there an existing clear "workflow" for collecting requirements, defining user stories and getting the features built and UX-tested? or is it all verbal between "founders" and the one dev? (comes back to how old/new the company is; is it a brand new "startup"...?)

3. MVP Defined? - What "MVP" has already been shipped? who built it? what tech was used? was the work "outsourced" e.g: to remote contractors or an "agency"? was a revision control system used e.g: GitHub? If no MVP has been shipped, is it at least clearly defined in the backlog?

3.a Paper Prototype?: what is the minimum you can do to test an idea?
See: "Google Ventures Design Sprint": http://www.gv.com/sprint & https://youtu.be/Z8MOwcqZuuU

4. Technology & Tool Selection - If the personas & problem is well defined, and minimum features captured in a "backlog",
then we can discuss technology choices. It's essential to have these choices documented somewhere, because this question will come up in the future and "because it's popular" on https://stackshare.io is not a good reason for selecting a tech/tool; whereas "it was the best choice for our specific problem/domain" is a good reason to choose a tech/tool e.g: https://github.com/dwyl/technology-stack
For example: if you're building a robust real-time messaging system, use Elixir/Erlang every time.
If it's just a "low budget quick-to-market" MVP to get a demo out to start testing and get "funding",
use Meteor: https://www.meteor.com (and accept the "technical debt"!)

5. Developer Workflow

- Documentation Driven Development: If it's not already being done, focus on this first, without clear docs for the work done, "you're going to have a bad time" when trying to understand (never mind "fix") things in production.

- Test Driven Development: If tests aren't already being written, understand why and fix it.
Should you follow ("strict") "Test First Development"? Or is it "OK" to write tests after the code? The answer is simple: if you want to write less code that is more reliable, learn how to (and discipline yourself/team) to write the tests first! see: https://github.com/dwyl/learn-tdd
If you're stuck writing the tests for a feature/idea ask for help till it becomes natural!

- Pre-commit Hooks: Make the tests, "linting" and doc checks run on the developers localhost before they can commit. See: https://github.com/dwyl/learn-pre-commit
If your tests "take too long to run" don't use it as an excuse to disable the pre-commit, fix it! Having slow tests (and build process in general) is a cancer that will gradually "sap" the productivity & energy of the team! Analogy: it's much more difficult to get physically fit if you are an obese "couch-potato" than if you simply maintain your fitness each day; "Unfit" Apps die young.

- Code Analysis: If there is an automated tool for your chosen tech/tool/stack use it! Even if costs money, think of it as "member of the team" not an "expense". It will always save you time in the long run.

- Continuous Integration: Pick a CI system based on your tech/tools and implement it for your app. it only takes a few minutes: https://github.com/dwyl/learn-travis

- Code Review: Use GitHub Pull Requests (or the equivalent on BitBucket, GitLab, etc.) and leave helpful comments, besides pair-programming this is one of the best ways to learn as a team.

- Continuous Delivery: When Pull Requests are merged, they should be automatically deployed!
If the app/product/company is new, use Heroku for deploying your app! Don't waste time on DevOps till you need to! Migrating to AWS or GCP is easy once you have "traction" (i.e. if you're paying Heroku $200/month, you can justify orchestrating/managing you own DevOps/Infra). see: https://github.com/dwyl/learn-heroku

- Continuous User Testing: Ensure there is a clear process for testing the new features you are releasing. Ideally "get out of the building" and test with "real users" in person. see: https://steveblank.com/2010/03/11/teaching-entrepreneurship-...
"weekly" should be the minimum user-testing cycle. No "excuses" to not test! Use online services like https://www.usertesting.com if you aren't physically near to your users.

- Continuous & Validated Learning: Instil the habit/culture/expectation that everyone should keep learning. If people "stagnate" everyone suffers. The Product will be worse, the best people will get jaded and leave. Learning is easy to forget but it's just as easy to maintain, it's just a question of routine.