contact us

Use the form on the right to contact us.

You can edit the text in this area, and change where the contact form on the right submits to, by entering edit mode using the modes on the bottom right.


San Francisco, CA, 94160
United States

Writing

Tips For New Start-Up CTOs

Jesse Atkinson

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:

  1. 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.
  2. 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 --squash or not? Do you merge to master with the --no-ff flag? 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.
  3. Write good commit messages. In fact, I recommend against using the -m flag in git unless it's the most small and inconsequential commit. When you use -m you 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.
  4. 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.
  5. 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.
  6. 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.
  7. Take #6 and apply it to any policies or expectations you may have (especially work from home).
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. Hire unicorns. If you need a Rails dev and you find a Rails dev who is the world's greatest rails dev ask yourself before you hire her if she's good at other things. Sure you need her write really awesome Rails code, but you may need her to jump in and help resolve a javascript issue or fix a database issue. You're a start up. You're young. Every coder you hire needs to fully realize that they are not working at a big mega corporation and can sit safely in the language of their choice all day. Shit happens. They need to be cool with this and have the ability to learn quickly to patch things.
  13. The day you write your first line of code is the day you write your first test. Retroactively testing stuff sucks. Write tests as you go. I'm not going to get religious about TDD, but at least ensure that you're writing tests and application code together. This includes JavaScript. Jasmine is awesome and easy to learn and use. Use it. Save yourself headache. Sleep well at night.
  14. 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.
  15. 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.)
  16. 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.
  17. 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?
  18. 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.

My Favorite Page

Jesse Atkinson

photo 2.PNG

This is my favorite page in all of comics. This is page 95 in Astonishing X-Men: Gifted. Four panels. No words. Everything said.

Even if you know nothing about the X-Men I think we can at least agree the art here is gorgeous. John Cassaday is one of my favorite artist working today. I think these four panels demonstrate why. The lighting is consistent, his characters extremely realistic and yet some how maintaining a distinct "comic book feel", and there is action.

Obviously, that's not the only reason why this is my favorite page ever. Art alone wouldn't elevate a single page to a level where I felt compelled to blog about it. It's also Joss Whedon's writing. (Yes, I know there are no words on this page.) The writing and the art come together in this insane magical way that happens every now and then in a comic book. Cassaday draws this scene so perfectly that it tells Whedon's story without the need for words.

But there's another factor here. There is the back story which rewards the readers "in the know", yet doesn't alienate the new.

If you do know about the X-Men you'll recognize these two as Kitty Pryde and Piotr Rasputin (better known as Colossus). Kitty can turn herself intangible. She can walk through walls, or as we're seeing here, allow bullets and people to move through her. Piotr, who without his power is an intimidating force. A tall, hulking, strong-jawed Russian that can turn himself into steel.

