I realize you were possibly asking these rhetorically, but let me answer these questions for the sake of trying to let you see through the eyes of someone who does feel "somewhat confident" in guiding large projects; because I believe you'll find that you may have more intuition for it than you realize, and that at least for me there's been no Magic(tm)
How much should we be writing tests?
- How much do you need them? (Are you grinding out an MVP on very short notice, or setting down the foundation of a long running important project?) and if you need a more obvious signal, are you hurting from not having them?
How much should those tests cover?
- See the above; but additionally (and tautologically), what parts of the code do you worry about tests covering?
What type of tests?
-What type does your team feel comfortable with using and maintaining long term?
Should we use Agile/Waterfall/etc?
- See the above, additionally consider if the context you're in (because the powers that be over you incurr a LOT of constraints) really encourages one of these.
Do we need code reviews?
- See "how much should I be writing tests"
Pair programming?
- Continue to cite the above, as well as "does it work for your team"
Continuous integration?
- Is the overhead worth the benefits? (this is not a loaded question)
What should the deployment be like?
- Easy, robust, hard to fuck up, easy to clean up.
I stopped here intentionally because your latter questions touch on technical decision making, to which I'd give unified advice: Get to know the space. Get to know your tools, then ask someone smarter than you :) Less glibly, someone else has almost always done what you intend to, if not many someone else's, and their experience is so fucking valuable I cannot emphasize it enough, this is also half the benefit of having a personal network. However, you need a mental model of the space to evaluate their learnings in your context, and that just takes playing in that space until you feel comfortable with it.
I really hope this doesn't come off as a preachy rant, my goal is to address your final sentence; to echo my original statement, that I believe you can apply the experience you've gained as a dev thus far to the questions you claim to have no experience for (and you go so far as to demonstrate this e.g. your rails example); and even in absence or presence of that, leveraging your team and peers is invaluable for making "less bad choices", and you're already doing that by asking here on HN. You're already walking the path you are aiming for.
How much should we be writing tests? - How much do you need them? (Are you grinding out an MVP on very short notice, or setting down the foundation of a long running important project?) and if you need a more obvious signal, are you hurting from not having them?
How much should those tests cover? - See the above; but additionally (and tautologically), what parts of the code do you worry about tests covering?
What type of tests? -What type does your team feel comfortable with using and maintaining long term?
Should we use Agile/Waterfall/etc? - See the above, additionally consider if the context you're in (because the powers that be over you incurr a LOT of constraints) really encourages one of these.
Do we need code reviews? - See "how much should I be writing tests"
Pair programming? - Continue to cite the above, as well as "does it work for your team"
Continuous integration? - Is the overhead worth the benefits? (this is not a loaded question)
What should the deployment be like? - Easy, robust, hard to fuck up, easy to clean up.
I stopped here intentionally because your latter questions touch on technical decision making, to which I'd give unified advice: Get to know the space. Get to know your tools, then ask someone smarter than you :) Less glibly, someone else has almost always done what you intend to, if not many someone else's, and their experience is so fucking valuable I cannot emphasize it enough, this is also half the benefit of having a personal network. However, you need a mental model of the space to evaluate their learnings in your context, and that just takes playing in that space until you feel comfortable with it.
I really hope this doesn't come off as a preachy rant, my goal is to address your final sentence; to echo my original statement, that I believe you can apply the experience you've gained as a dev thus far to the questions you claim to have no experience for (and you go so far as to demonstrate this e.g. your rails example); and even in absence or presence of that, leveraging your team and peers is invaluable for making "less bad choices", and you're already doing that by asking here on HN. You're already walking the path you are aiming for.