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.

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…

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.

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.

 

 

Talking about setting goals isn’t the same as the actual setting of those goals, but allow me to venture down that path briefly.

For me, 2014 was lousy in terms of achieving goals. At the start of the year, I had set forth to achieve the following items:

• Complete the Spanish track on Duolingo.com
• Read 24 books
• Give a presentation at a programming meetup
• Work with Jonathan Sundquist to plan the Midwest PHP 2015 Conference
• Build and launch a web application using OOP principles
• Build a WordPress plugin
• Play a show with my new band
• Record a new album
• Create frame-able artwork on paper (any amount – even just one!)
• Eat more fruits and vegetables and fewer meats

Now, my new band played two shows this summer, and we recorded a demo in June; and I built the website for the Midwest PHP 2015 Conference, and read through 331 submitted talks to select just 32 for the event. Aside from those, though, I was pretty light on the completion scale of things – the Spanish track sits unfinished; as of today, I’ve completed just 7 books in 2014; I’ve drawn some, but nothing on paper; and…well, you get the point.

The point here isn’t to hem and haw about the things I didn’t accomplish. In fact, I accomplished some great things I didn’t set out to do in January of last year, like greatly reducing my debts, taking on my first freelance projects, and assembling a weekly gathering of programmers to work on personal projects (alas, since disbanded). The point is that life happens, often in ways one doesn’t expect, and yet it’s still important to take stock of where we’ve been so that we can move forward with purpose.

I’m beginning to draft goals for the new year, and have already submitted several to my boss that I’d like to achieve in a professional capacity in 2015. Some of those are modifications of unachieved items from this list (speaking at a meetup; building a WordPress plugin and/or web application using OOP principles). As I’m reviewing last year’s list and evaluating where I’d like to be twelve months from now, I’m reminded of the importance of setting goals that are measurable and attainable. ‘Read 24 books’, sure – that’s two per month, and in 2013, I read 39. ‘Create frame-able artwork on paper’ – that’s a bit more obscure. Who determines whether it’s frame-able? I could scribble on a sheet of paper, buy a frame for it, and hang it on the wall like I’m the next coming of Picasso, but that doesn’t make it art, does it?

It’s important to have goals. It’s more important not to use your unachieved goals against you, because you can take stock and determine whether that goal was actually worthwhile to yourself to achieve. If it was, give it another go next year. However, what’s most important is to make sure that your goals are measurable, or you’ll never know whether you achieved them at all.