Ask HN: How to set up a tech stack/engineering practices for a new team?

The #1 guiding principle for answering these questions that I've found is: Start with "Why?".

Why are you writing any code at all?

Are you writing code to test a hypothesis and present the results of testing that hypothesis to other people? If so, state that hypothesis explicitly, build the minimum needed to test that hypothesis, and have a clear & concise document (Dropbox Paper, README.md, etc) explaining how the code tests the hypothesis.

Are you writing code to build a product that you plan to maintain for 5-10 years as you add features and support a larger user base? That implies that in 5 years, you are going to have some new junior engineer join the team who will need to figure out how to navigate this codebase and modify it. They will have a job to do and the UI they have to accomplish this job will consist of:

- The codebase itself (including any tests)

- The commit history of the codebase

- Any diagrams or READMEs that were written alongside the codebase

- The issue tracker

- The other members of the team and their memories and communication habits.

Engineering practices and team habits matter because they mean that your more junior engineers are able to much more quickly and confidently do projects to solve evolving business needs as much or writing as many bugs. Think of both your codebase and your project management tools as a UI whose users are the engineering team trying to accomplish business needs. This talk is close to the mindset I'm trying to convey: https://skillsmatter.com/skillscasts/10124-dylan-beattie-the...

Speaking personally, I find that automated testing is extremely useful for moving quickly because it makes it easier for me to break a task down into concrete pieces and to stay motivated by having constant positive feedback. The cost of testing is that it takes a while to set up and is especially difficult if you are not experienced in the toolset you are using. If you don't have a good testing toolchain in place, then writing and running tests is really painful and gets in the way of development

For this reason, it is tremendously useful to have testing infrastructure and practices set up early on in a project by someone who is experienced with the particular framework/language you are using. It is very difficult to introduce tests after-the-fact.

The branching and code review process that I've found most useful is:

```

$ git checkout -b my-feature

# Write some code.

$ git add -p

$ git commit -m "do some small thing"

$ git status

$ git checkout file/that/has/leftover/edits/I/dont/want

# Repeat.

$ git rebase -i HEAD^^^^^

# re-order commits, edit commit messages, and squash some commits into

# larger logical blocks.

$ git checkout master

$ git pull origin master

$ git checkout my-feature

$ git rebase master

# It now looks like my-feature was developed off the tip of master

# And I've resolved any potential merge conficts.

$ git push origin my-feature -f

``` And then make a pull request to merge to master and tag someone to review. CircleCI runs the full automated test suite on the PR. I've only run the few tests that I've modified because they're the ones that relate to my PR. It doesn't make sense to require passing tests for every commit because then you can't write PRs where the tests fail. You might want to do this so you can show someone a Work In Progress and ask for advice. It might make sense to run a linter like rubocop on each commit, but only if each of the linter rules is agreed-on by the team (just make a PR for it and have people +1 or -1).

If I need to make changes to the PR after pushing, I do so and then I rebase on top of master again and `git push -f` the branch. Once tests pass and someone +1s it, I'll merge to master...

Unless you're starting with zero.. Skills on the team? Current stack?

If nothing then I do this:

Git and stash. An agile approach, features and user stories. An agile board. Vsts or rallydev Yes to continuous integration, deployment and automation. Testing, unit tests first. A desktop application may have specific technologies so .. depends.

Oh and code review, pull requests and I actually advise desk checks before submitting PRs.

Regular demos of sprint work is essential

As far as testing goes, there's no one correct answer. It depends on what your goals are (and they'll probably change over time). E.g. if you're rewriting all the code every other week unit tests won't help you much. And unit tests won't catch many bugs. On the other hand unit tests can be extremely useful if much of your code needs to be stable and consistent.

My current second-best explanation of how to choose testing based on goals is written up here: https://codewithoutrules.com/2017/03/26/why-how-test-softwar...

(My best explanation is currently a slide deck that will become the third version of that post.)

Why don't you let the actual engineers decide on the engineering questions, ffs? If you were making aircraft parts, would you ask the internet what software you are going to decide for them to use? No you wouldn't even be allowed to decide unless you were a veteran engineer with some licenses. "I wanna make some wings. We are bringing on 10 aero engineers. what kind of tools and metals should I set up? I heard swept wing is good to use, what are your thoughts. I am leaning towards slide rules, but I heard RPN calculators work well."