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.

The Never-Ending Quest for Improvement

Well, here were are again – August. The time of year when summer is winding down, and everyone is racing to soak in the last of the abundant sunshine before our too-short autumn passes and winter takes hold.

I, for one, couldn’t be more delighted. Fall and winter to me means board games, obsessing over recorded music, and for the past few years, digging deep into personal coding projects and doing everything I can to further improve my skills as a programmer. Thus far, 2015 has been a challenging year, filled with client projects that come complete with a steep learning curve, and on a tight budget. All things considered, though, I feel that I’ve come out from each one a more skilled and seasoned developer. I’m starting to discover better tools to use to improve my workflow, notice inefficiencies in my code, learn more from my mistakes, and overall, make better decisions when it comes to planning the websites and applications I build for my clients. At this point in my career, I’m beginning to realize more clearly the long-term professional path I want to take and the kind of work I get more enjoyment out of doing. That’s exciting, and I’m hoping that means I can continue to take on projects that move me in that direction, because for the first time since I completed my college program just over two years ago, I’m starting to feel like I “get it.”

I’ve been very active in the developer community over the past year. I helped co-organize the 3rd Annual Midwest PHP Conference held in Minneapolis in March, and I’ve had the privilege to attend to additional PHP conferences in that time (Madison PHP in September ’14 and Lonestar PHP in Dallas in April ’15). In addition, I’ve attended two Prestige Conferences, WordCamp Minneapolis, and numerous developer meetups for the PHP, WordPress, and JavaScript communities. I went to my first MinneDemo this spring, my first MinneBar shortly after. Last weekend, my employer hosted the 1st anniversary party for the Minneapolis chapter of Girl Develop It, an event I was proud to have been involved with. And, next month, I’ll be attending the first-ever Pacific Northwest PHP Conference, at the tail end of an 8-night stay in Seattle, WA.

To say I’ve gotten out of the house this year has been a bit of an understatement. One of my professional goals for 2015 was to attend 12 industry-related events, and as of August 2nd, I’ve gone to 14 (with at least three on the docket thus far). I also aimed to speak at one event, which I achieved when I gave my first professional presentation ever at the MNPHP User Group two weeks ago (about Getting Started With Xdebug). I’ve started work on four separate WordPress plugins this year, at least two of which should be completed by year’s end. And I’ve set out to learn at least four new tools/languages/utilities, and I’ve since been exposed to a plethora of them (most recently Wordmove, which is a great Capistrano-inspired utility for deploying WordPress installations across different development environments, but also I’ve looked into and worked with many others, including learning how to write a cURL request, using Bower for installing front-end libraries, digging deeper into all of the features Xdebug and Composer provide, getting up and running with PHP CodeSniffer for validating how my code aligns with established standards, learning the WordPress Customizer, Settings, and Dashboard widget APIs, and getting a small module set up for a client site using AngularJS).

Some days, it feels like drinking from the firehose trying to learn all of this stuff. I don’t envy at all new developers who are interested in the craft but don’t know where to begin, because the amount of information there is to know even now feels daunting. But, as I complete various tutorials, or figure out how to integrate some new library into a client’s site, there comes a certain kind of validation that I’ve chosen the right path for me. I enjoy tinkering and putting something together, learning how to connect disparate code libraries developed by people who likely never suspected their software would have a shared synergy, and making something completely new to meet someone’s need for software.

I’m approaching 2 1/2 years of doing this full-time, and the amount of stuff I’ve managed to cram in my head in that short amount of time amazes even me. I can’t wait to see where I’m at just a few years from now. The never-ending quest for improvement of one’s skill set is never more satisfying than once you’ve finally found your place. I can only hope to become the kind of developer I want to be in the time I have.