Some Things I Should Have Said, Vol. II

An Anniversary

This past May, I celebrated five years of working full-time as a web developer. When I first started getting paid to write code, I remember looking forward to a point at some time in the future where I would have a base level of knowledge I could leverage when working on new projects. Five years later, I believe I’ve accomplished that goal, but in that time, I’ve also come to accept that there’s just so much still to learn (and that it will always be this way).

There’s a certain peace that comes with that understanding. Today, when I take on client projects, I may not always know how the work will be done, but I at least have some ideas about where to begin, how it will need to be structured, what kind of functionality I’ll have to write from scratch, what can be imported from elsewhere, where to find the right documentation when I have questions, who to ask when I’m completely stuck, and when to extract something into a library so I don’t have to write the same thing over again later.

It’s been a long, often frustrating journey, but after all this time, I’m more certain than ever that I’ve chosen the right career path. I love writing code, building something out of nothing, and delivering functionality that helps others make their own jobs a little bit easier.

Areas of Interest

In progress game of Century: Golem Edition

Over the past year, and particularly since seeing Chris Tankersley‘s talk about shell scripting at Midwest PHP in March, I have become increasingly interested in developer tooling. I’ve been digging a bunch into Bash scripting, the Symfony Console Component, delivering custom utilities via Composer, and trying to figure out ways I can use my knowledge to create useful tools I can pull into projects to make them more enjoyable to work on. It’s really opened my eyes to all of the possibilities that are out there, and I’m looking forward to seeing what sorts of things I’ll learn over the next five years and where it takes my career.

In addition to the command line, I have become increasingly interested what’s happening in the JavaScript communities, particularly with package development and frontend templating. Because I play a lot of board games in my spare time, I developed a small webapp a couple of years ago to log player scores when pen and paper are neither available nor practical. Recently, I’ve begun refactoring that app on top of React, which has helped scratch the itch for frontend work a bit. I registered a new domain for my blog, too, so that I can separate my more personal writings from the blog here, with the longer-term plan of rewriting this site in Laravel so I get some broader PHP framework exposure.

All in all, it’s been an exciting time for me!

Events and Happenings

While I’m posting, I’ve got quite a few things to look forward to in the coming months that I should probably talk about here. But first, something from the past! On the chance you missed it, I participated in the All About WordPress episode of the PHP Roundtable podcast in May. Tessa Kriesel (Pantheon), David Hayes (WP Shout), Jenny Wong (Human Made), Adam Silverstein and Ryan Welch (10up) all participated in the panel, where we talked about the sorts of things that are top-of-mind for WordPress developers (*cough*Gutenberg*cough*).

That was only my second time participating in a podcast, but I’ll be getting another opportunity on July 24th, when I join my WebDevStudios colleague John Hawkins on an episode of the HawkTalk Podcast. John and I will be talking about board games, hockey, development work, and anything else that comes to mind.

Though I won’t be presenting, I am also looking forward to attending the inaugural PHP Detroit conference in Livonia, MI on July 26-28. The two-track schedule looks very good, with at least one topic of interest to me during every time slot. I haven’t spent any time in Michigan since my music touring days, so it’ll be fun to hang out there for a couple of days.

Lastly, I have been accepted to speak this year at WordCamp Minneapolis-St. Paul for my second time ever. The conference coincides with the Minnesota State Fair, so attendees from outside of the state will get a chance to check out the Great Minnesota Get-Together first-hand. My talk – Modernizing Your Development Workflow Using Composer – will cover the basics of getting started with the Composer command line tool, with an emphasis on using it for WordPress development and the benefits and caveats that go along with it.

Then Comes Dudley

In the process of building custom WordPress themes for various clients over the past few years, I slowly came to realize just how much boilerplate plumbing I’d been doing from project to project. A theme calls for a big hero image with a catchy headline and an intriguing call to action? Make it so. How about an image carousel with options to adjust the delay between frames? Or maybe an list of frequently asked questions, expandable one-by-one until a potential customer has had every single possible question they could think of clarified and addressed?

