Are you doing what you want to be doing?

The Journey

I knew today was going to be a hard day.

This morning I made the official announcement that one of my passion projects, a Gracie Jiu Jitsu club I opened in 2014, would be closing down. I sent out an email to all members and parents informing them of the news, and then made that post public. I knew I would be letting some folks down and that I would find it hard to do so. What I didn’t expect was how it would affect me personally.

As I read the article which was the inspiration for the opening quote of that post, I found the emotions become too much for me to handle. As I wrote the post it happened again and each time I’ve read it I find my self feeling sad. It’s been a struggle to focus on work or anything else other than a few small tasks I’ll complete today.

The upside is that each time I see the quote, mostly commenting on the associated Facebook post, I am less sad about the choice I made. I am less sad because it was the right choice to make for me and my personal situation. Often the right choices are the hardest.

So why blog about it here? Well I’ve often in the past blogged about what’s happening in my personal life, mainly as a form of catharsis but also as a way to share the news with anyone who cares. I’m not someone who lives his life in the public space, but from the 1st of May I’ll no longer attach the title ‘Gracie Jiu Jitsu instructor’ and some might wonder why.

Mostly it’s about sharing the news on a platform I manage where I can put it out on social media for folks to find out and avoid any future ‘are you still running your club’ questions.

But I’ve also realised it has something to do with choices we make in life and in business, how this has really helped me understand that the right move at the wrong time, is the wrong move, and how this effects the path we follow when it comes to work and personal life.

If you’re sitting on the fence about a hard decision in your life, be it in your personal or business life, I speak from experience that to keep doing something well after your interest or passion for it has waned, just because you don’t want to let others down, is going to end up eating away at your soul. If you find yourself hating something, often it’s better to figure out how to remove yourself from that situation than to worry about how others may perceive your so-called ‘failure’.

Being able to get up every morning and know that whatever is ahead of you for that day is what you WANT to be doing, not what you HAVE to be doing, is worth all the money or fame in the world.

 

 

Codeable reviews – the good, the bad and the ugly.

Codeable reviews, are they real and how happy are Codeable clients really?

If you have been following this blog you’ll know that I was accepted as a Codeable expert back in September of 2016. Since then I’ve completed 70 tasks through Codeable with an average rating of 5/5. You can even read some of the Codeable reviews my clients have left me at the bottom of my profile, but how real are these reviews?

If you visit the Codeable home page, you’ll see they quote a number of ‘989 of every 1000’ projects completed with a 5/5 rating. This calculates to a 98.9% rate of 5/5 rated projects. I thought it might be interesting to see how real that figure is, based on my own experience.

First, some facts.

Since I joined Codeable in August of 2016 I have completed 70 projects with an average rating of 5/5. It is important to note that not all 70 projects mean a different client. In some instances, I have completed multiple additional tasks for the same client. In fact, as of this year, I have not completed much new client work and most of my work through Codeable is from existing or repeat clients.

At the time I have been with Codeable I have earned a total of $17,983.67 with an average project size of $639.82. Most of the projects I work on are in the sub $1000 range, for personal and availability related reasons.

Bad Codeable Reviews

Let’s start with the bad. As a Codeable expert, I have been fortunate in that I have not received any bad client reviews. I have received 2 less than 5/5 ratings, one of 4 and one of 3. That works out to a 97% 5/5 rating. Not the same as average Codeable expert 98.9% rate but still pretty good in my books. In my own defence, the 3 star rating was from a project where I applied for a requirements gathering task, completed the requirements gathering, submitted the requirements document and then my estimate to complete the work required and the client opted to not follow through with the project. I’m not 100% sure why they then rated me 3/5, as I completed the task we agreed on. I can only imagine that they believed my quote was too high.

Good Codeable Reviews

It’s always nice to lead on from the bad news to the good news, so let’s take a look at my good Codeable reviews. On my Codeable profile, you can view the 15 most recent client ratings and reviews I’ve received. You’ll see that some clients choose to merely rate my work, some are happy to leave a review. This is entirely up to them, but I appreciate whatever they choose to do. Getting a 5/5 client rating or a great review really does put the spring in my step.

These are all real clients, who I’ve completed projects for, ranging from small tweaks to larger plugin customisations.

Ugly Codeable Reviews

There are always projects that go wrong. Again, I’ve been fortunate that I’ve only had two go badly wrong during my time at Codeable. Both times the same things happened. Codeable customer support stepped in, took over the project and either found another developer or refunded the project. In both instances, I was actually the second person to work on the project, the relationship with the client and expert having already gone wrong. In the first instance, the client was refunded and they were assisted by Codeable customer support to post a new project, with a better project description. In the second the client was refunded half of the project amount, as half of the project was completed. Both times I lost money but learned a valuable lesson and was impressed with how Codeable honoured their quality promise and money back guarantee.

Understanding why projects go south.

