Chris Lema published a blog post at the beginning of this month entitled Stop Making Premature Announcements that really resonated with me. I can’t count the number of times in my life I’ve said to someone else, “I’m going to,” “I plan to,” “I want to,” and so on only to realize weeks or months later that I lost interest or focus or drive on the thing I planned, wanted, or was going to do that I simply never saw through to the finish.

It’s far better to be able to proclaim “I did it,” “I built it,” “I created it,” or “I finished it, here it is!”

That post was written in October, and I published my last post at the beginning of August. In that post, I declared that I’m open for business. On September 1st, I began a new Senior Software Engineer role where most of my energy during the day has kept me focus on meeting new people, learning how to work together, figuring out what we’re working on (and how to work on it), and simply getting up to speed like everyone must when they start with a new company.

Two things are certain: I’m loving the challenges, and between everything I’m juggling during the day and the still ever-present state of the world, I’ve just been far too mentally exhausted by the end of the day to accomplish much else.

At the start of the year, I set extremely modest goals for myself. I wanted to keep things light. As light as possible. With everything that’s been going on in the world, from the pandemic to the climate (regular and political) to the struggles everyone has been facing, some far more disproportionately than others, maintaining an upbeat attitude while surviving alone feel like enough of an accomplishment alone. Admittedly, I haven’t been eager to add a set of goals to that load.

With that laid out, this is going to feel so small. I recognize how small it is, how insignificant. But, in this year, in these times, with everything else going on, and how difficult it has been for me to maintain extra motivation and allocate time for creativity, learning, and exploration, I accomplished something I set out to do this year, and I want to tell you about it.

I accomplished my goal of completing 15 books this year.

See? It’s nothing. The effort was full of stops and starts all year long, and the majority of the books I finished I started reading sometime after June. Some of them were technical books, including one that I read as part of the Dev Book Club during the spring, and some were fast, easy reads. But, the important thing is that I set out to do something, I did it, and now I’m telling you about it. And the great thing is, it’s still October, I can still read the rest of the year, and still feel proud that I accomplished something so small.

Here are the books I’ve finished in 2021:

1. Building GitHub Actions by Michael Heap
2. The Beautiful Struggle by Ta-Nehisi Coates
3. Refactoring by Martin Fowler
4. The First Bad Man: A Novel by Miranda July
5. She Memes Well by Quinta Brunson
6. Breath by James Nestor
7. Big Magic by Elizabeth Gilbert
8. Node.js Web Development by David Herron
9. You are a Badass at Making Money by Jen Sincero
10. Year of Yes by Shonda Rhimes
11. Little Weirds by Jenny Slate
12. St. Paul by William Lindeke
13. Exploded View by Sam McPheeters
14. Based on a True Story by Norm Macdonald
15. Kafka on the Shore by Haruki Murakami
16. Humblebrag: The Art of False Modesty by Harris Wittels

I’m currently reading The Gunslinger, the first book in The Dark Tower series by Steven King. 11/22/63 and Under the Dome are two of my favorite novels I’ve read to date, and I’m looking forward into digging into this expansive series. Maybe I’ll even finish it! You won’t hear about it again until I do.

Anyway, I’ve been wanting to write this post for awhile, but I haven’t known how to put things into words. I’m glad I finally did. I hope to do so again soon, but I promise it won’t happen until I’ve accomplished something.

Thanks for reading. I hope you’ve been well.

Over the weekend, I read Big Magic by Elizabeth Gilbert, the best-selling author of Eat Pray Love. It was loaned to me by my partner, Abby, who set it on the coffee table and left a Post-It note that read “Follow your curiosity…” stuck to page 235. Recognizing it as the act of love that it was, I started from the beginning and read it straight through to the end of the course of two days. I’m so glad I did.

The central idea in Gilbert’s book is that living a creative life is a choice we each make. She suggests that ideas are ethereal, and that they come to those who are ready to accept them and work to bring them into existence. We can choose to listen for these ideas – they are quiet, almost faint, and often are not immediately clear – or we can let them go, and they’ll find someone else willing to see them through. Ignore ideas long enough, and they will stop coming to you.

I used to live a creative life. Or, I suppose as the late Mitch Hedberg might say, “I still do, but I used to, too.”

