The Process of Writing

The general recommendation to becoming a better writer, is to write every day.

Besides high school creative writing, I am mostly a self taught writer. I’ve never completed any official copy-writing courses, even though I have three purchased on Udemy from about 2 years ago. I generally don’t understand the finer details that would take me from being a blogger or writing contributor to the ranks of editing someone else’s writing work.

That being said, since I was accepted as a freelance contributor on the Skyword platform early last year, I’ve probably completed at least two written assignments per month. I’m definitely writing more than I ever have, and it’s definitely paying off. I’m seeing the benefits not only in my paid writing work, but also in the general content of my blog.

I thought that it might be useful to share the process I follow, when I am writing content for money. If nothing else, it allows me to write something else today 😉

Brain vomit

While the image above my not be pleasant, this is always my first step. When working on a specific assignment, I will have certain guidelines I need to follow, in terms of article content.

I’ll create a new blank Google Doc, paste any relevant information from the assignment at the top of the page, and then just type out whatever comes to mind. This is usually just a few words or phrases, maybe a title, or a sentence or two.

Research

Once I’ve put down the thoughts I have in my head about the topic in question, I’ll start doing some research. Often this is to clarify some points of (mis)understanding, or to fill in some gaps in my knowledge. The assignment topic will define how much research I do. If it’s in an area I know little about, I can spend up to an hour researching. As I am researching the topic, I’m starting to put together a plan of how the article will look and what the story is I want to tell.

First draft

I then start writing my first draft. This is just everything as it enters my head. I might make minor edits here or there, but mostly I just write as the thoughts come to me.

Break

This is a pretty important step, but I then take some time away from writing. I find this allows me to think about what I’ve written, if there’s anything else I want to add or take away, and allows me to come back to review what I’ve put down with ‘fresh’ eyes.

First edit

This is the most edit heavy process. I read through the content and do my best to self edit my work, taking out repetitive words, looking for other words or phrases that will convey what I’m trying to say. This is usually where I will also start adding links to relevant content, including images, and generally trimming down the content to fit specific criteria. I may also take out sentences, and sometimes whole paragraphs, that don’t fit into the edited article any more.

Second edit

Immediately once the first edit is complete I’ll start the second, and final, edit. This is where I try to just read the article from top to bottom, as a reader would. Usually this is also where I look for complex sentences and try to uncomplicated them, as well as a more detailed focus on spelling and grammar errors. I will also look at the flow of the sentences and prune them where necessary.

I’m sure my process is nothing new or unique, but it’s evolved over time and I find it works for me.

The two worst things you can say to your freelancer.

I’ve been freelancing full time for just over three years now, having spent 10 years developing for either digital agencies or small to medium sized businesses, in various roles.

In the 3+ years since I switched to freelance development, the two sentences that I’ve heard/read the most from clients, and the ones that illicit the most negative responses in me, are:

“This will only take x minutes”

“This will be easy for an experienced developer”

If you are a freelancer, and you’ve been on the receiving end of these phrases, you’ll know what I’m talking about. This post however is not for you, it’s for anyone who has ever said one of these phrases to a developer, or who might not understand why they are so negative.

“This will only take x minutes”

x is usually a variable number, ranging anywhere from ‘a few’ to 30. Sometimes minutes is replaced by hours. Either way, the reason this phrase is so despised by freelancers is that it indicates to that you think you know more about what we do, than we do.

If you know something will take 5 minutes, that means you understand the problem fully, as well as the possible solutions required to solve it and also which one to apply to solve it within 5 minutes. This means you can do it yourself. And it is therefore a lie, because if you could do something in 5 minutes yourself, you would not be hiring someone to do it for you.

“This will be easy for an experienced developer”

Personally, this one is worse than the previous phrase, and here’s why.

This phrase tells me you understand that I am experienced in my field, that I am knowledgeable, and you recognise that I can fix your problem. What it also tells me is that while you recognise my ability to fix your problem, you don’t value my knowledge enough to pay what it’s going to cost.

What is happening in both instances is that you’re trying to get me to keep my price down, because you think it will be a simple solution and you assume therefore it will be quick to fix. Unfortunately, in most cases, you’re making the same mistakes as the folks who thought that Titanic was unsinkable.

