What the hell is $x?

I’m currently in the process of writing my first technical book. I chose to write it on a topic that is close to my heart; how to effectively work within a development team, on a code-based level. It’s going to be about what you can do to the way you develop, and the code itself to make the development environment easier for yourself, your colleagues and contributors. Below is a preview of my book’s introduction.


WHAT THE HELL IS $X?

This is a great question; what the hell is $x?

$x is of course, as you may recognise, a variable in the PHP syntax. It is anonymous, it is elusive, it is ire-inducing. $x is the poster-boy for bad variable naming. It is indicative of everything I despise about working in a development team where multiple developers share a code-base. Whatever language you develop with, you’ll find things like $x in almost every code-base you’ll see in your career. It tells us nothing.

It is a manifestation of an attitude to development that is deemed healthy from the product point of view, but unhealthy from the engineering point of view. It’s focus is on speed of delivery, rather than sustainability of the codebase, when in reality, a delicate balance needs to be struck between the two. Throughout this book, I will hope to illustrate why, and what we can do to reduce the appearance of artefacts such as $x.

WHY DO I CARE?

One thing I’ve learned, as I slowly make my way through this journey of life, is this: You cannot control what other people do, you can only control what you do. This, really, has served me well as part of my ethos for working. When working with others, you’ll undoubtedly come across developers you disagree with, product managers who make decisions that you wouldn’t have, managers who you feel don’t have your best interests at heart, CEOs who compel you to do things you’d be otherwise unwilling to do.

It is a fact of life that everyone is different. Why then, would a developer’s approach to development standards, or their ability to work effectively in a development team be any different? It too would suffer from the same variation in behaviour, or adjusted priorities that sit as a contrast to your own.

Throughout the decade of my work in various industries as a developer, I’ve noticed that I’ve become extremely opinionated about the way others develop. My co-workers develop differently, and (in my mind at least) it was by definition, wrong. It took me some time to realise that it was simply me with the wrong attitude, they didn’t do anything wrong, and they even took the time to ensure that their code adhered to the relevant PSR standards.

When I started work, I was somewhat alone — I was the sole developer in a fast-moving design agency. There were plenty of employees, most of them were print-based designers, others were 3D designers, motion graphic designers, there were administrative staff, production staff, directors, and then there was me. At the time of joining the company; website development was a somewhat new field for them, I wasn’t just their token developer, I was helping shape an emerging department, it was very exciting. It was perhaps this then, that in-turn shaped my own development ability, and my deeply biased opinion on style and standards.

I wanted so desperately for my new department to succeed that I became fervent in my pursuit for development perfection. I needed my code to be flawless (with the benefit of hindsight, I can tell you here, now, that my code was awful). I worked at the company for around four years in total, and it was only in the final year that the workload increased to such an extent to warrant an additional hand. At the time, I thought of my new colleague as beneath me; a superiority that I had cultivated with the manure of my own self-importance. In truth, he simply developed in a slightly different way than I. He knew the platform well, was effective at tackling solutions, he just didn’t prioritise code style and the ‘correct’ way to do things.

Maybe it was the three years of working in isolation from the criticisms of others that generated this attitude in me, who knows.

Upon leaving the design agency, I started working for an Ecommerce development house. I was part of a team now, a cog in the wheel. There were those who were far more advanced than I, and those that still had much to learn. I was bombarded with a veritable smorgasbord of development styles and alien ways of architecting solutions. It was into this cauldron of differing styles that really caused me to become more self-reflective. I needed to look at the way I was doing things and not focus on others.

I couldn’t control the Linux distro selected by the CTO for our deployment servers any more than I could control the maverick approach to tabbing and spacing in too-long JavaScript files that one of my peers had. I slowly began asking myself the question “What can I do, to make this environment better for everyone?”

LEADING BY EXAMPLE

I’d been working on a utility package for use with a Magento 1.8 extension. It was composer enabled, PSR-4 namespaced package that would slot seamlessly into the extension we were constructing. I’d built it from scratch, and it was a masterpiece — to my endless supply of self confidence.

Then, I took ill. My colleague was forced to pick up the remaining bits and pieces to complete the package. I was dreading it. His style was vastly different to mine, I was certain he’d mess it up. He didn’t. When I returned, I took some time to inspect the code he’d written. It was semantic, descriptive and succinct, stylistically matching the classes I’d written and his new methods were sitting alongside my own with pride.

This is where it hit me; in order to make my own development environment better, I need to lead by example. Stop pointing out flaws in other peoples plans and just focus on my own, make sure what I do is perfect and use it to inspire others to do the same.

ABOUT THIS BOOK

So here we are in the opening of this book. This book isn’t meant to be an instruction manual of the standards you should be using in your projects — there’s plenty out there on that already, but instead it just presents the various tools and ideas at your disposal and shows you the how and why of using them to improve what you do. This is a clear way to improve the way that you develop — not so much from an achievement standpoint, but from a team-working perspective. We’ll be attempting to reduce the negative comments you encounter on code reviews, and trying to improve the re-usability of your code for years to come.

By the end, you should be able to effectively answer the following question:

What can I do, to my code, that’ll vastly improve the development environment of everyone around me?

This book will mostly be utilising examples and syntax from PHP, but that’s simply because it’s my language of choice. Most (if not all) of what’s discussed therein will apply to other languages.

You may find that certain examples or chapters will contradict others. This is intentional; development communities offer many conflicting schools of thought for how to do things, this book simply presents the arguments and provides you the ability to form an opinion of your own.


I’m hard at work completing this book in my spare time and I hope to complete before the end of Q1 2016, but we’ll see how it goes.

It will be released in eBook form on LeanPub, as well as some other avenues that I’ve not yet explored.

Disclaimer: This was originally published on my blog.

Show your support

Clapping shows how much you appreciated Dan Hanly’s story.