Drupal has been around for a long time. Officially, it’s been around for at least 20 years.
Even if you jumped on the wagon around Drupal 5 or 6, that is still over 12 years of Drupal. You might have started to look longingly at the greener grasses of other ecosystems, new technology stacks, and polished products that feel fresh and new.
Burn-out happens. Disillusionment happens. Boredom happens.
If you stare at something long enough, you start magnifying all of its flaws and forgetting some of its virtues. Familiarity breeds contempt. We get it.
But there are reasons to stick with Drupal, and there are ways to get excited about it again. You might not be able to relive the honeymoon phase back when you first installed it, but you might be able to have something better: a mature, trusted partnership.
It’s not you, it’s me - get realistic
It can be frustrating to feel like you are in a rut. Drupal is old. PHP is even older. Neither one is the new kid on the block anymore. Everyone else looks like they are having the time of their lives playing with new stuff.
There is always something exciting happening in the Javascript ecosystem. Products like Contentful and other JAMStack solutions come along that feel fresh. Even WordPress looks like it’s having more fun.
But let’s be realistic.
Drupal can help you solve real problems. In many cases, Drupal will help you solve them better than any other toolset on the market. There is still excitement to be found in helping solve these complicated, thorny problems.
Problems like:
- Allowing large teams to manage large repositories of content.
- Modeling content to match an organization’s domain and having that content be served anywhere.
- Multiple editorial teams serving multiple audiences, each seeking out content in multiple formats.
While it sometimes feels like all cool kids have moved on to greener pastures, Drupal has matured and found a steady groove. It is content to sit by the fire on a Friday night with a good book and a hot cup of tea. It can look back on its youth with fondness, maybe a little embarrassment, and be confident about the future. It doesn’t need to chase after invitations to the hottest parties.
The Drupal community remains solid. It does a great job watching out for issues related to backward-compatibility, stability, and security, and all of this work is easy to take for granted. Virtually any customization can be built on its shoulders.
Yes, Drupal has changed. But haven’t we all? You might need to shift your mindset. Why did you start using Drupal in the first place? Was it to chase the newest technology? Was it to help you solve particular problems? Clarify and think deeply about your “why.”
Even if you leave the Drupal ecosystem, one thing will remain a constant no matter where you go: yourself. Be sure the disillusionment you feel isn’t baggage you will be carrying with you.
Even if you leave the Drupal ecosystem, one thing will remain a constant no matter where you go: yourself.
Remember that newer technologies are built by people. Other communities are made up of people. No matter what toolset you are using, you will be solving problems for other people, defined by other people.
And whenever people are involved, you get people problems. Some problems are more obvious than others, but you could find yourself jumping to another ship already full of holes, taking on water.
To summarize:
- Be realistic.
- Know yourself.
- Set proper expectations.
If you do these things, you might find that Drupal isn’t so bad after all. In fact, it’s still pretty great.
Double-down and dig deep - lean into craftsmanship
Come for the code; stay for the community. For many excellent reasons, that’s the motto that many people still recite and believe in.
But what if you’re burned out on the community?
You can always stay for the code.
Drupal’s codebase indeed feels bigger and more complicated since the switch to Drupal 8, but at the same time, the code has never been more transparent. Code organization and typehints allow for better IDE (Integrated Development Environment) autocompletion. It has never been easier to discover how things work.
By making it a habit of going down rabbit holes, you can gain knowledge of Drupal’s internals, and this knowledge comes with a fulfilling sense of capacity, flexibility, and usefulness. This level of introspection allows you to build features that are as extendable as Drupal itself.
Solving problems with confidence is addicting. It may feel unintuitive to cure your disillusionment by diving deeper. It feels like the opposite of what you want to do.
But it can spark a new passion. So try doubling down. Set up your debugger and step through some code.
Start with one of the subsystems, like cache invalidation. It has a lot of moving pieces, touches different parts of the Drupal codebase, and is a big infrastructure improvement from previous versions of Drupal. Not many people have a deep knowledge of its inner workings, and knowing how all the joints fit together can enhance the solutions you build.
Or maybe you are curious about the full render pipeline. Or the CKEditor integration? Whatever it is, get curious and find some focus.
Gaining this deeper expertise and understanding can help you solve deeper problems an organization may have. You can start creating deeper solutions that have a more long-lasting impact. These can come in the form of performance improvements, better code maintainability, or better automation. You will be able to tackle more complicated problems and architect more elegant solutions.
Some other things to do to improve your craft while also directly benefiting your projects:
- Focus on maintainability by mapping custom code to S.O.L.I.D. principles.
- Extract and segregate business logic into typed entities. This also means learning how to ask better questions.
Embrace the archipelago - trade and share
Since the advent of Drupal 8, we are fond of saying that Drupal finally moved off of the island. We embraced Object-oriented best practices. Symfony components now power many of the underlying subsystems that Drupal depends upon. We shed more of our “not invented here” approach.
Except it’s not entirely true that we left the island. There are still many things unique to Drupal, and to implement Drupal at scale, you need to have deep Drupal expertise. Not just Symfony or PHP expertise. Drupal expertise.
However, we did move our island closer to all of the others. Our ports participate in more shipping lanes and trade routes. We became more conscientious members of the open-source archipelago.
If you are feeling antsy to get off the Drupal island, lean into this.
Don’t just build things for Drupal. Look for opportunities to extract logic into separate libraries with full test coverage, then loop them back into Drupal. Centarro did this with currency formatting for PHP applications. Lullabot did this with an AMP PHP library that anyone can use. Thinking this way presents new challenges and introduces you to new conversations.
Drupal’s commitment to content APIs, like JSON:API, opens up more opportunities to interface with various Javascript technologies and their communities. Building a front-end for Drupal no longer means you have to work exclusively in Drupal. React, Vue.js, and many other frameworks are waiting for you to explore.
Even without committing to a fully decoupled front-end, you can still flex these muscles in creative ways. For example, you could create a widget registry that contains reusable pieces of content. These widgets can be served on Drupal or anywhere else.
It has never been easier to island-hop while maintaining a home in Drupal. Likewise, it has never been easier to grow skillsets while working in Drupal that will serve you well if you do eventually decide to leave.
This leads to our final point.
Focus on transferable skillsets
We have already hinted at this. When you double-down on becoming a great Drupal developer and getting familiar with the internals, focusing on object-oriented best practices, you will find yourself right at home if you start developing a Symfony application.
Likewise, the Javascript you learn to consume Drupal APIs doesn’t care where the content comes from. The skills you learn will transfer.
If you feel disillusioned with Drupal, focusing on these transferable skills can help you get excited again because they can only open more opportunities for you. You won’t have a voice in the back of your mind whispering that you are stuck. With this comes confidence, and with confidence comes excitement.
As Drupal has matured, so have the tools surrounding Drupal. Package management, automated testing, and DevOps are all things you can learn about. Not only will they help your current projects, but they each present marketable skills outside of Drupal.
Deep knowledge of Vagrant, Docker, and some of the continuous deployment platforms have an immediate payoff and will pay dividends in the future.
Drupal doesn’t have to be your final destination. It is a useful partnership of opportunity. It can be a springboard to other things. Sometimes, recognition of this fact alone is enough to spark some excitement.
Knowing you can leave any time you want makes it easier to stick around for a while.
Conclusion
Drupal has been around a long time, and sometimes it can be hard to maintain enthusiasm and excitement for it. But it can still help you solve difficult problems. Sometimes, you just need to shift your mindset a little.
Dig deeper and find joy in craftsmanship, try to package up libraries to trade with other communities, and recognize your ability to build a transferable skill set.
It’s hard to overcome burn-out, and you might need to step away. But if you leave, be sure you do it with clarity and intention, making sure you don’t leave anything valuable on the table.
Thanks to Mateu Aguiló Bosch, Marcos Cano, Andrew Berry, Mike Herchel, and David Burns for contributing ideas to this article