If the problem was a 5 minute solution, you wouldn’t need to hire me to fix it. And my experience, comes with a price. You either value the fact that I am capable of solving your problem, or you are looking for a cheap solution, which usually means taking shortcuts, something that I am not prepared to do.

Successful solutions take time, planning and thorough testing. By making assumptions up front, you are setting the project up for failure, and nobody wants that.

A Quick Hack to Writing Testable Code

I’ll be the first to admit that I am fairly inexperienced in the practical application of unit testing, or any kind of automated testing. That’s not to say I don’t understand what these things are. I was first exposed to the concept of unit tests back in 2008 and automated browser testing in around 2012. I know the theory of how they work and what the benefits are. It’s just that I’ve never been in a situation where I had the time to learn how to implement these things, so I’ve never really been able to. It was the classic “running alongside your bike” scenario.

That being said, there is something that a very skilled developer I used to work with said to me back in 2012, which I’ve implemented ever since, that I only realised today not only applied to writing better code, but also to writing testable code:

“Every function, or class method, should only do one thing”
Shaine Gordon, CTO at Realm Digital

Let me explain that by means of an example.

Let’s say you need to write a string parser. The parser needs to take a string, convert it to lower case, strip out specific punctuation (full stop, comma and space) and return the string with the first character as upper case.

In PHP, that could look something like this:

function my_string_parser( $string ) {
	$string = strtolower( $string );
	$string = str_replace( array( ' ', '.', ',' ), '', $string );
	$string = ucfirst( $string );

	return $string;
}

Now, the perceptive amongst you might notice the bug. If you don’t see it right away, that’s OK, because that’s the point of this article.

So lets say I now decide to write a unit test to test this function (we’re not digging into TDD just yet). With PHPUnit installed, I might write a test class method that looks something like this:

function test_my_string_parser() {
	$string        = 'My test, string.';
	$parsed_string = my_string_parser( $string );
	$this->assertEquals( 'Myteststring', $parsed_string );
}

Based on the code above, this test would fail. My problem is, at what point in manipulating the string, does my function fail?

However, if I refactor my initial code a little:

function my_string_parser( $string ) {
	$string = my_string_to_lower( $string );
	$string = my_string_remove_punctuation( $string );
	$string = my_string_ucfirst( $string );

	return $string;
}

function my_string_to_lower( $string ) {
	$string = strtolower( $string );

	return $string;
}

function my_string_remove_punctuation( $string ) {
	$string = str_replace( array( ' ', '.', ',' ), '', $string );

	return $string;
}

function my_string_ucfirst( $string ) {
	$string = ucfirst( $string );

	return $string;
}

Granted, it’s a lot more code, but now I can write individual tests for each smaller ‘my_string’ function, and the failing test(s) will point to where the bugs are. I can then fix those bugs, function by function, until my individual tests pass, and then the ‘test_my_string_parser’ test will also pass.

I’m pretty sure this isn’t rocket science, or anything new, but if you’re starting your unit journey, it’s a good place to start.

Unit Tests for your WordPress plugin using WP CLI and PHPUnit

Often when I write a blog post, part of the reason I write it is to document things that I tend to forget. This is one of those times.

Requirements:

PHPUnit: At the time of this writing, WordPress only supports the latest stable 7.x version of PHPUnit, and recommends installing it globally.

wget https://phar.phpunit.de/phpunit-7.5.9.phar
chmod +x phpunit-7.5.phar
sudo mv phpunit-7.5.phar /usr/local/bin/phpunit
phpunit --version

WP-CLI: If you’re developing on WordPress and you’re not using WP-CLI, you are missing out on some amazing tools.

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar 
sudo mv wp-cli.phar /usr/local/bin/wp

Set up

Using WP-CLI, you can quickly scaffold some unit tests files for your WordPress plugin.

Inside the WordPress directory of the site you’re building/testing on, run the following command to scaffold the unit test code for your plugin, located at /wp-content/plugins/plugin-name

wp scaffold plugin-tests plugin-name

If you don’t already have a plugin directory, because you’re building the plugin from scratch, you can just run the following command to scaffold some initial plugin code, which includes the unit test code.