It’s important to note that in both of the above instances the main reason the project went south was a lack of understanding of scope. Project scope is defined as “The work that needs to be accomplished to deliver a product, service, or result with the specified features and functions.” To put it in Codeable terms, it is the agreed upon pieces of work that a Codeable expert will complete to deliver what the client has requested. More often than not, client/expert relations break down when the initial agreed upon scope is expanded on (new requirements added) during the course of project and there is a miscommunication or misunderstanding as to the fact that these new requirements will require additional time and cost to complete. In my personal experiences, this was the exact reason both projects went wrong.

Understanding Codeable reviews

If you’ve come this far you probably think this piece was meant as a strongly pro Codeable article. It was, but not for the reasons you think, I’ll leave that up to more experienced writers like Nathan Ello and Robin Scott. I am a Codeable expert because their customer service, quality standards, and unique developer community mean my clients will get a better service from me than what I could do on my own. However, if you are considering hiring a Codeable expert, it’s important to be able to read all Codeable reviews online and make up your own mind. I, therefore, wrote this to give you a little inside scoop and to help you understand how it all works and be more informed when making your decisions.

 

Everything you’ve ever wanted to know about dealing with Codeable.

If you have been following my blog you will know that I was accepted as a Codeable Expert in late 2015. I’ve since spent a fair amount of time espousing the advantages of working with Codeable.

Now, one of my Codeable colleagues, Robin Scott from Silicon Dales has written what is probably the most extensive tutorial on working for and with Codeable. As a developer and owner of his own development agency, Robin has the unique perspective of having seen both sides of the Codeable coin, both as a Codeable expert and client.

It really is an amazing read and not only describes the experiences of both a Codeable client and expert, but shares some common tips and pitfalls of hiring through Codeable as well as being hired as an expert.

If you are looking to hire a Codeable expert to help you complete your next project I highly recommend reading this article.

Taking back ownership of the word ‘freelancer’

PHPSouthAfrica

Based on some prompting by Hugh I applied as a speaker at PHPSouthAfrica this year. Apparently they still don’t know how little I actually know as they accepted my talk submission 😉

I’ll be talking just after afternoon tea about a topic that has been on my mind since 2010, that of the common perception of the freelancer, specifically when it comes to developers.

A freelancer or freelance worker is defined as a person who is self-employed and is not necessarily committed to a particular employer long-term. Since becoming a freelance developer in 2010 I’ve discovered that there is a stigma attached to the word. I don’t know if it is developer specific, but every time I meet or take on a new client the fact that I am ‘freelance’ tends to inspire visions of horror, usually of poor deliverables, bad client support and just a general lack of responsibility. In my talk, I would like to unpack this problem and provide some solutions to it.

Here are the slides for this talk.

Gutenberg day 8 – Contributing to Core

I’m attempting my first shot at contributing to WordPress core with ticket that was opened 8 years ago!

I feel like it’s small enough that I can get something done by the time the next release rolls around but useful enough that it will make peoples lives easier.

Feel free to follow the ticket to see how it pans out.

In other news, using Gutenberg today was a bit of a pain. Because I use Jetpack’s publicise functionality to share my content socially and Jetpack does not yet support Gutenberg (for obvious reasons) I have to write up the post in Gutenberg but not publish it and then edit the Post in the usual way and publish it. Today this lead to me loosing all my content and merely switching to the regular post editor. Fun times.

Gutenberg day 7 – New things

WP HackerCast
Today I'm especially excited to blog as I have a little news to share. The first episode of my new podcast has officially been published.
WP HackerCast – Episode 1 – Seagyn Davis
WP Hacker Cast is my way of talking to and learning from all the great WordPress developers I know and communicate with. I've got some great interviews coming up, but the first is always the most special. I hope you enjoy it.

Gutenberg day 4 – New things

New_Office_Space
Today was a my first day in my new office space. Since becoming fully self employed at the beginning of 2016 I've been working mostly from home on a day to day basis. This has led to a few frustrating moments, although based on what I've seen I'm pretty sure I'm not alone in this.
In order to try and find better focus on my work and more of a separation of work and home life, I'm sharing an office space about 10 minutes from where I stay. It works out pretty well, except for a minor hiccup today which meant I lost about an hour of my day. The upside however is that I am less inclined to take my laptop out when I get home and I'm therefore less inclined to work after hours. Part of me still feels like I haven't done enough today but I'm hopeful that as I get used to the new setup I'll become more productive with the time that I do have for work. 

2017 WordPress resolutions – mid year check in.

Late last year I wrote down my 2017 WordPress resolutions. These were the goals I set myself (for better or worse) that I would like to achieve this year.

As we’re just over halfway through the year I thought it might be interesting to take a look back and see if I’ve made any headway on any of these items and whether I need to make some drastic changes for the next six months.

A more stable work environment.

If I think about it I have not yet quite achieved the ratio I had set out to, but there is some good news. I can’t remember when last I worked past 23:00 and I’ve even had some weeks where I didn’t have to catch up in the evenings at all. I have not yet been able to carve out time for plugin development though, so that is something I want to work on more. I can still be doing better with my project estimation so I’m constantly evolving that process.

