That title is a bit dramatic. I’ve written infrastructure as code, pushed stuff to AWS, and supported it for over 10 years. I’ve gotten a bug report in the morning and messaged the support engineer (via Hipchat, because that’s how old I am) that afternoon to let him know the issue was fixed. But most of the “let’s get it out quickly” I’ve worked on over the last several years has been bugfixes. And up until fairly recently, I’ve been in a “big enterprise” environment (although around the time I left we were being encouraged to “pretend we were in a startup” in an attempt to convince us to work weekends to make a release date that was made by people who shouldn’t have been making release dates way too early to be making release dates), so putting things in production was such an involved process that required work from so many other people that my “let’s get this in prod” muscles have atrophied, severely. Now I need to get them back.
Obviously, I don’t mean that I need to start shipping buggy crap (though I’ve pushed my fair share of bugs). But I do need to start finding ways to deploy stuff that’s clearly in progress. I got way too comfortable just writing code, iterating on it, making sure it got through QA, and then declaring it to be someone else’s problem. All anyone really looked at was Jira, and rarely at the application.
It’s carried over to my personal projects. I may not have made as much progress on my gift registry as I wanted, but I don’t even have something deployable (I’m working on cleaning it up so I can run it on a server somewhere). I basically have some Go files that I’m toying around in, but not shipping. That’s bad.
Now I’m working somewhere where people want to see changes in the test environment, so taking a lot of time to do some polish before making a PR isn’t really jiving. I need to build a habit of “here’s the feature flag you need to enable, here’s what’s done on the dev server, and here’s what I’m working on pending feedback.”
This is going to work a lot of skills that I’ve let fall by the wayside over the years, which is good. It’s going to force me to think in terms of product features, user experience, and impact of changes. It also encourages things like feature flags up-front, so stuff can be safely merged while in-progress, without breaking stuff. That way as soon as I have something building with automated tests passing that does something useful, I can merge it in to the test build and have product start working on it. I’m tempted to start doing in-progress merges with new feature stories to support this “ship sooner” push, but I’ll have to see how that plays out with the new team.
I’m not a football guy, but this seems like the equivalent of doing a lot of running plays – a little bit of progress every time, just not anything big and flashy. Hopefully this pushes me to avoid “yak shaving” rabbit holes and helps me build some more productive iterative habits, mostly by putting it on a public record that I can be called out on later.
So what’s the plan? I need to put hiding the change behind feature flags as step 1, not the last step. That lets changes not be customer-facing until I want them to be. Next step, create some visible indication that work is being done. The key thing here is that it doesn’t have to be cleaned and polished, but just enough to show that work is happening. Then get some piece of the feature working well enough that I can trigger a call from the browser and get a visible response back. From there, PR to merge into either a feature branch for quick testing or even to the master branch so it can go ahead and start living full-time on the test server. Then on to the next piece.
What I have found is I tend to iterate a lot on the stuff I’ve already written, and I’ve forgotten that some of that iteration needs to happen after the code is live, because that’s how I know what actually needs iteration, and what’s just me wanting to yak shave.
For my personal project, I wanted to get login/auth done up front so I could have it in place the for all the actual functionality, but that’s taken a lot of up-front time. Once I find the time to get what I have cleaned up, I’m going to deploy it with just a simple static text where the registry goes, just to put pressure on myself to populate the page with actual stuff. I’ve been trying to take time to write solid, defensive code, but I’ve forgotten that real-world data can easily trash every assumption I’ve had about data, and there’s no way to learn that short of actually having them crushed by running code.