wp scaffold plugin-name

Either way, you’ll end up with a ‘tests’ directory inside your plugin directory, which includes the test bootstrap file, and a sample test file.

The next step is to set up the ‘wordpress_test’ database, which the test suite will use when creating mock posts etc. Switch to the plugin directory and run the following comand, replacing ‘root’ and ‘password’ with your local MySQL servers username and password.

bash bin/install-wp-tests.sh wordpress_test root password localhost latest

And you’re done, go forth and write some unit tests for your WordPress plugin.

Travelling the web on the WordPress HTTP API

At WordCamp Europe 2019 in Berlin, I was accepted to present a workshop, which was on the WordPress HTTP API.

Unfortunately we had some WiFi issues, and not all the attendees were able to complete the workshop. Also, there were some folks who were not able to attend at all, due to the workshop being booked out!

This post attempts to solve both problems, by including a link to the GitHub repository, the slides, and 3 videos of me live coding (more or less) the workshop content.

Fair warning, this is the first time I’ve done something like this, so bear with me.

Hopefully using the slides, the GitHub repository and the videos, you’ll be able to complete the workshop and learn a little more about working with web based APIs and WordPress.

You can find the slides here

You can find the GitHub repository here

Below are the videos I’ve recorded of me completing the workshop content.

Part 1

Part 2

Part 3

The Answer to Life, The Universe, and Everything.

Today, I turned 42.

If you’re a fan of sci-fi, specifically Douglas Adam’s “Hitchhiker’s Guide to the Galaxy”, you’ll understand both the importance of this number, and the reference in the title.

I do think it’s sort of apt that the number 42 was used in this context. When I hit 40 I felt good about it, but now, a mere 2 years later, I think I have a much better idea of who I am as a person than I did two years ago, and my place in the world. Isn’t that weird, how two years can make such a difference?

What I have noticed is that in the last 2 years I have been focused less on worrying about what others are doing around me and more on just being a better version of myself. This way of thinking has bled through into all areas of what I do, both personally and professionally, and I think I’m really starting to see fruitful results.

So maybe the answer to the life, the universe, and everything, lies in having the confidence to being honest with myself as to my strengths and weaknesses, which, for me anyway, only comes from being on this earth for 40 years. I feel like there are people who get there earlier than I did, but I’ve learned that we all have our journey to follow, and each is unique, and that’s OK.

This morning I learned that the execution of Archduke Ferdinand, which kicked off WWI, happened on this day, but that the Treaty of Versailles, which effectively ended WWI, also happened on this day.

Isn’t that amazing, two major events that changed the world, happened on exactly the same day. This really gives me some food for thought.

At the end of it all I’m grateful for the 42 years I have spent in this planet, and I look forward to the next 42.

Some news updates.

I don’t think I completed my year end review for 2018 or wrote a resolution post for 2019. However a bunch of things have happened so far this year, mostly in the past few months. As it’s almost exactly halfway through the year, I thought it might be cool to share them.

As one door closes…

Towards the end of last year, my wife and I decided to sell the family business we’d been running together since 2011. It was a hard decision to make, but as our boys were growing older we found ourselves less and less inclined to want to work on weekends, which the business required. I’m happy to say that we successfully sold the business earlier this year.

Castos and accelerator funds

Back in December of 2016 Craig Hewitt contacted me looking for someone to help him extend the podcasting plugin he had recently acquired. I’ve been working with Craig ever since, and so I was very pleased to find out the Castos, the company built to support and enhance the plugin was accepted into the TinySeed Accelerator. Which brings me to…

…another opens.

The investment Castos has received has allowed Craig to offer me a full time role in the company. I’ve been the designated lead developer of the project since pretty much just after we launched what was then called Seriously Simple Hosting back in 2017, but now it’s an official position, with all the benefits and responsibilities that go along with it. I couldn’t be happier, because I think we have a great product, and I now get to work with a small group of amazing people, helping our clients and plugin users from all over the world, every day, so I’m looking forward to what the next year holds for us all.

That’s not to say that I won’t be able to continue to work with my clients at Codeable. I’m lucky to have made great relationships with a group of repeat clients and I will continue to serve them in whatever capacity they require.

