My current workflow stack

Happy 2017, lets take a look at the current tooling for this year!

One of the joys of starting a new greenfield project, is the chance to choose the technologies and tooling that the project is built on top of. When I'm making these decisions, I tend to have two different stacks in my head. The first is the technology stack and this is what is generally needed to run my application. It might contain third party services, languages, and frameworks. The other is my "workflow stack", this is what I use to get the project to happen rather than the application to work. That stack, is todays focus.

What is the stack for?

When starting a new project there are lots of unsolved problems. The last thing I want to be spending time on during a project is figuring out how to communicate across the team. It slows us down and no one really enjoys solving those problems anyway.

As a result, I've come to settle on a small stack of tools which I use by default. When starting a new project, these aren't even given much consideration anymore as they're just my starting point. The only time I really consider them heavily is when I feel I might need to change them for some reason.

The stack

I'm going to go through each item on the stack and list some pros and cons. The number of pros and cons don't always seem to line up, but they're just some off the top of my head. If you're looking for advice, talk to me on twitter!

Markdown

I'm a huge fan of Markdown as everyone knows. I write notes in it, I write essays in it, I even write this blog with it. I think it's a fast and simple markup language and I absolutely love how easily it can be converted into html and have a nice stylesheet applied.

For that reason, Markdown is my go-to for any documentation on the project. The README, and any documentation which it outside of the code is all in markdown. It's also usable in some of my other tools as well.

Pros

• Fast to write with minimal syntax.
• Converts easily to display for the web.
• Supported across my other tools (github, slack, etc).
• Easy to keep along side the project.
• Is a light-weight format with small file sizes.
• Can easily be read in any editor.

Cons

• Takes time to learn and get used to. If a team member hasn't used it before, they'll need to skill up on it.
• Requires knowledge of CSS if you want it to look pretty past plain text.

Git

My go-to for version control! It's very powerful, fast to use, and almost every mistake can be undone. Right now I don't see any source control system which works as well as Git. I know that's quite a strong view but it's my current standing.

Branching works really well and the tools built around it also make life much easier for me. Not to mention it handles Markdown really well!

Pros

• Very un-opinionated with how it's used, you're very free to form your own workflow.
• Great extension tooling around it.
• Multi-platform so everyone can use it.

Cons

• Steep learning curve!

GitHub

We all knew this one was going to be on here. It has it's pitfalls but it's still my default for source control along side Git. Currently all my projects are rather small and so the project management tools work really well for me. Issues, Pull Requests, and even the Wiki I find to be great tools on small projects.

GitHub pushes everything to be visible and I'm a big fan of that. The more that's visible, the more likely everyone is to be on the same page.

Pros

• Lots of developers have experience with the tool already.
• Tight integration with the rest of the stack.
• Tight integration with other CI tools such as Travis.
• Project management tools such as Issues, Projects, and Pull Requests which each function well.

Cons

• Yet another thing to learn alongside git if never used before.
• Project management tools are often criticised for not providing enough value.
• Can be quite pricey for a small bootstrapped project.

Slack

For projects with a team I'm loving Slack at the moment. It has tight integrations with my other tools of choice and the way it's made IRC easy to run is wonderful.

I'm a big fan of optimising a slack team because it reduces noise and increases signal. I think Slack are doing a great job of making the IRC into a service for more commercial use and the free-tier generally suits my needs pretty well.

Pros

• Easy to learn and on-board people.
• Relatively un-opinionated and can be used however the team desires.
• Tight integration with a huge number of tools (github, wercker, etc).
• Multi-platform so everyone can use it, also has a web client so doesn't even need downloading.

Cons

• Free-tier doesn't give unlimited history.
• Can quickly become expensive for a bootstrapped project who simply want full historical archive access.

Subject to change...

That's my tech stack as of January 2017. If things change dramatically then I'll have a look at making a new post with additions or changes.