Notes from WordCamp Phoenix

This week, I’m speaking at WordCamp Phoenix (my first time in Arizona!). My talk is called “Think Outside the Block”, and covers the myriad ways you can customise the block editor.

Here’s the talk description, and the slides are below.

The block editor in WordPress (aka Gutenberg) offers a structured way of creating content through customizable “blocks”. But building custom blocks isn’t the only way to extend the editor; you can also register sidebars, enable custom toolbar buttons, and much more. In this talk, you’ll learn how to use these extension points to transform the block editor… without building a single block.

The Gutenberg Crisis

A few years back, Matt Mullenweg implored us to “learn JavaScript deeply”. As the Gutenberg project kicked off not long after, it quickly became clear why: Mullenweg’s dream of a reworked, rethought, reimplemented administrative experience for WordPress was largely a JavaScript-fuelled dream, powered by the magic of the React framework. PHP, long the primary language in any WordPress engineer’s tookit, was relegated to “implementation detail” status: still a useful skill, but really just for writing API endpoints to be consumed by the JavaScript front-end.

Whether he was conscious of the change or not (and I think he was, but that’s another minor detail), Matt’s warning has set off what I would describe as an existential crisis in the WordPress community — even though I don’t think we’ve fully understood what it means, and the impact it will have.

The crisis, in particular, is a serious lack of strong JavaScript and React talent in the WordPress community, and the hiring imbalance it creates. These engineers were already in high demand in other disciplines within tech; with the world’s most-used CMS now embracing React + JS, the demand scales have been tipped even further. There has truly never been a better time to be a JavaScript/React-focussed engineer.

But for companies who are just (still) coming around to the idea that WordPress requires React skills, the challenge is daunting. JavaScript talent is already tough to come by, and while the WordPress team (and let’s be honest, Automattic’s engineers) have done a great job of documenting the basics to help transitioning PHP developers, any organisation with a sufficiently complex implementation is going to quickly bump into challenges that only engineers with strong React skills are going to be able to solve.

Now just over six months in since its official launch, it’s clear that Gutenberg is here to stay, we’re seeing the start of this crisis. The smartest agencies and organisations saw the writing on the wall and have been recruiting JavaScript talent, but many companies — especially those who can’t manage the top salaries commanded by skilled React engineers — are in a tough spot. Should they be focussed on re-training their existing engineers? (Hiring is expensive, after all.) Should they be replacing groups of PHP-oriented engineers with smaller teams of high-impact JavaScript developers?

And what will the impact be for the teams navigating this change? Some organisations opt to keep their existing engineering teams and augment them with a React-focussed team; others embed the React engineers throughout the engineering organisation. Both approaches are valid, and they both have downsides. The “React skunkworks” allows you to move faster, but at the risk of isolating knowledge. Spreading the talent is good for ‘lifting all boats’, but propagates change much more slowly; and your expensive React engineers end up focussing most of their time on teaching and mentoring instead of really engineering. Unless they genuinely love the educational process, it quickly turns into “just give me an API and I’ll handle the React bits”; that’s no way to build strong knowledge across your teams.

So where will things go from here? I genuinely don’t know. I think it’s clear that this crisis is just beginning, and will certainly get worse before it’s better. Teams will be restructured and reorganised — multiple times, likely — as engineers are forced to change their skillsets and adapt to the front-end reality. Boot camps and online training courses will go through their own boom-and-bust cycle. The most talented JavaScript engineers will move from ‘low six figures’ to ‘mid-six figures’ (who will be the first $250k JavaScript engineer working in WordPress?), and PHP developers will scramble to get there too.

(And all of that barely dives into the impact this will have on the WordPress ecosystem: the realignment of power among third party plugin and theme developers, the emergence of new community superstars, the shift in WordCamp programming, etc. The crisis grows.)

So the best advice I can give is: work quickly to re-evaluate how you’re screening talent. Allocate time for your existing teams to retrain. Open the lines of communication with your engineering managers to determine how to start integrating Gutenberg workflows into your teams.

The crisis will get worse before it gets better, but the writing is on the wall. Now is the time to start adapting. Adopt JavaScript deeply.

You have no choice.

5 outcomes for great code review

As a technical lead, senior engineer, or technology director, code review can be one of the most valuable and force-multiplying tasks during your day.

Code review is often thought of by new managers or leaders as simply about identifying bugs, but I think it’s more than that. Especially when you’re working with junior developers, code review is an educational tool. It’s a chance to help your team learn best practises and write code that remains stable and reliable for years to come.

In my code reviews, I aim to:

  1. Identify bugs. As noted before, this is the most common thing people think about during code review, and of course it’s true: it’s an opportunity to identify mistakes or bugs before they make it into the code. As a technical lead, you might not have time to personally QA every pull request, but you can at least spot typos, mistakes, and obvious errors.
  2. Reduce fragility. As you gain more experience and move into senior and leadership roles, that should also come with a better understanding of where code is most fragile. Fragile code isn’t easy to identify for less experienced developers, but will likely jump out at you. Maybe it’s a particularly complex regex, a function with multiple return types, or an interaction with a finicky third-party API; you probably have a sense of where things might fall apart, and this is your chance to prevent that.
  3. Increase clarity. Clear, well-documented, easy-to-read code isn’t just a matter of preference: it’s an insurance policy against future change. However that manifests for you (I like to encourage inline comments, sufficient white-space, and clearly named methods and variables), it’s important to set the standard and
  4. Reduce complexity. This goes hand-in-hand with reducing fragility, but takes it slightly further. Junior developers can fall into the easy trap of writing code that’s too complex. That might mean a few too many conditionals in a method, or choosing a solution that is clever, but perhaps a little too intricate. Not all fragile code is complex, but all complex code is fragile. Be mindful of where you introduce complexity, and limit it where you can.
  5. Enforce consistency. As a lead engineer, you are one of the few people with a comprehensive, 360º view of your codebase. As such, it’s implicitly your job to make sure the code that enters the codebase is consistent. You can get some help with this from automated linting tools and good documentation, but code review also gives you the opportunity to add context, so you can explain whyyou enforce those requirements.

With these outcomes in mind, your code reviews will not only be a defensive tactic centred around avoiding mistakes and bugs, but they will also help you stay on the offensive by actively building reliability, predictability, and consistency into your code.

Great code review ensures you avoid the bugs of today while preventing the bugs of the future.

Goals for 2019

(In no particular order)

  1. Read more
  2. Write more
  3. Research more
  4. Move to Brooklyn
  5. Sketch more
  6. Slow down
  7. Regain my focus
  8. Meditate consistently
  9. Practise yoga consistently
  10. Read The Field Study Handbook
  11. Apply The Field Study Handbook
  12. Cook more
  13. Eat more vegetables
  14. Think bigger
  15. Write a newsletter
  16. Build a product
  17. Do more with Notion
  18. Travel to 3 continents
  19. Pay down debt
  20. Spend less time in Slack
  21. Act asynchronously
  22. Be online less