Cooking up Some Workflow – InApps 2022

This has been a miserable week.

I am cranking simultaneously on two website commissions, neither of which is particularly complex and both of which are proceeding with glacial sloooowwwwnneess. The lack of progress is maddening: This is work I enjoy. I’m pretty handy with the necessary tools. I have spent most of my waking hours banging away at both projects. And yet, after at least 100 hours over ten days (guess how I spent the Labor Day holiday weekend — laboring!) neither project is ready to show the client even as a rough beta.

Late last night, after yet another endless, miserable day featuring the tiniest of bits of forward progress, I finally realized that root of all my suffering is workflow. As in, I have none. Or rather, I do have a workflow, only it sucks.

Currently, my personal version of workflow is the front-end web dev equivalent of a pig on ice, skidding all over the place while desperately trying to retain the slightest sense of progress or direction. This realization struck me during a late-evening rant (via Slack) with my coder pal Asa. Pouring out my frustrations with both projects, I typed the words, “If someone just showed me the design they wanted, I could code it no problem — so what IS my problem?”

“If you were a contractor, you would never start building the house while the architect was still designing it.”

It was one of those lightbulb moments: the problem was that I have been hired to design and build both of these sites. I am in charge of showing me the design, which I can then code. But I had been designing as I built, with almost no plan, no project outline, not even a rough sketch of the underlying architecture on a bar napkin.  My entire project prep consists of a single Post-It note with things that one of the clients doesn’t want in her site.

“Yeah,” Asa typed back. “If you were a contractor, you would never start building the house while the architect was still designing it.”

Duh. It seems so incredibly obvious now. But I had been doing the equivalent of attempting to stand on a floor that hasn’t even been built yet, while simultaneously trying to figure out why the master bathroom has seven doors but no windows or plumbing. So I was working my ass off, true, but in an almost epically ineffective way. My efforts were duplicative, short-sighted, and wasted an incredible amount of time.

The thing is, I have no idea how developers learn workflow. I can remember, in the rushed and fervent “learn everything now” atmosphere of boot camp, that we briefly discussed it. The main takeaway is that it’s important to have a good workflow, but — looking back over my class notes — that was pretty much it.

Definitely, there was never any kind of blueprint offered on how to approach a project or a roadmap of best practices. Even if they had been offered, though, I may not even be able to appreciate the importance of Workflow 101, hyperfocused as I was on learning the actual coding skills themselves. But, looking back, it seems downright negligent that we front-end n00bs were not given any kind of basic birds-and-bees discussion of how to actually logically lay out a project, in a linear progression of iterative tasks.

Maybe it’s one of those things that just seems so incredibly obvious that nobody should actually need instruction in “the sequence of industrial, administrative, or other processes through which a piece of work passes from initiation to completion,” as the OED defines workflow. Hoping I was not the only one who has struggled with this, I asked Asa — who graduated from an earlier cohort of the same boot camp — how he had achieved his own version. “From other software developers who I pissed off by not having any,” came his short reply.

Ah, so there is one clue to my workflow cluelessness: currently, I am still a one-woman show, freelancing on solo projects. I have to work with clients, but I don’t have developer colleagues sitting at the next desk. I can’t just learn by watching, or by getting flamed when I blunder in on anyone else’s project with my little pig-on-ice hooves.

So, late as I am running with both of these projects, it seems like a very smart idea to pause and try to figure out a better way to work. Because the way I’m working sure AF isn’t. Googling “front-end web development workflow” stirs up an avalanche of apps and software that helpful people would love to sell me to fix my problem. But again, not so much an ABCs of how to just, you know, learn how to do it better on my own. So I stepped back even further and took a (sideways, cringing) look at how I was trying to conduct business.

Here is what was wrong with my workflow:

• I cherry-picked the things I like best and did those first. Because I’m only human. I mean, who doesn’t prefer to work on the fun stuff? For example, the very first thing I did for one of these projects, a portfolio site for a furniture artist, was to build a nifty little JavaScript-powered gallery template for building out the many, many pages to be devoted to individual artworks. Before, you know, even sketching out the site architecture or seeing the assets files.
• I jumped around. When I got stuck or overwhelmed by a project problem, I would drop it and move on to something else. This meant lack of consistent progress on any one front and left me feeling like I was making little appreciable progress on either project. Also, if I was doing one thing and noticed a small bug in a nearby, related but still different thing, I would jump right over to fix it — thence dropping whatever I was doing.
• I had no specific project plan of attack. I’m not completely clueless — I approach building any website using the same build logic: Big screens first, front-facing inward, etc. But in terms of taking a strategic look at the project before me, assessing its parameters, making design and structure decisions — nope. I was just making sh*t up as I went.
• I wrote absolutely nothing down anywhere. See bug-hopping, above. Had I just kept a “things to go back and fix later” list, for example, I could have made notes when spotting an issue instead of dropping everything to rectify it. Which sometimes took just a second, but often turned into a nightmarish rabbit hole. Or if my mental picture got fuzzy, say of how the second-tier pages of the site were supposed to tie together, I had no reference I could quickly glance at to get back on track. Instead, I had to stop and think/puzzle my way through, each time.

I was horrified by this list. I cook most of our meals from scratch, and if I approached making dinner the way I’d been trying to build these projects, my kids would starve to death before I got food on the table. But framing it as meal prep was actually helpful because I can see how that internalized workflow is crucial even as it makes my life so much easier. I know not just how to make individual recipes, but how to prep them, stage them, time various cooking lengths — and eventually serve every simultaneously as a nutritious and reasonably tasty meal.

Developing a website, then, can work the same way as cooking dinner. (At least for me — maybe you never cook, but you can choose your own area of existing expertise and compare that way). Like chopping and sauteing, I already have the various skills necessary to design and build a banging site. What I am not yet good at is fitting them together in the right order so they build upon each other, quickly and with a minimum of wasted effort, so as to deploy them to the hungry waiting client.

And the ultimate payoff: unlike cooking, the final stage of web dev workflow is not washing all the dirty pots and pans. I like this better already.

Feature image via Pixabay.