Growing up, I passed the time by drawing cartoons, usually as a way to entertain my friends. My favorite illustration-based storytellers were Bill Watterson, Gary Larson, Berkeley Breathed, Mike Judge, Matt Groening, and Bill Plympton. I carried around with me a notebook where I’d put what I thought were my best ideas into it, and slowly built up a little catalog of quickly drawn cartoons paired with terrible puns.

I started working at a fast food restaurant the summer before my 16th birthday. Two summers later, I hadn’t saved up much, but managed to convince a co-worker to loan me enough money to purchase a drum set. It took me over a year to pay her back in full, and by the end of that year, I’d started playing drums with other musicians, and pursued that creative path for quite some time after. I played in a lot of different bands, and through the years, I designed stickers and t-shirts and illustrated numerous record covers and show posters.

It was during that time that I purchased the Complete Idiot’s Guide to Creating a Web Page & Blog, and started teaching myself about web development.

In the subsequent years, I built simple static sites for myself and my friends’ bands, as well as my first ever site for a small business. I never pursued the practice as a full-time thing – I enjoyed doing it too much in my free-time over nights and weekends, slowly building up a catalog of knowledge and being able to achieve more and more.

In 2011, I enrolled in an Associate of Applied Science program at my local community college. During that time, I wasn’t actively playing in a band, but I was renting out a practice space near Downtown Minneapolis so I had some place to go to play drums. I bought a desktop computer and put it in that space so that I could also continue to work on my programming skills. I took that time to explore creative writing in the form of poetry and occasional prose, and I did a redesign on this website that included some of that poetry and my illustration.

Two years later, I began my first web development internship. After I graduated in May of that year, I was given the opportunity to work full-time at that same agency and have been generally working in that exact same space ever since: agency WordPress development with a dash of Shopify.

By 2017, my partner and I bought our first home. I had just quit my last band a few months prior, and before we moved, I gave my (second) drum set away to my friend and former bandmate Matt. I felt that I was done playing music, and couldn’t bear the thought of having a drum set just sitting up in storage, and we didn’t have much room for it anyway (not to mention our neighbors probably wouldn’t take terribly kindly to me bashing away at the kit).

From that time until now, the only constant has computer programming. My focus narrowed to primarily back-end development upon joining an agency that worked with larger corporate clients, and as I mentioned in my last post, I’ve felt more or less like I’ve been treading water since then. I still draw, but not seriously. I still make music, but haven’t committed myself to it. I still write code, but it’d been so narrowly focused at work that my hunger for more has largely been dependent on my energy levels at the end of the day and on weekends.

It’s possible only my friends have read about any of this on my blog, since I changed the focus to only the computer programming aspect some time ago. I still intend to keep that focus here, but as of today, and in the spirit of Elizabeth Gilbert and with much thanks to my beloved partner, I am taking active steps to reclaim my time and my creative life.

I am a musician.

I am an illustrator.

I am a poet.

I am a computer programmer.

I am a business owner.

I’m still working on the next phase of my career, but one thing that is clear is that I want to get back to working on interesting projects. I want to help people who are struggling to reach an audience over the internet to build their platforms and give them a voice. I want to build meaningful relationships and empower others to be able to express their own creative voice by creating and assembling the tools that they need to achieve that.

If you’re working on a project or are just getting started with a new idea, and you need technical expertise, I can help. At this time, I’m open to taking on projects involving full website builds, custom plugin or application development, or website upkeep and maintenance. My primary experience centers around WordPress, but if you need help building a Shopify site, or you already have or want to build a web application in another language such as PHP, Python, Node, or Go, I’m most interested in these new challenges and will work with you to help you create your vision on top of these platforms using industry-standard frameworks, practices, and tools.

Interested in working together? Then let’s talk.

Resources

Thanks once again to my wonderful partner Abby for helping me recognize my path back to a creative life, and for all of her love and support over the years.

You can learn more about Big Magic on Elizabeth Gilbert’s website.

If you have a Spotify membership, you can listen hear me play drums via this playlist:
(edit: removed. I canceled my Spotify subscription in favor of Tidal)

Here’s an illustration I posted on this website several years ago, drawn on an iPad:

Here’s an animated GIF I made from photos I took at the Minnesota State Fair in 2013:

Finally, I republished one poem I wrote in 2011, entitled Waiting.

---

