Get To Know Peter Chester
Peter is a partner at Modern Tribe, the digital agency responsible for The Events Calendar and Image Widget WordPress plugins as well as for large scale WordPress builds including Harvard Law, Stanford Law and Steelcase.com. Peter often leads large technical projects with budgets in excess of $500k. Peter is also a father, musician, artist, surfer and list maker with an obsession for google spreadsheet formulas (though not necessarily in that order).
We’re thrilled Peter will be sharing his knowledge with us by speaking about coding with a team at WordCamp Sacramento 2015.
Speaker Q&A
How is coding with a team different than doing it solo? Why do practices need to adjust?
Solo coding is fast, nimble, and lawless. You can do what you want. And that is a ton of fun until you reach a certain level of complexity or until the project gets too big for you.
Actually, it’s even a little more sinister than that because your future self is in effect your coding partner. So even if you aren’t working with a team, if you don’t employ good coding practices to support sharing your code, you will likely encounter your own code in a year and find yourself completely perplexed as to what you were thinking as you built this bloated birds nest.
One way of thinking about this is that Code is not just for computers. It is for people. Code is a language for humans to communicate with each other which is then translated for computers. If it were up to a computer, we would simply write in 1’s and 0’s.
There are many ways to achieve the same functional effect. The question then is, which solution is the most easily understood by another developer, or by yourself in 3 years?
The journey starts with scope, architecture and coding practices. Before you code anything, it’s important to have a clear understanding of what the feature is that you are building and to have that relatively well documented. If you have a solid understanding of the scope, you are more likely to be able to land on a well thought out architecture. And when you get to writing it all out, that’s when coding practices take effect. Code should be easily readable without documentation (honestly, I don’t understand why people go to the WordPress Codex when all the info is in the source code). That is, class names, file names, function names, variable names, and the manner in which these elements interact should be pretty obvious just be scanning the code.
I am not an expert at test driven development (TDD). However, one of my colleagues, Luca Tumedei, has frequently demonstrated how TDD inherently leads to readable code and because it is by definition test driven, it is obviously suffers fewer bugs.
Next we need a vehicle for sharing code. That is version control (GIT). At this point, I never work on any code unless it is in version control. Even if it’s just for my own purposes. Version control allows people, including your future self, to inspect the history of the code and to quickly share it between computers. If you don’t have your code in source control, you are left with emailing or FTPing as a means for sharing. But then the minute the code is edited, all the other copies of it are out of sync. This quickly leads to severe confusion.
If you do have the luxury of working with a team, then there are a number of other processes that are worth leveraging including architecture review, code reviews and quality assurance reviews. These will at a minimum help ensure that the code you release is less likely to break. However, you can also look at these processes as opportunities for growth.
Reviewing someone’s architecture or code or having yours reviewed is an opportunity to learn about where you can grow and to see through someone else’s eyes. We often go about solving the same problem in very different ways.
All in all, coding with a team is all about carefully articulated clear communication. It takes time. It takes effort. But it leads to a sustainable coding practice and to a more joyful experience for everyone.
What is your experience coding with a team?
I started coding in Perl about 20 years ago. I didn’t read any books about architecture or best practices. I just read other people’s code (for better or worse) and looked for the most efficient ways to achieve my coding goals.
Naturally, every time I encountered any of my larger projects after a year or more of not working on it, I would find that what once seemed clear as day to me now looked like a soupy tangled mess. Not to mention the embarrassment of then sharing that code with other people later.
One of the things that drew me to WordPress was the way that the code walked the line between complexity and simplicity. In many cases I could dive into the code without reading any documentation and without having a CS degree and quickly and easily pick it up.
The WordPress community has been maturing. The code and the tools that we author are getting more complicated. We often don’t write CSS, we write LESS or SASS. WordPress core hasn’t adopted either officially but I wouldn’t be surprised if we did some time soon. I increasingly find Grunt and/or Composer prerequisites for WordPress projects. WordPress core employs a test suite. Beyond the tools, I’ve seen increasing usage of abstractions and advanced OOP architectures in the WordPress community.
In our own projects at Modern Tribe, we are employing most if not all of these tools and practices. The net result is this: A couple years ago, as a strategist / project lead, if I saw an error in the php or in the css of one of our projects, I might just crack open the code, fix it, and commit the change. Today, I can’t really do that without first making sure that I have my SASS compiler updated, running and pointing the right project, that I’ve got Grunt updated and that I have composer updated and that I’ve run it recently on the project, etc. At that point it’s easier for me to just ask one of the devs on the team to handle it.
The sum total of our efficiencies have produced an environment where regular contributors can move more quickly and efficiently and sporadic ones are better off communicating their needs.
At this point, the truth is that my experience coding with a team has evolved from solo coder, to coding with a team, to leading a team of coders where I no longer author code, I facilitate communication.
How did you get started with WordPress? Why WordPress?
I had been building custom CMS tools up until I bumped into WordPress in 2005. It was love at first wp-admin. I immediately became obsessed with how easily it could be customized, hacked, hooked and filtered. More importantly, my customers immediately became enamored by the simplicity of the administrative experience.
What is your favorite thing about WordPress?
The community. The code is cool (or in some cases not so cool). But the community is what makes the project great.
Can you share a couple WordPress plugins that you love or recommend?
Obviously, I’m a huge fan of our own plugins, especially The Events Calendar. But just for fun, let’s talk about some other plugins.
10up’s TinyMCE Table Buttons is a fantastic plugin! It’s one of those that I sort of wish was just part of WordPress. Though, I’ll admit that there are times, especially on account of responsiveness, that I would want to deactivate it (Tables are not trivial to handle responsively). It really is a fabulous utility for adding tables to your WYSIWYG.
Casey Bisson and Zach Tirrell’s New Relic plugin is one of those lesser known but really useful plugins. The thing is, when you sign up for New Relic, as we do on all our projects, New Relic simply sees a ‘PHP Application’ and doesn’t know how to separate frontend, backend and cron requests. This plugin takes a shot at addressing that for you. It does a great job except it can not intercept when php caching occurs so you also end up with a separate report of cached responses. In any case, we now use this on all our projects.
Resources or recommendations?
1. Use version control (GIT) so that you can share your code, revisit the history of your code and just to make the world a better place for all of us.
2. Write for people. Don’t write to use the least number of lines or the least number of characters. Name things carefully and organize things clearly. Your code should be readable to some extent even by a non-coder.
3. Take the time to do code reviews. You will learn. Your team will learn. There will be less bugs.
Check Out The Speakers
WordCamp Sacramento 2015 is bringing you an awesome line up of speakers from not only our greater Sacramento region, but throughout California and beyond. Check out our speakers page to see the 2015 WordCamp Sacramento Speakers, and be sure to follow them on Twitter.