On March 9th, we held our 3rd Genesis Shapers Slack meeting. As a reminder, These meetings are a great opportunity for folks to share their thoughts and ideas about Genesis. You can read the recaps of the January and February meetings.
The Genesis Shapers are a hand-selected and diverse group of people representing companies from across the community who have come together to be a representative voice in the strategic direction of Genesis in addition to the feedback we receive directly from customers, across social channels, and through Genesis WP on Slack.
Included in this group are:
Bill Erickson, Carrie Dils, Gary Jones, Greg Boser, Jennifer Bourn, Jon Brown, Jonathan Jeter, Lauren Gaige, Lee Anthony, Mike Hemberger, Robin Cornett, Sara Dunn, Sridhar Katakam, and Tonya Mork.
In the Shapers meeting earlier this month, we discussed some technical elements of Genesis, from local dev environments to regression testing to code snippets.
David Vogelpohl, the Vice President of Web Strategy at WP Engine and StudioPress brand lead, facilitated the conversation, and here was the meeting agenda:
- What local development environments do you think most Genesis developers use (if at all) and why?
- What role do you see regression testing playing in the Genesis context? What tests or testing approaches should people be using?
- Do you think learning advanced dev techniques like WP Engine’s LocalDev & regression testing will actually help Genesis developers in ways that help them grow?
- What Genesis Code Snippet libraries are the most useful? StudioPress’ snippets? Genesis.community snippets? Other?
- Do you think it would be valuable to let people contribute snippets to a public repo which is curated and available for all to use?
Local Development Environments
David Vogelpohl kicked off the meeting by asking the Shapers what development environments they use. Mike Hemberger jumped right in:
“In just this Slack group we have Valet, Valet+, Lando, Local by Flywheel, DesktopServer, MAMP, and probably more.”
Jon Brown echoed what Mike said, with a few additions:
“Local by Flywheel and Desktop Server. I’d be willing to bet more than 95% of genesis devs use one of those two. A few percent use MAMP and the rest a various collection of things from VVV to Valet to Lando to Chasis to whatever.”
Personally, I use MAMP, but as Jon pointed out, I am probably in the minority. I don’t do local development often since I’m typically not working without WIFI connection or on sites that can’t be live.
Representing DesktopServer was Lauren Gaige and Laragon was Robin Cornett.
Carrie Dils mentioned this, which also brought about its own thread of back and forths:
“I’d suspect most are using a GUI dev environment like DesktopServer or Local.”
David followed up by asking:
“Why do you all think devs are making those choices? Anything specifically beneficial to Genesis developers as a group (e.g. Carrie’s points on GUI)?”
Tonya Mork explained why she uses local dev:
“Why? Because it lets you quickly spin up and gets out of your way. You can then focus all of your energies on developing instead of messing around with tooling.”
Tonya went on to say:
“What I prefer about Local vs. DS is I can quickly switch the environment through the GUI for each site. A couple of clicks and I can change it from PHP 5.3 to 5.6 to 7.2. That helps me to run the tests and ensure compatibility locally with different environments.”
Before we moved on to the next topic, John Parris from our team said:
“I use Local too. Quick PHP/MySQL version changes is very handy. Site cloning. Blueprints. ngrok integration. Auto-populating creds for Sequel Pro. Mailhog. Easy SSL cert trusting. It basically does everything I need in my day to day work.”
From the conversation we had around local development environments, it’s clear to me that developers do in fact rely on them. Of course, like any software, a variety of sources is well represented, and more than like different folks use different tools for different reasons.
Regression Testing with Genesis
David moved us to the next topic by asking:
“What role do you see regression testing playing in the Genesis context? What tests or testing approaches should people be using?”
I stood as a bystander in this conversation because I don’t fully understand what (and how) regression testing works, but the conversation was definitely interesting.
For those like me who needed an explanation, Carrie provided us a link. (Grins.)
Jon offered his opinion on the matter:
“Sounds fancy but we’ve never found automated/unit/regression testing of themes to be practical.”
To which Nathan Rice brought up the concept of “linting” and “code standards”:
“Linting … making sure that your code isn’t broken syntactically. Code standards … making sure the code adheres to the WP standards. it absolutely can. if a test that was previously passing suddenly fails, it’s (at the very least) a red flag.”
And I love what Bill Erickson added here:
“WPEngines checks when you `git push` have saved me a few times.”
There wasn’t a whole lot more to the discussion around regression testing, which paved the way to the bigger topic at hand.
Genesis Code Snippet Libraries
Ok, time for the can of worms. David led this part of the meeting with this:
“What Genesis Code Snippet libraries are the most useful? StudioPress’ snippets? Genesis.community snippets? Other?”
This was easily the bulk of our meeting, as I suspected it would be. As the provider of many Genesis Code Snippets, I was very interested to hear what the Shapers thought about the topic.
Lauren shared her process, which I think many folks in the Genesis community would concur:
“I generally start at Sridhar’s site and if I can’t find it there I Google.”
Jason Cohen, CTO of WP Engine said it best:
“Sridhar—the new home page on the Internet.”
Sara Dunn quickly chimed in:
“I literally will not go to someone’s snippets and look through them to find what I want. I think many people just Google. I want tutorials, not snippets.”
Most of the snippets I publish for others to use are short, very basic ones. What Sara is suggesting is that context—or specific use case—of code snippets is far more valuable.
Jon echoed that as well:
“I value ‘blog posts with snippets’ far more than ‘snippet’ out of context… that said I’ve been known to troll through Bill’s gists and find gold on occasion.”
I think that snippets within tutorials are more prime for a less experienced user, and normal code snippets (without context) are for someone who knows they want to do something just need to remember how to do it.
Tonya added:
“I tend to get a lot of people asking me how to adapt a snippet for their specific needs. One-size-fits-all snippets don’t fit all use cases. Tutorials help when there’s an explanation of why it does what it does and a customization strategy.”
And Robin expressed:
“For those of us who want to know why something works, context, comments, explanations are great–but in supporting plugins, I’m finding that people don’t really want to know why, and often aren’t willing to bang on things to tweak them.”
David recapped this part of the discussion:
“So to recap these thoughts… Snippets are good, some collections better than others (@sridharkatakam is the best), and snippets are also a learning tool best paired with tutorials / documentation?“
I think he is spot on with his assessment, by the way.
The conversation around code snippets moved into the idea of repositories—where to host them, who should host them, and the importance of keeping them updated. The idea of a central repository is daunting for many reasons.
Mike pointed out the obvious:
“Managing would be crazy. 10 different versions of similar snippets, all with various coding standards/styles.”
And Carrie brought some valuable insight to the ramifications of a central repository:
“I do wonder, however, if a public repo like that would take away from the visibility of people like Sridhar who earn a living from their tutorials/snippets.”
I love her heart for the community, and this is something that I also think is true.
While I understand the need for sharing code snippets within the community, there are also a few things to consider. In addition to the code quality, they would have to be monitored/updated as new iterations of Genesis come out.
To which Robin dropped the mic with this:
“Especially if 3.0 changes all the things.”
Helping Genesis Developers Grow
David brought us home for the last portion of the meeting by asking this:
“Do you think learning advanced dev techniques like LocalDev & regression testing will actually help Genesis developers in ways that help them grow?”
Carried kicked off the responses:
“Grow? Sure. But the money in streamlining processes for more effective and efficient development, which in turn increases margin on projects. My customers don’t care how I get it done. What matters to me is how much time it takes me to deliver. The more effective and streamlined I am, the bigger my margin.”
Robin chimed in:
”I think it depends on whether you’re talking about developers who build one off sites or who are producing something for the masses. one off, not so much, I would think–a lot of times the goal is to just ship it.”
Bill finished up the trifecta with:
“None of my clients care about my dev tools. They just want a high quality product delivered quickly and affordably.”
In my opinion, these responses sum up what I have experienced over the years leading StudioPress: A customer wants a beautiful website, and if they hire someone to design/develop it, they worry less about the “how it gets done” and more about “what it looks like and how easy it is to use.”
And that’s a great spot to end the recap of the March Genesis Shapers meeting.
As I’ve said before, it’s an exciting time to be in the WordPress space. By focusing on the development of Genesis and suite of tools that extend it further, I feel confident that our team will be able to keep pace and continue to provide the best digital experience possible for our customers.