I’ve learned this weekend that it doesn’t matter whether any of this is any good. What matters is that I continue to create. I’ll leave it to the rest of you to love, hate, or feel nothing at all about any of it. This time is all we get. Thanks for reading.

When was the last time you’ve sat down and thought about your career? Do you like what you do? Are you getting what you want out of it? Does it challenge you in ways you want to be challenged? Are you thriving, or simply surviving?

I love writing code. If you’ve read this blog for any length of time, you know that I’ve worked primarily in the WordPress space for the last 8 1/2 years, and that I’ve simultaneously kept my feet firmly planted in the broader developer communities. I’ve done this because I feel that it’s important to get a full range of perspectives to inform my craft, and to determine whether there’s something someone is saying from outside of WordPress that could help improve the way we do things within it. I love writing code, and I’m also passionate about software architecture and finding ways to reduce the friction involved in maintaining code. This is a big reason why I’ve focused my attention over the years on concepts like modular development, the five principles of S.O.L.I.D., writing clean code, incoporating testing into your workflow, etc.

I write about these topics here not because I think of myself as an expert in any of them, but because I find them interesting and I think that by discussing the way in which we write code, we can start to consider whether how we write it today is serving us both now and in the future. How difficult is it to change your existing codebase because of some design decision you made in the past, because you didn’t write tests to support it, or because you didn’t document it, or perhaps all three and you’re maintaining a codebase that wasn’t even written by you?

There’s a lot of friction in writing software. In my experience, that friction is lessened over time through coding practices such as code review and pair programming, particularly on small teams, because those are the times in which we can discuss our craft and the current state of our projects, share ideas, and come to consensus about the way in which we want to do things going forward. No two people have the same pool of knowledge, and only by encouraging these practices do teams, over time, grow together to understand the existing state of their codebase and agree upon a vision in which they want it to evolve.

There’s also friction in change. Just think about how passionately people have been opposed to the WordPress block editor! It’s come a long way since it was first released a few years ago, and what I think is most exciting about the project is more willingness to make drastic changes to the way we do things: the chance to try something new and break out of the status quo.

As a fan of PHP, I wish that same mentality transferred to the server-side language. In early 2019, WordPress bumped the minimum required version of PHP from 5.3 to 5.6, and stated as a goal that it was aiming for 7+ as a minimum by the end of that year. Around the same time, there was also some discussion about how we could now, finally, start to incorporate some modern syntax into the core application. Two years later, the same minimum version and much of the ways we write PHP in WordPress remains the same.

Going Forward

All of this is a long way of saying that there is a lot of momentum and focus on JavaScript: not just in WordPress, but everywhere. I need to acknowledge that momentum, accept change myself, and determine what all of this means for me.

At the start of my career, I worked on a broad range of projects, building full sites atop WordPress and Shopify for small businesses and non-profits. I enjoyed this work because it exposed me to a variety of technologies and I was learning something new nearly every day. I collaborated directly with designers and my clients to help meet their visions, and when my projects were finished, I got to launch them for the world to see and use. In fact, just two weekends ago, my partner’s aunt told me that she visited the Glensheen Museum in Duluth, purchasing tickets via the site I built several years ago during my time at a previous agency.

For the last 4 1/2 years, I migrated into plugin development, both at agencies and on the product side. I still learned a lot, and in fact, learned so much from one client in particular that it helped further shape my curiosity and interest in the software development lifecycle and software architecture in general. But, due to the nature of the kinds of projects I worked on, I rarely got to build something that I could celebrate and share with others. I’ve felt further and further isolated from the advancements in WordPress, few of which have come to the language in which I’ve specialized.

I have been only surviving, not thriving.

Last spring, I began studying Python with the goal of landing an engineering role outside of my comfort zone. Interviewing was going really well, but then the pandemic hit, and hiring ceased. This summer, I am continuing my Python exploration, brushing up on Node.js and React, getting better at understanding Docker, digging deeper into CLI scripting, refactoring some existing projects and thinking up new ones. I attended DevOpsDays Minneapolis (online) and was completely in over my head with terminology and concepts I have had virtually no exposure to during my time in WordPress, and I loved every minute of it.

I am motivated to get back to the time when working on projects was delightful; when I could launch something new and show it off to my friends and family. I want to write modern code, to collaborate with my peers, discuss pros and cons of various architectural approaches, and create beautiful, well-tested, and stable applications. And I hope to do so at a company, like so many companies that I have already worked for, who value a positive and supportive engineering culture.