One of the key tenets of programming is “don’t repeat yourself”, and about a year ago, it finally dawned on me just how much I was. From project to project, I was writing markup for the same exact modules I’d written before, and hooking it all up to the WordPress backend. At that time, I was determined to approach my projects differently; to start cataloging the instances where I was building something I’d built before, and to actually do something with that information, to make something I could reuse instead of reimplement.

In that time, I began to develop a patterns library of sorts, one that worked with the Advanced Custom Fields plugin for WordPress. I approached each new project I took on with my patterns library in mind, and looked for opportunities to improve upon it. I didn’t just want my modules to be reusable, but I wanted them to be extensible, and I wanted to provide anyone who might use it themselves with the ability to work within that framework; to write their own custom modules that they too could reuse and share.

Inspired after attending the final Lone Star PHP conference in Dallas this past April, I decided to brand my work and release it to the wild: Dudley, named after Dudley Heinsbergen, the character from one of my favorite movies, The Royal Tenenbaums. Dudley is a WordPress plugin for developers that allows them to reuse, modify, or write custom, project-specific web components for any WordPress theme. It’s my first real open-source project, and my hope is that, over time, other developers will give it a try, provide feedback about what works or doesn’t work for them, open issues about bugs they find, and otherwise help me understand if what I’ve been thinking about helps them meet a need for some of their most common theming problems. It’s one of the first things I’ve worked on as a web developer that I truly feel proud of. Dudley isn’t without its shortcomings – I’m definitely aware that it began as a tool meant for me and me alone, and I need to make some updates to it to truly open it up to everyone – but I’m excited about where I’ve managed to bring it so far, and I’m hoping that, over time, it will become a tool that other people can incorporate into their projects, as well.

Today, as part of my Five for the Future Day at WebDevStudios, I spent a few hours writing some custom WP-CLI commands for quickly scaffolding some boilerplate files for Dudley. It undoubtedly will need some improvements, but I’m so incredibly thankful for the opportunity to spend some more time improving something that has truly been a labor of love. I hope, with time, others will give it a try and find something to love about it, too.

On Working Remotely

I have been working remotely for nearly 15 months, almost as long as it’s been since I last wrote in this blog. For many who commute five days a week to their employer’s office, working from home sounds like a dream. In a lot of ways, it is. Once you do the math, you realize just how many hours of your life you spend sitting in traffic on your way to and from work, and you perhaps start to think of ways in which you can prevent that from needing to happen.

Many years ago, when I worked in an office in Downtown Minneapolis, I switched to a four-day per week flex schedule: four 10-hour days, three days off. The long weekends were nice; the long workdays, slightly less so. I drove less in rush hour traffic (especially since I would leave two hours later in the day than usual), but I also ended up having far less time to interact with my co-workers. Eventually, I switched back to a regular 9-5 schedule, as being present at the hours when my co-workers were actually in the office and not having to catch up every week and what I missed on that fifth day was more important to me than saving some time on the road.

Lesson learned: I am a social being. I like building relationships with others. I value camaraderie, partnership, and collaboration. I want to be at the table when decisions are made. I want to be present. Traffic is a reasonable exchange for these things.

And, on that note, beginning a career in web development four years ago has been one of the most rewarding and personally challenging decisions I’ve ever made. I absolutely love the work I do. When the problems are hard and I feel like there’s no way I’ll ever figure out how to solve them, and then I do? There are few better feelings in the world.

At the same time, the work can be extremely isolating. In these four years, projects have often been handed off to me once the design phase is completed and the expectation has been that I’ve got things from there. And I have! Hopefully I’ve served my clients well, and have guided their projects skillfully along the full path from local environment setup to deployment, like a true “full-stack” developer. I’m proud of most of the sites I’ve built. The ones I’m less thrilled with were usually due to budget restrictions combined with the requirement that I wear all the hats.

Working remotely can double down on that feeling of isolation. It’s not for everyone. Thankfully, just as I realized I needed to make a change when a four-day week of 10-hour days wasn’t working for me, I understood that I needed to make a change here, as well. As much as I love working on the web, I don’t enjoy the whole process. And, more importantly, I still crave collaboration and interaction; the opportunity to work on projects as part of a team, not just on my own.

