Learning React is easy, but learning how to properly architect an app using React is an exercise in frustration. React is just the view layer and Flux is a pattern for updating views. But there is a large gap - how to organize your data in a React app. And while React is an amazing library, Facebook left the data organization part as an exercise for the reader. And this, I believe, is a big problem.

Because Facebook left React as just a component of an as-yet undefined framework, the Javascript community was forced to define the rest of that…

Calliging courtesy of Hally Ammons (https://www.instagram.com/hallyammons/)

Start today! All you need is a bit of time and discipline.

I am an avid side project-er. At any point in time I always have at least one “thing” going on in the background that feeds my appetite for playing with new tech and learning new stuff.

Side projects can be liberating and super fun. They are great for your career overall and could lead to great opportunities. These side projects have had an amazing effect on my career, and they can help yours immensely as well!

Some of the many benefits of side projects

You learn a ton. There is no shortage of new tech, new languages, new paradigms and techniques that you need to learn and master…


Recently I started a weekend project called Todolist, which is a little Go application for the command line that does simple task management. Todolist is centered around due dates, and I needed a good way to unit test my code. So the question was, how do I test functions with dates in Go?

Well, in Ruby the answer is simple: you either grab Timecop or drag in ActiveSupport’s TimeHelpers and use travel_to to mock up the date you need to be at.

But you have to ask yourself, is this the best way to test time-dependent code…

QA 101: Defining the terms, what works, and who does what


When it comes to software, the term “QA” itself is highly loaded. Because what is it, really? Is it just a thing at the end of the software delivery line, where quality gets lovingly sprayed on at the end, achieving a nice glossy sheen? Is it a separate department that bolts on quality, where the developers don’t really need to worry about it after they throw it over the wall? Is it that one integration test that one developer wrote, once, and it’s “probably good enough”? Of course not!


Retiring features is a critical part of product management. It takes guts and discipline to do it, but it is critically important to the overall health and success of your product.

If you let too many features creep into your product, the core value proposition and vision can easily get diluted. The product will start to seem “big” and “complex”, and does not easily solve the problem the customer had in the first place.

When it comes to feature requests, the customer is not always right. If we added every single thing our customers requested, no one…


A major goal you should have as an technical leader is to help grow the abilities of your team.

In order to do this, you need to deliberately cut your engineers’ time away from doing their actual work to focus on learning. On purpose. Knowledge workers need sanctioned time to develop themselves and they must feel comfortable doing so at work.

As the saying goes,

CFO asks CEO: What happens if we spend money training our people and then they leave?
CEO: What happens if we don’t and they stay?

Of course, your engineers will stay because…

“Ok, so we launched our new feature last night. However we have 30 customer emails from last night about bugs, and we need to hit those right away. Also the error rate is a little spikey, which probably means there’s more issues, and our response time is up a few ticks. Have a nice day!”

What a bummer.

This is unfortunately how things go during a standup meeting after just after shipping a successful feature. The above narrative might as well be the following instead:

“Ok, we launched our new feature last night. We made a list of all the…

Individuals and interactions over processes and tools.

Why? Because the first principle of the Agile Manifesto is so easy to break. We broke it big time, and we learned a lot when fixing it.

Tools like Jira seduce you into building a mammoth process that is convoluted and hard to convey to your team. You get blinded by the allure of super-sweet metrics and charts. …


The following is a story about how we matured as an engineering team. We went from an ad-hoc process to Scrum, and used Scrum for a whole year. Scrum leveled us up as a team in terms of structure and process. But it caused major morale issues. Then we found Kanban. We implemented it and have never looked back.

From nothing to Scrum

We started using Scrum after using a strange, ad-hoc system of developing software. There was a perception from the rest of the company that things were disorganized. We did not have a PM and did not have a…

At PipelineDeals we have an engineering manifesto. Our manifesto is the backbone of what we stand for as a team. They are high level, core underpinnings of our team’s culture. They read like team-level objectives, but they trancend any time-based measurement. They are here for the life of the company.

Each member of PipelineDeals engineering will always strive:

  • To have a culture that fosters continual learning and self improvement.
  • To keep teams static.
  • To favor technical generalism over specialization.
  • To keep a well tested, easily maintainable codebase.
  • To facilitate practices that enable us to ship high quality software.
  • To keep…

Grant Ammons

Director of engineering at @convertkit and @pipelinedeals. I write about my experiences as an engineering leader and product development.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store