I know I can get there. Perhaps it could be with you? If you or your company is hiring and you think I might be a fit, then I’d love to chat. Please get in touch.

A friend and I were having a really interesting discussion this week about PHP foreach loops, array_* functions, and the subjectivity around code readability; significantly interesting enough, in my view, that I wanted to document it here and share it with my broader network for consideration and discussion.

Let’s say you have an array of options you’ve assigned to a class property:

$this->options = [
    [
        'text => 'Good',
        'value' => 'the-good-one',
    ],
    [
        'text' => 'Better',
        'value' => 'the-better-one',
    ],
    [
        'text' => 'Best',
        'value' => 'the-best-one',
    ],
];

This array gets used in a system to select a default option for the list. The calling code searches within the array to see whether there is a match, and if there is, it returns the value of that match. So, for instance, if I passed the string the-good-one to my search lookup, I would get the-good-one back.

If someone wanted to get the value using the text key, the same behavior applies: I pass in Good, and once again, I get the-good-one back. If, then, I pass in something that’s not located within the array, I simply get back the value I passed in – the-worst-one or Worst would return the-worst-one or Worst, respectively.

You’re assigned with writing a fuction that performs these steps. How do you solve it?

The Loop Approach

One possible algorithm for finding a matching value in this set is to use a loop. It might look something like this:

public function get_matching_option_by_value_or_text( $value ) {
    foreach ( $this->options as $option ) {
        if ( $option['value'] === $value ) {
            return $value;
        }
    }

    foreach ( $this->options as $option ) {
        if ( $option['text'] === $value ) {
            return $option['value'];
        }
    }

    return $value;
}

Loops are one of the first programming control structures that new developers learn, and they can help make solving these kinds of problems easy, but they are not without their tradeoffs. Though simple, this example does contain some inherent complexity, primarily: 1) moderate nesting of control flow, and 2) clear-ish but not necessarily full clarity of developer intent (reading the code, you have to stop and consider why there is a return statement within the loop).

The complexity here is that the main point of the algorithm is to determine if a given value doesn’t exist in the value index, and find the matching value for it if it does exist in a text index.

Let’s look at an alternative using built-in PHP array methods.

The PHP array_* Approach

The same result using a loop control flow can be achieved with two built-in PHP array methods: array_search and array_column. The array_search method returns the index of the found result or false if the result could not be found, and array_column pulls all of the values out of an array into a flat structure, preserving the keys. Let’s take a look:

public function get_matching_option_by_value_or_text( $value ) {
    $value_index = array_search( $value, array_column( $this->options, 'value' ) );

    if ( false !== $value_index ) {
        return $value;
    }

    $text_index = array_search( $value, array_column( $this->options, 'text' ) );

    if ( false !== $text_index ) {
        return $this->options[ $text_index ]['value'];
    }

    return $value;
}

There is both more and less complexity in this approach: more because there are two methods within the algorithm that fewer developers might be familiar with, and because we’re making some nested inline function calls (e.g., calling array_column as the second parameter to array_search). It also has more variable assignments, once because we want to know if we found the index of the value key, and again because we want to know if we found the index of the text key.

That said, at the same time, there is also less complexity, because the control flow is subjectively easier to follow: I simply need to read top to bottom to understand what’s happening, and if I need context around the specific functions being used, I can read the PHP documentation to understand how those functions work. In plain language, I can see “If there is a value index, return the value that matches it from the options. If there is a text index, return the value that matches it from the options. Otherwise, return the value.” The intent behind this approach, I’d argue, is clearer, because any questions that get raised as a result of the algorithm can be reviewed within the documentation, whereas questions about the first approach might need to get answered by running the code and stepping through it with a debugger, or asking the original developer who wrote it.

Programming “The Right Way”

Spoiler alert: there is no “right” way. The beauty of programming is that there are lots of different ways to tackle problems. To me, the most important thing is that when someone is assigned at some future date to modify code you’ve written in the past, how easy is it for them to understand what you’ve written? In my view, it’s easier to follow control flows that have reduced levels of nesting, and which use native language contructs. However, I’m just one person, with one worldview, and one collection of knowledge. Everyone’s technical level and programming approaches differ, so it’s important not to be dogmatic about a particular approach, and appreciate that broader audiences might understand how things work in a different way.

