During WordCamp San Francisco a few years ago, I had the chance to do pair programming with Rodrigo Primo on #15459. He’s an incredible and passionate WordPress developer, and he approached me before the Contributor Day to do some hacking on performance for hierarchical post types after I sent my patch with some ideas related to that change.
The Unit Test Challenge
When we reached the unit tests, none of us knew how to build that specific bit. The function was printing some code without returning an array of data to assert. And we couldn’t find a Core example of unit tests doing that validation. I suggested to parse that and validate the number with a regex, but we were not sure about the way to go, especially invoking methods directly to the WP List Table object being initialized somewhere in the life cycle of WordPress.
And we just started. Rodrigo created a new file. He added a class extending WP_UnitTestCase. Then we wrote two blank functions – one for the setup, and the first test function.
And we kept forward, step by step. We didn’t know the best way to solve it back then, but we knew that we had to create a unit test. Instead of brainstorming everything and getting lost in our ideas, we went on with the iterational approach, building small bits of code until we hit a real problem. It’s not perfect, but it works. Solve it, then go for the next one. If it doesn’t work, try the next option.
Sometimes “good” is good enough, even if it’s not perfect. I’ve had at least two Core commits where Nacin was not fully satisfied by a patch, but had nothing better in mind:
Sometimes a good will and a decent solution can do wonders. Striving to be perfect is an important goal, but taking the first step and breaking a project into several components is the way to go.
Break It Into Pieces
When I break it into essential components, and then break them even more into specific tasks, I get a better idea of whether this is a tough job, or not.
Sometimes I see a WordPress RFP that seems trivial, and after spending some time on R&D or estimations, I reach to several crazy APIs with tough endpoints to connect to, or other modules that cannot be extended easily. I see potential compatibility issues, communication problems during the development process, or other things that could go south.
And sometimes I see a complicated proposal that is really straight-forward. It sounds complicated at first, but then it ends up with several functions replicating the functionality for everything across the platform.
Over the years I’ve had some rough tasks in a Project Management system that weren’t defined properly. And when I open my IDE and prepare for work, I cannot proceed further due to the various question marks reading the task. And as soon as I break it into independent small modules, I can easily jump on that even at 1am after a long and exhausting day. Because then it’s a no-brainer.
Pippin’s How To Guide
Pippin has a great guide on becoming a better developer. It’s really practical for almost any industry, since it’s a common sense when you want to accomplish more with your life and sharpen your skills.
When you see the best developers, or business owners, or marketers, or speakers out there, it may seem as if they were born with the skills. The “naturals” are really a rare breed, and almost everyone you admire or follow online has been a pathetic junior at first. All they got was motivation and willingness to tackle the hard work. As Pip says:
One of the biggest weaknesses I often see in developers is the “this is too hard” mentality. Bullshit. Nothing is too hard, you just don’t yet have the knowledge or know how to accomplish the task at hand. Being faced with technical challenges is very different than mental challenges. You may not be able to make a processor run faster, but you can find ways to make the processes take less power.
And it all ends up with starting somewhere.
If you come up against a challenge, work on it. Dig into it until you find a hint at the solution. Pursue that hint until it turns into a brick wall or opens up into another hint. Eventually, after you find enough hints, you will have a solution. If you run out of technical knowledge, go and seek more. If you’re working with an API and don’t know how to retrieve some particular data, research the documentation, and if that fails, dig into the source code.
With so many online communities, support forums and how-to guides, working on an Open Source project is fairly logical. All of the resources are out there, and they are waiting for you to grab them.
It may sound as a cliche, but when I started, I had a printed copy of a book and a DOS Borland text editor with a compiler. I had no programmer friends back then (it wasn’t that popular of a job either) and I spent months on a few tasks, trying them from different angles. Sooner or later, it worked out.
The Pet Project Solution
One of the best ways to keep yourself motivated is working on a project of your own. Something that you are passionate about, a pet project. You need a tool or a service for something? Develop it. You want to start a blog, or a business website? Go for it. Then continue and refine it until you get better.
This approach lets you solve real problems, build a portfolio, and feel proud of what you’ve made. Plus, it’s a chance to be creative and meet people with similar interests. Overall, personal projects are more than just work; they’re rewarding journeys that help you grow personally and professionally.
In junior high school I had a QBasic copy and I wasn’t into the natural sciences. I had a long homework with identical formulas, so I built a small calculator for it. Then, I started to extend it and improve it in a way that helped me solve all of my tasks.
A bit later – with a modem at home – I set up a forum on programming and IT security. I asked a few of the online experts I knew from other forums to become moderators, and all of the other wannabe’s to join me. I was reading every single topic and answer, digging online for different perspectives, studies, posts or forum threads. I was brainstorming together with the newbies, and learned from the experts. But it was a hands-on experience. And I got into building small modules and customizing the forum system in order to make it better, which is when I learned about web servers and PHP development in the first place.
A pet project can easily last for a few years, help you with a real problem and allow you to learn with it. Extending a platform, customizing an existing solution – you name it. The same approach could be applied for other groups of people.
Trainers can organize small group events for training activities. Or help at a school by presenting a topic. Organize a seminar or a workshop at the university. Volunteer at a conference, or a training course.
People interested in marketing can start a blog, analyze the audience, get on the social media. Or even get a business that’s not active online, build their online presence for them and take it from there. There is always a way to start small, get on a few volunteering gigs, learn from the best and improve your skills.
Take The First Step
We had several QAs at DevriX over the last 2 years who weren’t excellent in their testing efforts. Which is why we kept trying and we hired my friend Yovo who is doing QA for us since August.
At first he was terrified with the few tasks we assigned him. But he had an eye for detail and user experience and he nailed them in a few days. Once we revealed a few of our other projects, he got speechless by the amount of work awaiting for him. A month later he was completely comfortable working on large multisite projects and testing all bits of code, learning GitHub and setting his own local multisite environment.
Yovo has been trying to build small sites for a while without a huge success, mostly due to the lack of persistence. I’ve been bugging him to check one of my seminars with a step-by-step guide of turning an HTML5 template into a working WordPress theme. He finally agreed on watching the video twice, and just a day later he had a semi-functional WordPress theme.
“It really wasn’t so hard”, he said. All he needed to do is start, and then slowly get better in learning the skills.
Now he can even review a PSD before turning it into a static site and find a huge list of potential gotchas with tricky div alignments and animated spans, floating sections or overflowing headers.
I was fortunate enough to start my career with one of the three largest projects that I’ve ever touched in my entire programming and management life. It was an enormous eRP platform for a food chain with shops across Europe, with complicated invoicing and CRM platforms and several intranet networks syncing into a large Oracle cluster. I started reviewing the thousands of Java classes and spent months building small components or refining existing ones. When I switched to regular web development, everything was straight forward and pretty standard, thanks to my first experience and determination to make it work.
After more than 10,000 hours on stage, I still remember my first few sessions in 2006. I teach some workshops every now and then for people eager to become trainers, and I see the improvement they get with every coming session. Some of my technical students are now agency owners or team leaders in Fortune 500 companies, and that’s the greatest experience a trainer could have.
But starting a presentation is tough. So a few years ago I blogged about the preparation of training materials in my old blog, covering the research steps and taking the right notes for building a the scope of a technical session or a course.
Other than collecting all the resources, I start with an empty Gist. I create a blank Markdown document, write all of my titles. Then I fill my imaginary slides in with some notes:
- add a code sample for X here
- add an image of Y there
- add a “demo” heading slide
- insert these notes here
- research that case study of Harvard in this slide
I start with the overall structure, then I refine each title. When I’m somewhat ready, I create a few slides with HTML5 Slideshow Presentations (a WP plugin) and just deal with the styling and minor content changes.
1 Push-up A Day
Matt Mullenweg was interviewed by Tim Ferris and the interview was quite informative on various aspects.
One of my favorite parts was related to Matt’s workout schedule. During the show he mentioned an interesting strategy to start your exercise with a push-up (around 49-50min from the start of the podcast):
Well, it started with 1. So, just before I got in the shower, I do 1 push-up. And no matter how late are you running, no matter what’s going on in the world, you can’t argue against doing one push-up. Like, come on, there is no excuse. So, I often find I just need to like, get over that initial hump, with something that’s almost embarrassingly small.
When you think about working out in a fitness, it’s usually related to commute, long physical training, showers, changing clothes, commute again etc., which is often tedious and time consuming. Which is a great excuse for many people not to do that.
What Matt suggested is starting with one push-up. Doing 20-30 or more may be more demotivating, but how much effort is in there for one push-up? And once you start, you can easily do a few more, since you’ve already made the first attempt.
I love Remote: Office Not Required by 37signals (now Basecamp). It’s one of my top books I recommend for remote workers and cofficers. They also have another book – Rework, that covers your own planning, strategy and personal project management, as well as other good bits for remote workers.
So I’ll end up with a few power quotes from the book:
“Start making something”
“What you do is what matters”
“The most important thing is to begin”
“the real question is how well you execute”
The context is obviously important, but you can get the gist of that and read the books for more insights on productivity and personal development.