Four weeks ago, I began working as a Backend Developer at WebDevStudios. We are a fully-distributed company, which means that every one of our project managers, designers, product managers, and developers works from home. And we work together on big, big projects. When I write code, it’s primarily in a language I enjoy (PHP), and one or more of my colleagues reviews it to make sure it’s up to snuff so that we can deploy with confidence. We discuss potential ways to tackle a problem, we assign tasks, and then we work together to get them done. It’s completely unlike anything I’ve experienced since becoming a developer four years ago, and I’m already hooked.

2016: Better Late Than Never

Oh, hey.

I launched a little redesign of this site at the end of 2015, placing my blog front-and-center with the idea that I’d suddenly catch writing fever and generate all sorts of content. It’s mid-March, so I guess we’ll call that little experiment a failure. 2016 goal: do better.

A lot has been happening, too. Most significantly, I accepted a WordPress Developer role with 3five, and since February 1st, I’ve been working remotely from my little home office. In the short time that I’ve been there, I’ve been getting up to speed on modernized deployment stacks and development tools, racing through a couple of quick turnaround client projects, adapting to remote life (and sharpening my electronic interpersonal skills), and trying to figure out ways to improve our internal processes. It’s great working for a company where my input is not only valued, but also solicited, and I’m feeling optimistic about our potential to achieve great things.

In related news, last month I applied to speak at WordCamp Minneapolis, which will be held from May 20-22, and I’m excited to announce that my proposal was accepted! The title of my talk is “Good, Fast, and Cheap: How Modular Design Improves Our Projects”. This is my first time speaking at WordCamp, and also my first time speaking in an official capacity at a conference (I previously gave a talk, “Getting Started With Xdebug”, at the Pacific Northwest PHP Conference Uncon track in September, and also to some local user groups), so I’m thrilled to have the opportunity. I’m working on my slides now, but some general concepts I want to touch on include: Atomic Web Design, why companies should agree upon an ubiquitous language, how patterns libraries can streamline development, and how this all comes together for a team focused on WordPress development. Anyone who has worked with me in the past has heard me evangelize the importance of designing reusable components for website development, so I’m hoping I’m able to distill this information down into a helpful and meaningful 45-minute presentation.

And…well, there’s more, but I’ve got a friend stopping by to play some board games any minute now, so that will have to wait until another time. Better to publish than to wait until all of my thoughts are compiled in one place.

Until next time…

Assessing One’s Own Skill Set

Some backstory to this post

I’m in the process of redesigning this website to put more focus on my web development capabilities, highlight some projects I’ve worked on, and otherwise showcase just how much I’ve learned since earning my computer programming degree a mere two and a half years ago. Before enrolling in an academic program, I’d been building static websites since the summer of 2003, when I first purchased “The Complete Idiot’s Guide to Building Your Own Web Page”, but I’d never gone beyond basic HTML and CSS. In college, I reinforced my knowledge of my base skills, and had additionally been exposed to a broad set of languages and platforms. My homework involved writing code in PHP, JavaScript, Python, C++, Java (and JSP), and MySQL, as well as exploring data structures concepts, learning about orders of magnitude, reading up on how machine languages work, doing binary math, and more. I also took a class on computer networking, so I gained some knowledge about using the command line in Linux, and configuring workstations in Windows.

For the most part, college was great for introducing me to some basic concepts and help me discover in general what it is I wanted to do, but didn’t fully prepare me for the realities of what it’s like to work as a professional developer. If you were to ask anyone in any field about their own college experiences, they would likely tell you the same thing – they probably got some basic building blocks, but once thrown into real work, the landscape changes dramatically.

Sure, I learned some basic terminal commands in college, but we never talked about version control. I didn’t learn how to configure a virtual machine. I’d never used a pre-processor to compile my stylesheets. Aside from jQuery, we didn’t really discuss how or why to use third-party libraries. We used phpMyAdmin and MySQL WorkBench as GUIs for interacting with a MySQL database, but students were never really introduced to alternatives, or shown that, “Hey! You can use this desktop software to talk to a remote server, not just the one installed on your local machine.” Although they existed, we didn’t talk about taskrunners like Grunt, or about the need to minimize HTTP requests and the importance of compressing your JavaScript and CSS files. Heck, we didn’t even talk about REST or how to communicate with an API.