At the end of the day, the one true measure of your algorithms is how many tests are supporting it, so that you can more confidently and easily change it when the tides shift. :)

Addendum

I edited this post after a conversation with another friend, Sal Ferrarello, as I’d realized the original examples for the loop were incorrect. Both the loop and array_search examples have been revised to be the same: returning the $value if it was found in the 'value' index of the original array, otherwise returning the 'value' index if $value was found in the 'text' index. Finally, the methods both return the $value parameter if it was not returned in either search. Thank you, Sal, for noticing the inconsistencies in the original post.

There are, also, notably some limitations with array_column in PHP, which does in fact make the loop example preferable. The array_column method creates a new array from the values, so if any does not contain that index, the indexes of the new array will not match the one of the $options array. Thus, it would seem, once again, that the simpler approach, even with its additional “grok-factor” (because of the early returns in a loop), might in fact be the superior one.

This blog post is more for my own future recollection than anything else, but I figured it might be useful for some of you, too.

If you’re used to working with multiple stages of development (e.g., “local”, “develop”, “staging”, “production”), it’s useful to be able to easily migrate files and data between them. For the longest time, I used a tool called Wordmove to do this (or, to quote Mitch Hedberg, “I still do, but I used to, too”, just not for my own site).

What I simply love about Wordmove is how easily it makes it to move plugins, themes, mu-plugins, and the WordPress database itself between environments. Unfortunately, since I switched to a Composer-based install and moved my WordPress installation into its own directory, Wordmove is no longer an option. I’ve simply dealt with this for the most part by being annoyed by logging into my server, exporting the database, downloading it, then re-importing it on my local.

Fortunately, there’s an easier way.

If you didn’t know already, WP-CLI has a db export command, and I use it all the time. You might not also know that you can set up WP-CLI with a configuration file where you can define login credentials for different environments.

In my local development instance, I now have a wp-cli.yml file that looks like this:

@production:
    ssh: <my-username>@<my-server>/<my-production-wordpress-server-path>

What this allows me to do is run any WP-CLI commands from my local installation against my production installation. Those commands will look something like this:

wp @production post list
wp @production rewrite flush
wp @production db query
wp @production shell

The most important command for this blog post, however, is wp @production db export – I want to get an export of my production database and be able to pull it down into my local instance.

Normally, when you export a database using the wp db export command, it writes a file to the directory from which you called the command, and you can give it a <file> option so that it has whatever filename you choose when you’re done. However, you can also pass a simple “-” option to the command to tell WP-CLI to write to stdout, which is perfectly useful for importing the database locally.

What does this mean? It means that using a combination of WP-CLI commands, I can export my production database directly into my local database, then rewrite the URLs to match my local setup:

wp @production db export - | wp db import - && wp search-replace '//jmichaelward.com' '//my-local-domain'

Voilà!

Update

Thanks to Alain Schlesser for the following recommendation:

Did you notice that the search-replace command actually has an –export flag, so you can use it as a replacement for the db export command?

— Alain Schlesser (@schlessera) June 6, 2021

This means that it’s possible to shorten the above command by excluding the export command altogether and using the --export flag on the production URL.

wp @production search-replace '//jmichaelward.com' '//my-local-domain' --export | wp db import -

I tested this locally and it works great! --export accepts a file name as an option, but if you exclude it, it writes to STDOUT just like wp db export does, so it’s ultimately a combination of the two statements.

Because wp db is such an explicit command, I hadn’t considered that there might have been an export option as part of the search-replace command. It looks like this issue was introduced for discussion and ultimate inclusion into WP-CLI quite some time ago, where it was ultimately decided to include this flag on the search-replace command for performance reasons (plus, it has fewer flags!).

All that said, the only thing that gives me pause about using the above approach is that, if one were in a hurry and forgot to include the --export flag, theyd’d be left with a production database that had the replaced string everywhere. As with anything, there are ways to mitigate this, such as wrapping this command in an alias so one needn’t type it out each time, but knowing my own wariness about doing any modifications to a production database, I may personally continue to use the export -> import -> replace approach. However, the above demonstrates just one of the many powerful aspects of WP-CLI, and whichever approach you use in your own work, hopefully this adds a wonderful new tool to your toolset.