This position will also give me some security and time to to put into other areas, including expanding my contributions to WordPress, and getting back on the ‘building my own products’ train. Watch this space.

Castos goes to WCEU

Part of the Castos/TinySeed news was that I was able to travel to Berlin and (finally) meet both Craig and fellow Castos developers Danillo and Stefan. It was the first of what looks to become a regular, yearly team retreat. Working along side people remotely in a start up environment is a fun-filled experience, but there’s nothing like actually meeting in person. We know also know who the tallest member of team Castos is, and no, it’s not me! I’m hoping that the next team retreat will include the other members of our team.

The team retreat was timed to coincide with WordCamp Europe, which meant I was able to attend this year again. My favourite thing about WCEU is meeting people in real life, especially those I’ve only ever meet online. It’s always great to see my community team friends, but this year I was able to connect with, and meet in person, an entire years worth of ‘online only’ folks.

Highlight’s of WCEU 2019 was being able to secure a 15 minute chat with Matt Mullenweg, the Codeable experts dinner and group photo, and Monique Dubbelman bringing me some amazing and authentically Dutch stroopwafels, which I now have to find a supplier for locally.

Professionally, 2019 is shaping up to be a pretty awesome year. I have some plans of things I want to accomplish for the rest of this year and the next, but I’m also acutely aware that one cannot succeed at everything. Win or loose, I’m exceptionally excited to be able to at least try.

Thoughts on Unit Testing

I’ve never been someone who understood the value of unit testing. During my programming studies, when I learned new languages like PHP or JavaScript, unit testing was never a topic that came up. The byproduct of a non university, tertiary education I guess?

The first time I discovered unit tests was when I was working with a Python developer in the late 2000s. I can’t remember how it came about, but it was through him that I learned about the concept, how you write the tests first and then write the code to pass the tests. I still didn’t understand the value, so I did some cursory research but generally moved on.

Over the course of the next few years I often saw articles or discussions on unit testing, but the idea of unit testing my code was not something that was a part of any developer position I’ve held in the last 15 years, so I never learned how to, or why I should, write unit tests.

In 2015, when I started developing for WordPress, unit testing came up again, as I looked into contributing to WordPress core. In my search to ramp up my WordPress development knowledge I discovered Know the Code, and one of Tonya’s courses was about unit tests. At around the same time I started using Laravel, which meant eventually finding Laracasts, which also included a course on Unit Testing. Through these places I eventually discovered Grumpy Learning by Chris Hartjes, who has 3 books dedicated to unit testing PHP code.

I’ve since come to appreciate the value and need for unit tests and have committed myself to writing unit tests for all new functionality I code from 2019 onward. At first it was daunting, but today something finally clicked.

It started with a new feature. I needed to verify the extension of a media file path, ignore any query strings that might be appended to that path, and return the correct base name to the actual file. Contrary to my unit testing resolution, I wrote the actual code first, but realised that when it came time to test it, I’d need to do a whole bunch of other work to deploy the code and test it manually, the old fashioned way. I realised this was a great chance to write some unit tests.

During the writing of some simple assertEquals() assertions, I soon realised that my initial understanding of the problem was flawed. By writing a few additional tests for cases I had not originally thought of, I could more thoroughly test my solution and improve it to handle these new situations.

In a round about way, I ended up eventually writing the correct unit tests I should have written in the first place, rewriting my code from scratch to solve these tests, and ending up with a much better overall solution.

The tests themselves and the code solution was trivial. What was important was the realisation that, had I started writing the tests first, my mind would have provided additional cases I might not have thought of. I would therefore be preparing myself to not only come up with a better solution, but with a much faster way to test and confirm it.

Through all this I’m getting a good grasp of which types of problems lend themselves to unit testing and which do not. I also realise that if I’m going to write more unit tests I need to allow myself more time up front to plan and execute proper unit testing. I’m still learning, so things like mocks and stubs are still far off concepts I’m aware of but will need to master. I am however excited to see how this improves as I practice, and how it improves my development output as a whole.

WordPress Plugin Development Best Practices

The slides for my talk on WordPress Plugin Development at CMS Africa this morning

