Practice Makes Perfect

Many years ago a very talented famous American professional basketball player kept skipping team practices and it culminated in a press conference where he complained that “it was just practice” and not the game. In his opinion, it was the game that mattered, not how hard he worked. In other words, results-oriented thinking. He felt his natural talent (which was extraordinary even by the standards of elite-level play) was enough for him to succeed.

This was in sharp contrast to most of his other peers, who used practice as an opportunity to hone and refine their skills while also helping their teammates get better at the same time. For them, practice was the only time they had to try and get better when the stakes were the lowest. In other words, process-oriented thinking.

So what does sportsball have to do with programming? I’m of the opinion that practicing and refining your tools and skills (meaning process-oriented thinking) will lead to better outcomes. Our industry is clearly one that focuses on results-oriented thinking due to the huge amounts of money that are out there to be made solving problems for people. At the end of the day, we do need to get what we’ve been working on out there for people to use but in my experience, the journey can be made a lot smoother through, well, practicing.

For me I think there is a tripod upon which all your programming outcomes rely on:

  • operating systems
  • editor
  • language features

By refining and practicing your use of these three things, you build a very stable platform to keep building your own higher-level skills and help other people get better.

Operating Systems

There are two operating systems you need to worry about: the one you develop your code on and the one your code will be running on. They’re not always the same so it’s important to learn what matters when it comes to PHP:

  • do you have to deal with a case-sensitive file system?
  • how to you install libraries and other tools you might need?
  • where are the error logs located?
  • how do you stop and start services
  • how do you upgrade the OS itself?
  • is there an easy-to-use shell?
  • can you use tools with a GUI?

Lots and lots of weird behaviour in an application can be traced back to subtle differences between the development environment and the production environment. Understanding those differences can really cut down on debugging time. Practice things like removing and re-installing packages, or turning on automated system updates. Learn about file permissions. You never know what might be causing a problem: system error messages are often cryptic and not actually pointing at the real problem.

I have been a long-time Mac user and appreciate the combination of a terminal shell when I need to work from the command line and the multiple options in terms of helper applications. Here are some things I use just about every day:

  • graphical Integrated Development Environment (PhpStorm)
  • graphical Git client (GitKraken)
  • graphical MySQL client (Sequel Pro)
  • graphical HTTP client (Paw)

All designed to help me get things done faster while also fitting with my own “way of doing things”, which consists of finding tools that allow me to automate a lot of things I used to do manually. Much like my editor, I practiced with other tools to find ones that (to use a sportsball metaphor) “fit my game”.

Editors

As someone who has switched between a lot of editors over the years before settling on one (PhpStorm + Vim for everything else), I can tell you that you can definitely produce code faster by learning your editor’s features. Pick one and learn it really really well. It literally doesn’t matter which one you use.

Here are some things that I learned to do with my editor via deliberate practice:

  • refactoring
  • keyboard shortcuts
  • installing third-party plugins
  • configurable layouts
  • code generation
  • syntax highlighting
  • style checking

Spend deliberate time looking at these features and learn how they can help you. As a dedicated lazy programmer, I believe in letting the computer do as much of the work as I can under my watchful-yet-distracted-by-my-phone eyes. Your editor is the programming-related tool you will likely be using the most next to your brain. Pick one and learn it well — it doesn’t really matter which one.

As for all those features I mentioned above? I find them useful but they might not work for you. Try things out, deliberately force yourself to use them. When I was first using Vim, I forced myself to not use the arrow keys so I could master moving with the “traditional” HJKL keys instead. My interests are always aligned with automating things I am prone to make mistakes on so I can concentrate on things that require paying closer attention.

If people write books or create courses for better understanding your chosen editor, I encourage you to support their efforts by buying them and doing more deliberate learning and practicing.

PHP itself

I first started using PHP when it was making the transition from being purely procedural to having object-oriented features. To be sure, I did not keep up with a lot
of the changes because they just weren’t important…until I started having problems keeping my code organized as the projects got more complicated. Just like with my other things I suggest practicing on to learn if they “elevate your game”, here is a shortlist of features you should at least try before dismissing:

  • return types
  • parameter type hints
  • interfaces
  • abstract classes
  • final classes
  • traits
  • functional programming paradigms

Explore the language, practice things, and refine your “solving problems using PHP” skills. A lot of concepts I was struggling to understand their usefulness became a lot clearer with deliberate practice via tutorials. You might not find any of these features useful in your own PHP work, but think of them as participating in drills where you work on different sets of skills to try and improve your overall level of ability with the language.

Following tutorials and then trying to adapt the lessons to your own codebase is some of the best practice you will find. It won’t always work but I can guarantee you will learn something you didn’t know.

Practice Raises The Floor

There is an idea that people do not rise to the occasion when under stress — they instead retreat to their lowest level of “unconscious ability”. This is why a lot of athletes practice things with such conviction — they are trying to train their mind and body to do extraordinary things without having to actively think about it. We can do the same thing by practicing with our tools and PHP itself to raise our own skill floor. Every time I apply something new I recently learned, or take a look at a tutorial, I look at it as a chance to get better. Failure is a natural part of programming, so embrace the failures that come during practice as the learning opportunity they are.

Happy Holidays to those who choose to celebrate this year!

So PHP is no longer your day job…now what?!?

From 1998 until 2015, PHP was the tool I used to make the vast majority of my income. I built all sorts of things with the language, and worked my way through my career going from place to place trying to leave things better than when I got there.
I carved out a great niche for myself as “that guy who yells at you about testing your PHP code”.

Then one day I got a message saying “hey, do you want to come and work at Mozilla?” Almost a decade ago while speaking at a web conference in Vancouver I had met Laura Thomson, who had just started working there. Talked to her for several hours while a group of speakers stomped around
Vancouver.

Like the happy little networker I am, I stayed in touch with her over the years and asked her to keep me in mind if ever anything came up at Mozilla that would be a good fit. I interviewed there once before and got nowhere. But now was a chance to do something I was very interested in: work for a company where their mission isn’t to “disrupt” something or just to hang on long enough to get aquihired by one of The Four Horseman Of The Internet (Facebook, Google, Amazon, and Apple).

There was no way I was going to say no.

It didn’t matter that I wasn’t going to be using PHP at the day job any more. The group I work with uses Python to test the various web services that Firefox talks to. So I no longer was going to be using PHP at the day job. But my whole identity had been built up around the community of people using PHP. So now what? Should I speed off towards a new career and leave PHP in the dust? It would’ve been really easy to do so like many many other folks who like to make fun of PHP have done.

Instead, I stay connected with the PHP community so I give back to a group of folks who helped me build the life I have today. This is not a joke or hyperbole. Without the support of people who also believed in my mission of helping people to learn how to test their code, I wouldn’t have built up a skill set that lets me write tests in another programming language.

The community has helped me meet dozens of people and fly all over the world to convince other people that you can test your PHP code and you can build a satisfying career just like I did. Even though I don’t use PHP at the day job, I still work on open source projects that use PHP and will continue to spread the message that you can test your PHP code and continue to willingly write PHP code.

I can’t ever give back more than what I got from all of you.