This is all knowledge one starts to glean on their own once they’re finally given a real project and tasked with figuring out how to convert it from a conceptual idea into a working piece of software.

This Weekend

Okay, so fast-forward to this weekend, or rather, a week and a half ago. PHP 7 was finally released, and I decided I wanted to upgrade this site to the current version primarily so I can take advantage of its increased performance. This weekend, I decided, “Well, I’m running PHP 7 online, I may as well install it locally so that I can start writing my code in PHP 7, too. I can use scalar type hints! I can define return types! And heck, I’ll start using short array syntax, even though it was introduced three versions ago. It’s my site, so I know what technology I’m running on. I’LL DO WHAT I WANT!”

That was all well and good, before I realized that I don’t really know *how* to install PHP. Do I just do it over OS X’s pre-installed version? Nah, that’s probably a bad idea. Can I upgrade my VVV box? Also probably a bad idea – I might still have some freelance client sites on there that still need PHP 5.5. I decided to download Rasmus Lerdorf’s Vagrant box on Github. The instructions in his README file are good enough to get up and running, and I know enough about MySQL and Apache/Nginx to get my environment set up. Or so I thought. Sure, I got the site up and running, but once I started working on my new theme, I realized my CSS changes weren’t propagating.

I won’t bore you with the details (assuming you’re not bored already if you’ve read this far), but needless to say, my CSS files were being served by Nginx, which meant they were getting cached. A few hours of searching on Google, and I eventually learned there’s a setting called sendfile that you can set to off, and suddenly, everything was updating normally.

Today, I intended to set up a development domain so I could push my local changes to my remote server and test it on a real environment before I push everything live. I’m not on a managed host, so this poses additional challenges, because, although I’ve deployed many client sites in the past two and a half years, I still wouldn’t consider myself a DNS expert, and my aforementioned skills in Apache and Nginx are passing, but not proficient. I messed it up. This site briefly showed “Hello World” because of my misconfiguration. I reverted everything, and vowed to tackle it another time.

I’ll get there, eventually, by the new year, for sure, but I think I’ve had enough server configuration and administration lessons for one weekend.

The Point of All This

I hear all the time from new developers or people looking into learning the craft that they’re not sure about their own path for learning. I understand where they’re coming from – it’s incredibly hard to decipher what’s meaningful knowledge that will push you forward in your career, and what’s just an interesting side-attraction that’s fun to play with but doesn’t provide any actual value. You learn by doing; you learn from your mistakes, by trial and error.

But that’s not all. You also learn by deciding what to learn, by choosing something specific and deciding to learn it as thoroughly as you can. And you learn by talking to other developers in the community, discussing what tools they use in their day-to-day work, and finding out what skills they need to get their projects done. And lastly, you explore, because there is no one right way, and because having a curiosity about other solutions, other tools, and other libraries that solve a specific problem is the best way to advance your skill set.

My immediate goal for the end of the year is to get my new theme launched. Once I have, it will be running the latest version of WordPress, on the latest version of PHP, and I know I will have learned a lot about servers in the meantime. From there, I need to bolster my JavaScript knowledge, because WordPress is moving in that direction. I also need to learn another framework, because I might want to work on projects that don’t involve WordPress at all. I need to learn more about system architecture, because longer-term, I would like to do more server-side work and develop well-structured systems. This means that I need to know more about caching, and routing, and service-oriented architecture, and how to build an API, and…well, the list goes on and on.

Most importantly, it means that I need to make a significant effort to find a mentor – or several – who can help guide me on this path. Sure, it’s possible I can do this all on my own, but having a mentor means I can have a sounding board for voicing ideas, questions, and concerns, and more importantly, I can gain validation that the decisions I’m making when developing software are well-informed ones.

There’s no right way to learn. But, evaluating your own skill set, celebrating your past achievements, and determining a path for the future can go a long way toward establishing a focus. And nothing helps one learn like focus.