The Clear View – Get the MOST from your freelance developer

Have a clear understanding of your project requirements to ensure you get the most out of your freelance developer

The purpose of this post is to ensure that you know precisely what you need to do in order to get the most out of the freelance developer you’re about to hire. You need a complete understanding of what you want to achieve before even looking at the Freelance for Hire pages. Seriously. Otherwise you will waste time and money and nobody has an endless supply of either.

Here’s a great example…

You are an expert teddy bear maker. You love them. You know that your particular brand of bear is exceptional and you want to build a business out of them. You contact a developer and you say, “I want to sell teddy bears online.”

While an admirable plan, this is too vague and will require a lot of work to fine tune into a final requirements list. Instead, look at developing a breakdown of your requirements that outline every aspect of your business, your needs, your requirements and your customer deliverables.

Something like this…

– I would like to build an eCommerce store that can help me to sell my teddy bears

– The store needs to support a product gallery that can showcase each bear

– The store needs to support a short product description for each bear along with a list of specifications such as fur used, type of eyes etc.

– I would like to accept credit card payments along with EFT and possibly Snapscan or another app payment platform

– I would like the payment gateway to support both international and local credit cards

– I need to add shipping to the order after it has been placed as these will differ depending on the product purchased and the location of the customer

– I would like web hosting options

– I have a domain and email accounts that are linked to that domain, and I think the domain and emails are managed by my internet service provider

– I would like my store to be built with WordPress and WooCommerce

This level of detail really helps both you and your freelance developer to assess the job and what will need to be implemented to make it work. And what underlying technologies will need to be used. We will be exploring the process of clarifying these requirements in greater detail in a later post/chapter as they will help you with pre-hire and with how to harness the help of a freelancer in the scoping and investigative phase.

The detail

Have you ever tried to explain a complex concept to a child? As the parent of two very inquisitive young boys I have learned a lot about how to take something complex and breaking it down into pieces that their brains can understand. To achieve this, you need a solid understanding of the concept yourself. There’s little point in explaining the concept of why the wind blows unless you understand high and low air pressures (I was a geography nerd at school).

The same theory applies to your product or service. Understand your product and its requirements intricately before you move into a relationship with a freelance developer. You can’t brief something unless you know it really well. This also ensures you have a clear vision and will inform all your engagements with your freelancer.

Another bonus is that it will also refine your vision and you will potentially identify any loopholes or issues before it is too late.

CASE STUDY: The successful client/freelance relationship

Craig from Seriously Simple Podcasting

– He understands the concept of podcasting really well

– He was able to define the value of Seriously Simple Podcasting and how its add-on services delivered value to customers

– Already had a viable customer base

– Understands what his clients want

– Has completed some programming tutorials and has some understanding around the basics of web development and the concepts that define it

– Works with his freelance developer to define scope, determine project goals and discuss possible solutions to any problems that arise

CASE STUDY: The flexible partner

Melinda from Agency Of Creativity*

– She is a designer and owns her own agency

– She uses a popular page builder plugin to build her client’s websites

– Each client has a common requirement that she has to build from scratch each time and she realises that this could be developed as a plug-in

– She isn’t clear on the underlying technologies required to make this a reality but she is happy to hire a coding expert who can work with her to achieve her goals

– She provides clear and concise instructions

– She knows exactly what her clients need and is the ideal person to test what is built along the way to ensure it meets specifications

CASE STUDY: The client that can’t

Dawid from Services R Us*

– He has a vague idea of the service listing he would like to provide but isn’t sure about implementation

– Assumes that the process is as simple as ‘just add this field to this page, it should be quick’

– Rambles on about different ideas that pop into his head without actually getting to the point

– Doesn’t send a clear briefing email but rather wanders with his thought processes

– Can’t provide a detailed list of requirements but expects a clear and fixed cost/time estimate

– Constantly contacts the developer, asking them to fix other technical issues that are unrelated to the project. He expects freelance support for free just because of the project

The first two projects are a development success. The last is a time and energy vortex that leaves both client and freelance developer gasping. The best way for your project and your vision to succeed is to have a clear vision and to be open to the reality of what is required.

*Names changed