Kitty and Piotr dated. They fell in love. It was one of the sweeter and better of the comic book romances. Then Piotr died. I won't go into how or why or all that here. I hope you'll trust me when I say his death was very comic book-y (not that that's a bad thing). But for all intents and purposes—to the readers and to Kitty he died.

In the story Gifted that this page is taken from the X-Men invade a base. I don't want to get into the story because that's not why we're here. All you need to know is that they invade a base. Kitty gets separated and gets into real danger. Clearly there are men with guns shooting at her. But right as they get to her she also discovers the prison that's been holding the love of her life whom she thought was dead.

What we see on Piotr's face here is worry and concern. His love is under attack. Kitty's face is full of shock and confusion. She thought this man was dead. And without a single word spoken Piotr chargers forward through her. And that is the thing that makes this so special to me. There is no dialogue spoken. There is no plan of attack. There is no Claremont style expose on what happened, is happening, and will happen. There is only two faces and bullets flying at them. And without a single word spoken there is an understanding. An understanding that only two people who've been deeply in love know. He charges directly at the enemies knowing she will simply let him phase through her. He charges off to defend the woman he loves who is under attack. The irony here is she doesn't need defending at all. She can stand there all day and let the bullets or anything for that matter pass through her. Piotr could stand there and get shot or punched by these guards and they wouldn't do anything. He charges at them to defend her because how dare someone shoot at the woman he loves. How dare someone think they have the right to attempt to harm the love of his life. And as he runs off to save her Kitty stands there with this blank expression of shock on her face and does one single motion.

She covers her heart.

Setting Up A New Mac

Jesse Atkinson

Recently I've had to set up a new Mac three different times. This resulted in me getting a pretty solid process doing this and doing it quick. Well, as quickly as possible. I figured someone out there might find this useful even if they don't end up following it exactly.

This will take at least a solid 5 hours. There's just no way around that unless your internet connection is insanely fast. A few things worth noting before we start this. I keep all of my .dotfiles, notes, and 1Password library on Dropbox.

  1. Run all updates that are possible from the App Store.
  2. Install Dropbox.
  3. Log in to as many accounts as you can in System Preferences > Mail, Contacts, & Calendars.
  4. Once Dropbox's 1Password folder is synced download and install 1Password from the App Store. Once downloaded—launch and make sure app automatically picks up the keys.
  5. Install 1Password extension for Safari.
  6. In System Preferences > Mail, Contacts & Calendars sign into all of the services you use.
  7. Install all other previously purchased apps from App store you'd like to have on this computer.
  8. Install Xcode
  9. Install Command Line Tools
  10. Open Terminal.app
  11. Install Homebrew
  12. Run brew doctor
  13. Run brew update
  14. Run brew tap phinze/homebrew-cask
  15. Run brew install autoconf brew-cask bash-completion cmake doxygen fish freetds freetype gdbm git imagemagick jpeg libevent libpng libtool libyaml memcached mysql phantomjs pkg-config rbenv readline ruby-build ssh-copy-id taglib tmux wget tree;
  16. Make sure to follow the post-installation instructions for Fish to set it as your default shell. Also, read through any other post-installation instructions for the other forumlas.
  17. Install apps. (Note: Using brew cask is faster, but not ideal and requires you storing all of your apps installed via brew cask not in your Applications folder, but instead installs aliases to the apps in the Applications folder.) If you wish to use brew cask simply run brew cask install alfred bettertouchtool firefox geektool google-chrome google-earth instacast iterm2 keyremap4macbook nv-alt opera skype rdio spotify silverlight steam sublime-text transmit things textmate textexpander transmission vlc virtualbox; (Make sure to hang around for various prompts to input password.) If you do not use brew cask manually install all of those from their respective websites.
  18. Create symlink for config.fish, .bash_profile, .vim/ folder, .vimrc, .gitconfig, .irbrc and Sublime Text folder.
  19. Check to ensure that that set -g -x PATH /usr/local/bin $PATH is in your ~/.config/fish/config.fish and export PATH=/usr/local/bin:$PATH is in your .bash_profile. Run which git to see the git path. If the path is /usr/bin/git then you are not using Homebrew's git. If it's /usr/local/bin/git then you are. You want the latter.
  20. Install Sublime Text commandline tool.
  21. Set nvAlt to read from ~/Dropbox/notes/.
  22. Activate all licenses stored in 1Password.
  23. Install Inconsolata font
  24. Change Sublime Text's ugly icon to this icon
  25. Set up iTerm 2 preferences
  26. Set up keyboard shortcuts in System Preferences
  27. Set your hostname to something decent with sudo scutil –-set HostName NEW_HOSTNAME. Reference
  28. Unhide your ~/Library/ by running chflags nohidden ~/Library/
  29. Install rbenv.
  30. Install Ruby On Rails gem install rails
  31. Replace your Caps Lock key with a Hyper Key following Brett Terpstra's instructions.
  32. Set up Slogger (Make sure you have Day One installed).
  33. Install Brett Terpstra's Markdown Service Tools
  34. Setup Time Machine backup and perform first backup.
  35. Set Dock icons and other basic OS X preferences.
  36. Set Mail.app email signatures.
  37. In System Preferences > Users & Groups set your Login Items and account picture if you so desire.
  38. Drink a celebration drink.