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

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."

It's a small startup that hasn't been around for years. And it isn't a purely software focused company. Most of the engineers will be joining soon to start on this new product. They don't have a ton of engineers currently at the company.

Then hire some engineers and let them decide. If they don't immediately know what they want to use then you are not hiring engineers, you are hiring wannabe's or college kids.

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.)

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

Those are good points. Tech stack can be anything as long as it runs on windows.

What's the benefits of doing desk checks and code reviews?

Code reviews are one of the best ways we've found to improve code quality. If you're not familiar with it, then you should read up on it. There are plenty of resources out there discussing code reviews (e.g. http://dl.acm.org/citation.cfm?id=2597076 or Steve McConnell's "Code Complete".)

Think about it this way. Code is as complicated writing. There is no successful media organization in the world that would publish a book or magazine without at least having one round of review, because hundreds of years of practice has shown that review improves the final product significantly. It's hubris to imagine that programmers are any better than authors.

Oh, definitely. Code reviews are really valuable. I'm just curious about desk checks in addition to code reviews.

Edit: that paper's pretty interesting. I haven't really thought about what made good code reviews and what the causes of defects are.

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 and start on the next chunk of work in the project. Note that on Github, if you tag someone for a review, and they make a comment, you need to tag them again for your PR to show up in their list of PRs-to-review.

Keep your work tightly in-sync with master. If there is a feature that I don't want to go live, I use a feature flag to turn it off rather than keeping it out-of-sync with master. Merging large changes that have gotten far out of sync is hell.

For project management, try to be as lightweight as you can. We use a 1-page markdown doc of "Here are good questions to ask to make sure you've understood the scope of the problem and have talked to relevant stakeholders." and we break the project up into trello cards that roughly correspond to PRs.