5 for the future.

To be honest this has worked out, but in ways that I never could have imagined. Due to an unexpected set of circumstances I am the lead organiser for WordCamp Cape Town this year. I am enjoying this tremendously as I am really looking forward to putting together an even that could change someone else’s life as it did mine in 2015. I also recently joined the WordPress community team as a Community Deputy, meaning that currently I assist with vetting new WordPress meetup groups as well as hold Meetup orientations.

I still want to start contributing to WordPress Core as well as Calypso, the WordPress.com product, so I am looking forward to the the newly announced New Contributors meeting. I’ve also started learning React in order to look at contributing to Calypso.

REST API powered plugin

This one is still coming, as I’ve decided to build it using React for the admin sections (similar to Jetpack) so I need to finish my React fundamentals course first.

Twenty Seventeen theme

Sadly this won’t be happening this year, but I am getting a lot of experience using Twenty Seventeen on the WordCamp Cape Town site, so perhaps that counts?

WPHackerCast

This will also not be happening, however another podcast idea has revealed itself which is a much more exciting idea and one that will benefit way more people, so watch this space.

So, not to bad as far as I can see. I think I’m pretty close to completing at least 4 out of the 5 before the end of the year. I’ll check back in December and see how it went. How’s your year going? Any goals you’ve set that you’ve either achieved or are on your way to do so?

What’s your Git Strategy?

As a freelance WordPress developer/consultant I rarely work in a team environment. So my usage of Git is mostly for my own purposes of being able to have my code backed up somewhere and the ability to create branches to try out new pieces of functionality without affecting the ‘master’ code base.

Recently I was chatting to Simon Dowdles, another Cape Town based WordPress developer, about this. He is, in his own words, very strict about a Git workflow. We agreed that it would be a good idea to implement a better system, so we put his workflow into place.

  1. Development branch is where all UP TO DATE and approved code lives
  2. Master branch is the truth and is ALWAYS what is on production
  3. Feature/hotfix branches are branched off of develop and only come back into develop with a Pull Request
  4. Release branches are made off of develop for releases, the release is done, merged back into master and tagged with the appropriate version tag (ie 1.2.0)
  5. Release branch is deleted, and there is only ever one

On the surface this all seems very obvious but it is often something that one tends to dismiss when working alone on the code base. After working with it for a few days however I can already see the benefits.

Lets first look at a real work example of how this would work in practice.

Setup

Firstly the repository is going to need a develop branch. So inside the root of my project folder I’ll create the develop branch from the master branch.

git checkout -b develop

And then push the branch

git push -u origin develop

If the develop branch already exists I can just switch to it

git checkout develop

Now I will need to create my feature branch, to make my code changes. So while still on the develop branch, create a a feature branch

git checkout -b feature/my-cool-feature

Usage

I can now starting coding my changes, committing frequently. I tend to commit every time I complete a chunk of functionality. So if I fix a bug, I commit. If I add a function and its more or less complete I commit.

git commit -a

At the end of every day, or if I am going to leave my workstation for a period of time, I push all current commits to the feature branch.

git push -u origin feature/my-cool-feature

When I am convinced it is good to go, I will submit a pull request or PR. When I create my PR I will request that it is merged into the develop branch, NOT master.

As we are using GitHub for this project I prefer to use the web based tools to create a PR, but most of the other cloud based Git services provide similar tools.

The rest of the team will review this PR, which will involve testing. They will scrutinise my code and provide feedback and I will fix or alter things to suit the team/project coding style(s).

Each time I commit the above changes, the team in the PR is notified and will see the changes in the PR.

When everyone is happy, they approve the PR and I merge my PR into the develop branch. At the same time I can choose to delete my feature branch (which I typically do)

The develop branch now has more (stable) code in it, and part of my PR should have been a version bump. (for example let’s say to 1.0.1)

Release

The team decides it is time to release version 1.0.1

First I need to make sure all my code is up to date

git pull

And then make sure I am in the develop branch. This is the branch that has all the approved code for the next release (1.0.1).

git checkout develop

I create a release branch called release/1.0.1 off of develop

git checkout -b release/1.0.1

The code gets deployed ( in this case its a WordPress plugin, so it means pushing all the code to the wordpress.org plugin repository, more on that another day 😉 )

 

I then merge the release/1.0.1 branch back into the master branch and tag it as release 1.0.1, again using all the GitHub PR, merging and tagging tools.

And we’re done, release 1.0.1 is in the wild and by following this approach, master is ALWAYS the truth. If for example release 1.0.2 were to fail, we simply roll everything back to master.

Wrap up

I’ve been working like this for three releases of the project so far and I have to say, once I had all the steps in my head, it did make developing, merging and releasing a lot smoother and more controlled.

Are you using Git as part of a team? If so I’d love to hear your comments on the idea of having a Git Workflow/Strategy.