# Startup Learnings - What Taylor Williams Taught Me

DevFeed: [Startup Learnings - What Taylor Williams Taught Me](<https://devfeed.tech/articles/startup-learnings-what-taylor-williams-taught-me-28334.md>)

Original publisher: [Read original article](<http://fuzzyblog.io/blog/startup/2019/12/04/startup-learnings-what-taylor-williams-taught-me.html>)

Author: Fuzzygroup

Published: 2019-12-04T00:00:00Z

Content type: opinion

Language: en

Sources: [Scott Johnson](<https://devfeed.tech/sources/scott-johnson.md>)

Topics: [Development](<https://devfeed.tech/topics/development.md>), [Git](<https://devfeed.tech/topics/git.md>), [pull-requests](<https://devfeed.tech/topics/pull-requests.md>), [Software Engineering](<https://devfeed.tech/topics/software-engineering.md>), [Refactoring](<https://devfeed.tech/topics/refactoring.md>), [Ansible](<https://devfeed.tech/topics/ansible.md>), [Deployment](<https://devfeed.tech/topics/deployment.md>), [Back end](<https://devfeed.tech/topics/backend.md>), [Software as a service](<https://devfeed.tech/topics/saas.md>), [Amazon Web Services](<https://devfeed.tech/topics/aws.md>)

Tags: [ansible](<https://devfeed.tech/tags/ansible.md>), [aws](<https://devfeed.tech/tags/aws.md>), [back-end](<https://devfeed.tech/tags/back-end.md>), [deployment](<https://devfeed.tech/tags/deployment.md>), [development](<https://devfeed.tech/tags/development.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [git](<https://devfeed.tech/tags/git.md>), [learnings](<https://devfeed.tech/tags/learnings.md>), [pull-requests](<https://devfeed.tech/tags/pull-requests.md>), [refactor](<https://devfeed.tech/tags/refactor.md>), [repo](<https://devfeed.tech/tags/repo.md>), [saas](<https://devfeed.tech/tags/saas.md>), [startup](<https://devfeed.tech/tags/startup.md>), [taylor-williams](<https://devfeed.tech/tags/taylor-williams.md>)

## AI overview

The author explains how Taylor Williams taught them disciplined Git workflows for startup and side-project development. The approach uses ticket-linked feature branches, atomic changes, pull requests, testing before merging into develop, and a pristine master branch that can be deployed at any time.

## Source excerpt

Note: Code Cat watches disapprovingly as I work ... The bulk of my career has been spent at the small scale of the startup universe - companies with 15 people or less; often a lot less; more than a few times, I've been the only engineer. I have done three stints with companies at or near the three figure number of employees: Dataware, Mascot Network and Seas Education. One of the characteristics of working at the small scale of startups is that what matters is results. How you do it generally doesn't matter - that you do it does matter. And, perhaps unsurprisingly, this can lead to some bad things when it comes to engineering processes. To this point, I've actually been dubbed "the anti process" in at least one organization I spent some time at. So keep that in mind as you read on ... I'm actively working on an (unlaunched) side project and I noticed this today: That's from the repo on my side project and it indicates that I've created 500 pull requests (this was tied to issue #444 which only got merged this morning; the current issue number is 501. Issue 444 was a major refactor that has been a long coming. I'd like to joke that aggressively using pull requests, even on an unlaunched, personal side project, is "how Mother Johnson taught me to do open source" but that would be an untruth. This is a Startup Learnings post and I learned this from Taylor Williams. Taylor Williams is currently the head of software engineering for Seas Education, a SAAS product focused on record keeping for special education. I worked for Seas for about 18 months during which time I focused on AWS infrastructure, deployment, Ansible and back end features. When I came into Seas, Taylor was still a bit on the junior side but I watched him grow and develop as he took on a larger and larger role, culminating in a promotion where he took on leadership of all software engineering, across all product lines. What Taylor taught me was git discipline, specifically: All development is done in feature b