Ask HN: What is the first thing you implement at a new company?
#tl;dr<p>Regardless of how long you stay with a company&#x2F;team always leave it better than you found it.
Requirements Gathering, Paper Prototype, MVP, UX-testing, Docs, Tests, Linting, Static Analysis, Git&#x2F;GitHub Workflow, Team&#x2F;Personal Learning, Code Quality, CI&#x2F;CD, Pipelines.<p>#longform<p>Assuming the company is new to <i>me</i> but has already been writing&#x2F;shipping code for before I arrive ...<p>I ask clarifying questions to get &quot;up-to-speed&quot;:<p>1. <i>What is the Problem?</i> - Understand what problem they are trying to solve, do users actually realise they have the problem or is it a case of &quot;build it and they will come&quot;...? (it&#x27;s <i>vital</i> to know why we are building something to avoid wasting lots of time on something people don&#x27;t want! 
see: Bill Gross &quot;Why Startups Succeed&quot;: <a href="https:&#x2F;&#x2F;www.ted.com&#x2F;talks&#x2F;bill_gross_the_single_biggest_reason_why_startups_succeed" rel="nofollow">https:&#x2F;&#x2F;www.ted.com&#x2F;talks&#x2F;bill_gross_the_single_biggest_reas...</a>
or Paul Graham &quot;Make something people want&quot;: <a href="http:&#x2F;&#x2F;www.paulgraham.com&#x2F;good.html" rel="nofollow">http:&#x2F;&#x2F;www.paulgraham.com&#x2F;good.html</a>
A &quot;red flag&quot; is when there are no clear &quot;personas&quot; for prospective users. see: <a href="https:&#x2F;&#x2F;www.interaction-design.org&#x2F;literature&#x2F;article&#x2F;personas-why-and-how-you-should-use-them" rel="nofollow">https:&#x2F;&#x2F;www.interaction-design.org&#x2F;literature&#x2F;article&#x2F;person...</a><p>2. <i>Workflow?</i> - Is there an existing <i>clear</i> &quot;<i>workflow</i>&quot; for collecting requirements, defining user stories and getting the features built and UX-tested? or is it all verbal between &quot;founders&quot; and the one dev? (comes back to how old&#x2F;new the company is; is it a <i>brand new</i> &quot;startup&quot;...?)<p>3. <i>MVP Defined?</i> - What &quot;<i>MVP</i>&quot; has <i>already</i> been <i>shipped</i>? who built it? what tech was used? was the work &quot;outsourced&quot; e.g: to remote contractors or an &quot;agency&quot;? was a revision control system used e.g: GitHub? If no MVP has been shipped, is it at least clearly defined in the backlog?<p>3.a <i>Paper Prototype?</i>: what is the <i>minimum</i> you can do to test an idea?
See: &quot;Google Ventures Design Sprint&quot;: <a href="http:&#x2F;&#x2F;www.gv.com&#x2F;sprint" rel="nofollow">http:&#x2F;&#x2F;www.gv.com&#x2F;sprint</a> &amp; <a href="https:&#x2F;&#x2F;youtu.be&#x2F;Z8MOwcqZuuU" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;Z8MOwcqZuuU</a><p>4. <i>Technology &amp; Tool Selection</i> - If the personas &amp; problem is well defined, and minimum features captured in a &quot;backlog&quot;,
then we can discuss technology choices. It&#x27;s <i>essential</i> to have these choices documented <i>somewhere</i>, because this question will come up in the future and &quot;because it&#x27;s popular&quot; on <a href="https:&#x2F;&#x2F;stackshare.io" rel="nofollow">https:&#x2F;&#x2F;stackshare.io</a> is not a good <i>reason</i> for selecting a tech&#x2F;tool; whereas &quot;it was the best choice for our specific problem&#x2F;domain&quot; is a good reason to choose a tech&#x2F;tool e.g: <a href="https:&#x2F;&#x2F;github.com&#x2F;dwyl&#x2F;technology-stack" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;dwyl&#x2F;technology-stack</a>
For example: if you&#x27;re building a robust real-time messaging system, use Elixir&#x2F;Erlang every time.
If it&#x27;s just a &quot;low budget quick-to-market&quot; MVP to get a demo out to start testing and get &quot;funding&quot;,
use Meteor: <a href="https:&#x2F;&#x2F;www.meteor.com" rel="nofollow">https:&#x2F;&#x2F;www.meteor.com</a> (and accept the &quot;technical debt&quot;!)<p>5. <i>Developer Workflow</i><p>- <i>Documentation Driven Development</i>: If it&#x27;s not already being done, focus on this <i>first</i>, without clear docs for the work done, &quot;you&#x27;re going to have a bad time&quot; when trying to understand (never mind &quot;fix&quot;) things in production.<p>- <i>Test Driven Development</i>: If tests aren&#x27;t already being written, understand why and fix it.
Should you follow (&quot;strict&quot;) &quot;Test <i>First</i> Development&quot;? Or is it &quot;OK&quot; to write tests <i>after</i> the code? The answer is simple: if you want to write <i>less</i> code that is more reliable, learn how to (and discipline yourself&#x2F;team) to write the tests first! see: <a href="https:&#x2F;&#x2F;github.com&#x2F;dwyl&#x2F;learn-tdd" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;dwyl&#x2F;learn-tdd</a>
If you&#x27;re stuck writing the tests for a feature&#x2F;idea ask for help till it becomes natural!<p>- <i>Pre-commit Hooks</i>: Make the tests, &quot;linting&quot; and doc checks run on the developers localhost before they can commit. See: <a href="https:&#x2F;&#x2F;github.com&#x2F;dwyl&#x2F;learn-pre-commit" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;dwyl&#x2F;learn-pre-commit</a>
If your tests &quot;take too long to run&quot; don&#x27;t use it as an <i>excuse</i> to disable the pre-commit, fix it! Having slow tests (and build process in general) is a cancer that will gradually &quot;sap&quot; the productivity &amp; energy of the team! Analogy: it&#x27;s <i>much</i> more difficult to get physically fit if you are an obese &quot;couch-potato&quot; than if you simply <i>maintain</i> your fitness each day; &quot;Unfit&quot; Apps die young.<p>- <i>Code Analysis</i>: If there is an automated tool for your chosen tech&#x2F;tool&#x2F;stack use it! Even if costs money, think of it as &quot;member of the team&quot; not an &quot;expense&quot;. It will <i>always</i> save you time in the long run.<p>- <i>Continuous Integration</i>: Pick a CI system based on your tech&#x2F;tools and implement it for your app. it only takes a few minutes: <a href="https:&#x2F;&#x2F;github.com&#x2F;dwyl&#x2F;learn-travis" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;dwyl&#x2F;learn-travis</a><p>- <i>Code Review</i>: 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.<p>- <i>Continuous Delivery</i>: When Pull Requests are merged, they should be automatically deployed! 
If the app&#x2F;product&#x2F;company is <i>new</i>, use Heroku for deploying your app! Don&#x27;t waste time on DevOps till you need to! Migrating to AWS or GCP is <i>easy</i> once you have &quot;traction&quot; (i.e. if you&#x27;re paying Heroku $200&#x2F;month, you can <i>justify</i> orchestrating&#x2F;managing you own DevOps&#x2F;Infra). see: <a href="https:&#x2F;&#x2F;github.com&#x2F;dwyl&#x2F;learn-heroku" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;dwyl&#x2F;learn-heroku</a><p>- <i>Continuous User Testing</i>: Ensure there is a clear process for testing the new features you are releasing. Ideally &quot;get out of the building&quot; and test with &quot;real users&quot; <i>in person</i>. see: <a href="https:&#x2F;&#x2F;steveblank.com&#x2F;2010&#x2F;03&#x2F;11&#x2F;teaching-entrepreneurship-–-by-getting-out-of-the-building" rel="nofollow">https:&#x2F;&#x2F;steveblank.com&#x2F;2010&#x2F;03&#x2F;11&#x2F;teaching-entrepreneurship-...</a>
&quot;weekly&quot; should be the minimum user-testing cycle. No &quot;excuses&quot; to not test! Use online services like <a href="https:&#x2F;&#x2F;www.usertesting.com" rel="nofollow">https:&#x2F;&#x2F;www.usertesting.com</a> if you aren&#x27;t physically near to your users.<p>- <i>Continuous &amp; Validated Learning</i>: Instil the habit&#x2F;culture&#x2F;expectation that <i>everyone</i> should keep learning. If people &quot;stagnate&quot; everyone suffers. The Product will be worse, the best people will get jaded and leave. Learning is <i>easy</i> to forget but it&#x27;s just as easy to maintain, it&#x27;s just a question of routine.