I used to pretty much listen to classic rock and punk rock, but I’ve really branched out the older I’ve gotten. If I’m going to be binging for a couple of hours and I need to be heads down on what I’m working on, I usually queue up movie soundtracks or ambient playlists.
Anything without lyrics and things and things that tend to be epic in nature tend to be the things I listen to when I’m working on a larger task.
When I’m plowing through smaller tasks or something that doesn’t require as much focus, I’m more likely to be listening anything from, again, rock and roll (anything from classic to punk or hard rock) to motown and even old school country.
It’s fair - there are a number of really smart people here that are working on things related to WordPress and whom I respect. There are also a number of meet-ups that happen one of which I use to attend until we had kiddos running around :).
WordCamps typically have the usual beginner, business, and developer track and you have the opportunity to meet anyone from those who are just getting into WordPress as, say, bloggers to those who have worked with some major brands (like Coca-Cola) for building solutions.
I’d say that the WordPress scene could definitely stand to grow, though.
Funny timing for this question. He, the other guys, and I were just emailing this morning about plans for lunch early next month :).
Funny! But no - though we’ve all kept in touch in one way or another, we’re deep in our own thing right now and I think it’s safe to say that we’re all happy working on the things that we are, where we are.
So you’ve got the Boiler plate plugin, Mayer was just open sourced, and you have a few themes or so selling on WordPress.com. Are you in the middle of experimenting with various products, models, etc. to see which one works? From an outsider looking in, it appears as though you’re on some sort of journey, looking for the business model and product combination that will enable you to ramp things up.
I was a huge fan of Standard Theme. When it was sold to WooThemes I had hopes that they’d keep it going but alas no such luck. Did you know they were going to mothball it? Also have you had any thoughts about making a Standard V2?
A few questions centered around WordPress education:
One of the areas that I think will be useful for new-coming WordPress developers is track resources, and there are plenty of them out on the internet.
For example, I’ve gotten a lot of value from your Tuts+ articles and from your blog.
You’ve already gone over some advice for someone who’s a newcomer to WordPress development;
So, my question now is dual (with corollaries):
What resource(s) would you recommend to someone who would like to develop a self-directed “learning path”, focused on WordPress Development? Say they have learnt CSS and HTML, etc., and are looking for the “WordPress Development Track”, as it were?
1(a). How would you advise that they structure their learning? Will a study framework be useful?
1(b). What are your thoughts about “jumping in and breaking the code”? Perhaps there is something to be said about hands-on learning, but how do you feel that this compares to following some sort of curriculum or framework, in order to learn WordPress (and best practice coding) standards?
2 (a). Do you think following your advice from 1 (a) and (b) would help to produce better quality WordPress themes and plugins?
Since you’re involved with Tuts+, I’d love to hear your thoughts on the WordPress tutorial/documentation ecosystem. All of the “Intro to * API” tutorials (including yours) have been really useful. And there’s a ton of resources out there (of varying quality) with info on how to do X or Y. But finding good resources on architecting a plugin, managing performance concerns, scalable patterns, etc. is still pretty hit and miss. Do you think a site like Tuts+ or similar can fill this gap with professional, well-written guides? Or is there just not a large enough crowd for those tutorials to sustain ad-driven business models writing tutorials/guides?
You’ve been strong on promoting decisions not options in your themes. But I wonder how feasible you think this ideal is outside of blogging/portfolio themes, particularly in content-heavy niches like eCommerce, real-estate, etc.
Yeah, I think that’s a fair way to put it. I’m all for experimentation right now and I’m at a place where it’s completely viable for me to do so.
I think that things in the WordPress economy are how they are either because that’s how they’ve always been, or because that really is the best way that they work. If it’s the latter, then great, I’m happy to find that out the hard way; however, if there are other unexplored avenues that are available, I’m interested to seeing how they play out.
In a sense, yes. Since I’m just now spinning up the product side of Pressware, I have a lot of flexibility in what I can do. I mean, it’s much easier to experiment with this type of stuff early on rather than after something has been established for some time.
I don’t take that for granted, so I’m trying to use this time to find out what works best for the team and me.
No - but once the theme was their property, it was up to them as to what to do with it. Really glad to hear you were a fan of the theme, though. We definitely worked hard to make it one of the best themes for bloggers that we possibly could :).
No - Standard was an 8BIT product and when 8BIT dissolved, so did our product line.
That’s a really good question. Odds are, if you asked 10 different people, you’d get 10 different answers.
Personally speaking, what really helped me was first digging into the themes, WordPress documentation, reading various sites, seeing how people did things, how people did not do things, and trying to find may way around into what was considered “the WordPress way.”
I definitely think I took the long route. If I could go back and start again, I’d probably hire a mentor or try to get with someone who was already where I wanted to be and then use their knowledge to advance my own. This would shortcut a lot of the mistakes, missteps, and poor code I wrote earlier in my WordPress career.
To be clear, I’m still learning what constitutes clean WordPress code and the best practices for doing things, but I’m significant further along than I was years ago (and I hope to be able to say the same a few years from today :).
I don’t think there’s as much to be learned from studying frameworks as there is from studying vanilla themes and plugins. The reason being is that frameworks introduce a level of abstraction - a dependency - for a project such that you’re learning the framework versus learning WordPress.
I’m not saying that there isn’t a place for frameworks (because there clearly is) and I’m not saying that frameworks don’t provide benefit to others (because they do), but what I’m saying is that rather than starting at the framework level and working into WordPress, start out the WordPress level and work back out into the framework level.
If you were to picture it as a stack, a framework sits between WordPress and a theme and that just introduces one more layer to peel before you get down to WordPress itself.
It’s hard to answer this question because I think it’s best suited for what your style of learning is.
For example, breaking things and trying to fix them may work well or me because that’s how I learn best. I take the thing apart then I try to rebuild it while understanding what each piece does.
That doesn’t work for everyone, though.
Sometimes, having a book, a guide, or an instructor walk you through how to do things and describing each step of the way with a type of visual guide is more helpful.
I’d love to provide to a straight answer to this particular question, but I’m afraid I can’t :). I’d say first identify how you learn best, then work to find resources that will cater to that particular methodology.
I would hope so ;). If I’ve ended up giving advice on how to learn WordPress and it not yield some type of positive results, then I should probably stop participating in these types of discussions ;P.
But seriously: I think that what results in quality of a WordPress project isn’t necessarily based on how someone arrives at the WordPress-developer level, but how well they follow conventions, how well they follow the WordPress way of doing things, and how well they organize and structure their work.
How we get there will vary, but once we are there, ideally, I think we should all be writing similar looking code.
I’d say that it’s my series on the the WordPress Settings API. It’s a confusing API, but if followed, really makes for the best possible route in creating pages for the dashboard, setting up validation and sanitization functions, and for creating themes in the way that the core WordPress developers intended.
Aside from that, I’m also proud of Comment Images as it’s one that I tend to get a lot of email about. People use it for some really neat sites. Again, though, I wish I had more time to work on it. Since it’s a free plugin, I work on it during my free time and there’s only so much of that available right now.
Thank you - that’s what all of us aim for whenever we’re publishing those guides :).
I think it’s absolutely possible for a site like Tuts+ to fill that gap; however, I also think that a the high-end of those topics are likely going to be reserved for premium-grade courses.
That isn’t to say that the weaker content is free - not at all - it’s just that the amount of time it takes to do really, really deep dives into topics ultimately result in very long series rather than in a couple of short articles here and there that describe the how and why of how to do something.
I also think that because of the nature of WordPress (and other FOSS) and the nature of blogging, finding professional-grade articles can be tough because what Google serves up as the best result may not always be the most correct answer, but the one that ends up having the best SEO, for whatever reason.
To that end, it becomes really important to be able to distinguish the signal from the noise of the advice. This takes a little bit of time because I think that many of us first start off wanting to just get something working. And if it works, then we consider it done.
It’s not until we face scaling or maintenance problems that we ultimately look at what we’ve done and realize that the code we used could’ve been better. Of course, that gets to be a bit of the chicken or the egg problem: How are we supposed to write, say, scalable code when we haven’t faced a scaling problem?
So coming back to your original question, there’s a balance to strike between providing really high-end tutorials for people that are also practical without having too deep into something that they may not have experienced yet. Plus, people who haven’t experienced harder problems in web development aren’t capable of writing about the best solutions because they lack exactly what they need to provide the solution - the experience :).
I don’t know if it helps to break it down into niches like eCommerce, real-estate, etc., because each niche is going to bring with it it’s own set of problems many of which have already been solved.
For example, there are already best practices and patterns for, say, laying out inventory that exists in a shop, or how to best layout a page to showcase some type of information that’s related to how real-estate might be organized.
I’d say it’s up to us and our designers to make sure that we adhere to those patterns. Sure, there’s some alternatives that may exist within those patterns, but then we just provide options for the specific alternatives rather than opening up the gates for a “just do as you please” type of layout.
So the whole “decisions, not options” umbrella is something that I still adhere to and still believe that we should aim for, but we need to make sure we’re doing it within the context of what we’re releasing.
The decisions that I make for, say, a theme targeting publishers likely won’t include the same options that I might include for, say, a photographer.
Understand the template hierarchy and make sure that you leverage it
Gather a group of beta testers to hammer on the project that you’re working on
Have someone more experienced perform a code review before submitting it to WordPress.com
All of these things will contribute to having the best experience possible when submitting a theme to WordPress.com because all of these things will be expected, reviewed, and critiqued before a theme is available for sale.
If you can head off as many issues as possible, then it’ll help to not only build quality into what you’re submitting, but it will help to move the theme throughout the process, as well.
Completely feasible. In fact, this is something that I’m working on consolidating myself.
Yes, there are strong cases as to why you may want to have to separate versions and I get that - I’ve done it myself for the past few years - but over time, the maintenance aspect of it becomes a little bit of a pressure point and having the same version of the theme available for both platforms makes it easier to handle support.
Plus, I think you can make a case for how they’re technically different themes, although very, very similar, because of their feature set. This ends up raising the question “Should we be naming our themes the same thing when they offer different feature sets?”
Some will say yes, others will argue no.
I’d say that if you want to the most straightforward route, then stick with a single version of the theme.
Hey Tom, thanks for taking the time to answer our hard-pressing questions. Much appreciated!
So… I got into WordPress plugin development about a year ago or so. I managed to get a few plugins out there, and they work fine. They do what they’re supposed to do, and people seem to be happy with them. They’re not all too complex, but they’re also not basic “Hello Dolly”-level plugins.
Right when I was in the middle of learning how to develop plugins, your Plugin Boilerplate came out. I checked it out and… OH SHIT THIS IS TOTALLY NOT LIKE MY PLUGIN I’M DOING IT ALL WRONG WTF NOOOO.
So it turns out the Boilerplate is mostly object-oriented, while my plugins are not. (I don’t use “private”, “public” “$this->” and such anywhere in my code.)
So my question is, what would you recommend for someone like me – move towards object-oriented plugin development, or just keep going the way I do it now, since that works and “if it ain’t broke, don’t fix it”. Is it actually better to do it the object-oriented way, or is it really just a matter of preference?
Full disclosure: I absolutely love developing plugins, but I’ve always had a bit of trouble with object-oriented programming for some reason, so I’m a little worried that doing it that way may make things less fun.