Sarah Savage logo

A fusion of development and business

Twenty lessons from twenty years of PHP (Part 1)

I started writing PHP in 2003 when I needed to build an online game. While I had intended to use Excel formulas for the game, one of the players didn’t have Excel; this prompted me to learn PHP. Over the course of twenty years, I have learned many things. This is part one of the things that I have learned.

1. Programming is part skill, part art

It’s easy to think that code is simply designed to communicate with the computer running it. This couldn’t be farther from the truth. In fact, code is communication: we communicate intent and design to other developers through the code that we write. Other developers read our code (most code is read far more often than written), and they need to understand what we were thinking and doing with the code we write.

It’s helpful to think of code as a craft. We craft code the way we would craft a book or story. It tells a story: the story of our business logic and decision-making. Developers benefit when our code is clean, concise and communicates specifically the information we wanted to convey.

2. There’s plenty of work to be had in PHP

The death of PHP has been declared more times than I can count during my career. The fact is, there is a significant amount of code written in PHP, and there is tremendous opportunity to learn and grow as a developer in PHP. There’s tons of work to be had, and you can easily pay your bills with the PHP work that’s available.

That’s not to say PHP won’t decline. The advent of AI means that developers need to. be better at their work, because low-level tasks will likely be automated. Still, developers can benefit from doing the higher-level tasks that AI is poorly suited for: things that require thought, creativity and inventiveness.

There’s plenty of work in PHP. Don’t believe the hype; PHP is not dying, it is thriving.

3. Building a network is a key to long-term career growth

If there is plenty of work in PHP, finding it requires building a comprehensive network that can help you locate those opportunities. This is a lesson I have learned well: every job I’ve had in the past decade, and every contract I’ve found in that time, has come through a well-constructed network of friends and professional acquaintances.

Networks are not just for finding work: they offer a sense of community. They offer a collective sense that you are moving in the right direction, and they help provide context and information on things you might not otherwise be exposed to. I learn things from my network each and every day; from blog posts to hot takes, they provide information and thoughts that I would not otherwise have.

Build a network. It will be invaluable as you build a career.

4. Senior developers focus on solving business problems.

What does it mean to be a senior developer? Many job listings for “senior” developers require 5+ years of experience. But time is a poor measure for understanding what constitutes a senior developer. In fact, time has very little to do with “senior” status – there are decade-long developers who are still juniors, and there are two-year developers who can be categorized as senior.

What is the thing, then, that makes a developer “senior”? In my experience it’s a focus on one thing: solving the business problems that are in front of the developer.

I like to say “I’m a problem solver; sometimes I solve problems with code.” Senior developers are not interested in writing the most code; in fact, they recognize developing software as an incredibly expensive enterprise that should only be done when absolutely necessary. Instead, they seek solutions to problems, usually business problems, that are difficult and painful to the organization. They solve them, and sometimes they solve them with code.

You can be a senior at any level of experience. The key element is the ability to think in terms of pain points, not code points. Develop solutions, not software, and you’re well on your way to being senior.

5. The best framework is the one that serves your business interests.

Once you start to think about software in the context of solving business problems, you realize something: frameworks are tools. Nothing more, nothing less.

As tools, frameworks are incredibly powerful for solving common problems of software development. They offer an infrastructure for solving common tasks that most developers experience. But they are tools – they offer a solution and an opinion on solving a particular set of problems – and they should be treated this way.

Many developers treat their framework as a near religious obsession. The “framework wars” are a common thing on Twitter, Mastodon and other platforms. It’s time to put down our weapons and pick up our tools as what they are – solutions to problems we have. Perhaps your framework is particularly good at one aspect of software development. Great! Use it. But when the problem space is outside your framework, find another tool.

Michelle Sanver says in her keynote talk “Community, PHP and us: Growing up” that we should speak kindly of all frameworks. This is true. We would not insult a specialty hammer just because it cannot drive our kind of nail, so why would we insult a particular tool just because it doesn’t meet our use case? Speak kindly – be kind – and remember, frameworks are tools. The best one solves your problem.

6. Perfect is the enemy of good (enough).

Developers can be perfectionists. I am, and I know many that are. Yet there’s a truth in the fact that “perfect” is the enemy of “good”, and “good” is often equal to “shippable”.

Code that sits in a repository or on your hard drive but doesn’t serve customers may as well never have been written. It’s not worth much, because at the end of the day it doesn’t do the job it was written for. That’s not to say experimentation or “writing one to throw away” isn’t valuable – learning certainly is – but code that you intend for production that never makes it doesn’t have much value.

Refactoring is something you can always do later, especially if you have good tests. Good tests enable you to refactor without struggling to know if the functionality is identical, and then you have the option to put new polish on an old code base. But remember: shipping code is the priority, serving the customer is the priority, and solving problems is the priority.

7. You always know enough to teach someone else.

The best way to learn something is to do it. And the best way to know how well you’ve learned it is to teach it to someone else.

The truth is that you know things other people don’t. So teaching those things is something you can do. Anyone can teach what they know, and teaching is a great way to advance your career as well as share your knowledge with the community.

8. Someone else always knows more about something than you – be humble!

Humility goes a long way – especially when you find someone who knows more about something than you do. Someone will always know more about a subject than you, and you want to give them an opportunity to teach you and others about it.

For example, I know XDebug pretty well – it’s a tool that I use each and every day. But Derick Rethans, the creator of XDebug, will always know more than I do. I allow him to teach me, because it’s important for me to learn from the expert. And I don’t take it personally when a conference accepts his XDebug talk over mine.

9. You should never stop learning.

As a developer, you never stop learning new things. Not only is there an abundance of things to learn, but there’s never a shortage of things we could stand to learn more about.

Continuous learning is the way to becoming a better developer, better expert, better employee or business owner. It ensures that your skills stay sharp and fresh, never going out of style. Continuous learning is also fun and exciting – it’s an opportunity to grow your knowledge base, explore things that are interesting to you, and experiment with cool new technologies. Even if what you’re learning about isn’t immediately relevant to your daily work right now, that doesn’t mean it won’t be relevant in a week, month or year.

10. Become an expert (at something).

Many developers think the trick to being successful is to master the “full stack.” I’m here to tell you that’s not true.

Expertise, niching down, learning deeply about a particular topic makes you more valuable than being a generalist who does a little bit of everything.

Become an expert at something. Learn deeply about something you care about, and then be the expert on that thing, so that when people need your skill, they immediately think of you. While you’ll always be learning (see point #9), you’ll also be deepening your understanding of your focus area, and improving your value to those who need that area of expertise.

Part 2 coming next week…

Thoughts? Leave a reply

Your email address will not be published. Required fields are marked *