I've never founded a start-up. I've never been a CTO. With that said, I have spent a fair amount of time in this industry working at companies that I was not in on the ground floor at. That has resulted in me working in code and with coworkers that were there before me. I suffered and benefitted from those that came before me. Most of the time this meant I spent a lot of time paying for the sins of the past, but I also benefitted from great coders who came before me and established standards.
My best friend is starting a tech company with his brother. This has caused me to really think about what I would do if I was in his shoes. I want him and his new company to succeed. I hope they build an amazing product and make the world a better place.
So here is a completely non-exhaustive numbered list of my advice that I'd give to anyone responsible for writting the initial code at a new start-up. Every single one of these points are intended to be things you're doing or thinking about on day one.
In no particular order:
- Establish style guides for all the languages you're using — preferably before the first line of code is written. There's no need to write this style guide from scratch. Many awesome and battle-tested style guides already exist and are easily found. It's much easier to stick to a style guide from the beginning rather than implement after thousands of lines of code are written. When you're in crunch time and angel investors and VCs are asking you when they can see a minimum viable product you will not have time to go and fuss over whitespace or naming conventions.
- Establish version control practices. I know git the best so I'll use it in my examples. There are myriad workflows in git. Find one that works for you and stick to it. This will help you plan how you will do releases and handle sticky situations. Ask yourself questions like — will you tag? If so what is the tag naming convention? Do you do rebase when you pull or merge when you pull? When you merge branches back into master do you
--squashor not? Do you merge to master with the
--no-ffflag? What is your method for handling nasty merge conflicts (they will happen and they will happen at the worst time possible)? If you establish all this at the start things will go much more smoothly as you introduce new people to the team — each with their own version control histories and preferences. You don't want a master log full of squashed commits, merge commit from other branches, and rebasing conflict resolution commits. This is terrible. Enforce consistency.
- Write good commit messages. In fact, I recommend against using the
-mflag in git unless it's the most small and inconsequential commit. When you use
-myou artificially feel constrained to your terminal window and condense your message. Without it git by default opens up VIM (but you can easily have it open your text editor of choice). Seeing a text editor in front of you will encourage you to write better and clearer git messages. Take the time at the start of the company to do this and you'll establish an practice of writing clear and good messages. This will be important when you have 20+ people committing to the same repo.
- Don't use trial or stolen software. Seriously. Pony up and buy that Sublime Text or Adobe Creative Cloud license. You're a VC funded start-up.
- Use Github and allow as much code and documentation as you can to be public. This will not only help the community, but give interested job seekers a window into how you work. This will help them decide if you're the right fit for them helping you only deal with hiring those who've actually seen and approve of some of your work.
- Establish expectations with regard to email. Do you expect your employees to answer emails quickly? Do you expect them to answer emails before 9am or after 5pm? On the weekends? If so will you be paying (partially or in full) their phone bill? Make your expectations known and clear before you hire them so that way there are no surprises and disappointments down the road. Nothing kills a start up in its infancy more than talent leaving. Avoid this by discussing expectations for email upfront.
- Take #6 and apply it to any policies or expectations you may have (especially work from home).
- Establish culture early. Want a fun office environment? The secret isn't ping pong tables and kegs. It's happy employees who are working on a product they believe in with team members they believe in. Everyone doesn't have to like each other (although it helps) to have good office culture. Having employees who respect one another's skill sets and talents, see their loved ones, and get enough sleep will. Want it quiet? Make it quiet from day one. Want it loud? Get a Jambox and play some music. (Are you noticing a theme yet on establish things on day one?) It's way easier to welcome employee #10 into an already established office culture than to try to implement "culture" after employee #10 arrives. It must be organic. Forced fun sucks.
- Back up! These are the early days! Get your employees offsite backup! I recommend Backblaze. Using MacBooks? Buy external drives and have everyone use Time Machine (and encrypt their back ups). This might sound excessive, but this will save you a lot of headache when a key developer (and hopefully everyone at this earliest stage is key) gets his or her MacBook stolen (or more likely gets drunk and leaves it on MUNI at 1am) you'll only be out the cost of a MacBook and not the much more expensive cost of losing all work that's not pushed to the repo yet.
- Don't use untested open source software or libraries. Think that new hot JS library is cool? Awesome! Play with it in your free time. But unless its got a 1 or greater in front of the decimal in the version number it's subject to massive changes. Hell — that goes for even after it's 1.0-ed. I know everyone's on Node.js which hasn't 1.0-ed, but it has also been pretty battle tested. Its shortcomings are well documented. Help can easily be found on Stackoverflow. Make sure this is true for whatever third-party code you choose to use. Never forget that you do not own this code. It is a layer of abstraction. That abstraction is (mostly) awesome, but can be very costly especially when they jump to 1.0 and decided to deprecate a core feature you built your entire backend system around.
- Stay up to date with what the hell is going in in both the coding world as well as the field your start up is in. This is obvious. I shouldn't have to say it but I am.
- Decide what browsers or OS versions you support right off the bat and then ruthlessly test in those things. Does the website or app need to work the same in all versions? (Hopefully not). Awesome. Read up on progressive enhancement and graceful degradation and do it. If it does need to work identically in all browsers or OSes develop for and test against the least advanced of these.
- Abstraction is awesome, but can be expensive. Add layers of abstraction carefully and add them with eyes wide open. (This is a little bit of a regurgitation of #10, but I don't care. I'm saying it again.)
- Don't only hire your friends. You're starting a company — not an after school coding club. Sarah may have been your best friend since the fifth grade, but is she really the right fit for the system admin role you need to fill? It's really awesome when the answer to that question is "yes", but you need to be okay with it being "no". And if you're all such good friends they'll understand why you didn't ask them to join your new start up.
- Establish code reviews from the beginning. What's the policy on this? Does every commit need to be code reviewed? Can someone commit their own code to master? What tool do you use to code review? Does the commit that corrects the code review need to be reviewed?
- Don't QA your own work. You probably don't have the budget for QA, but that still doesn't mean you should QA your own work. Tell your co-worker what business problem you just solved and have them test it from that angle. Don't tell them you made the red button turn green on click. Tell them you added a call to action button for subscribers.
You will be working a lot. You will be worrying a lot. The last thing you need to worry about is if the code base is readable or consistent or well tested. The last thing you need to spend your time on is teaching a new employee about some cryptic poorly-named hurriedly-written method you wrote six months ago. If you establish all of this (admittedly not fun) stuff up front you can enjoy your time away from the keyboard more. Having all of these policies and pracitices established and in place from the beginning allows you to spend your very valuble time on the important stuff. It also allows you to disconnect. You can turn your brain off easier when you know the code base is consistent and well tested.