Earlier this month, at Mid Atlantic Dreamin’ in Philadelphia, I gave a talk titled Software Super Heroes: Building the tools you wish you had. My goal with the talk was to convince people that should, can, and in fact do, built tools for themselves. If you work with technology, and your job involves repetitive tasks the same applies to you too.

What do I mean by “Tool” and “Tool builder’s mindset”?

I like to use a very expansive definition of tool: “A tool is anything that makes a task easier which would be repetitive, hard, or impossible without it.” In that sense just about anything you make that simplifies you work can be considered a tool: a project estimation spread sheet, a good set of directions for a complex task, a flow for a Salesforce admin, a piece of code to normalize a large collection of files, and more.

My intention with that expansive view is to help encourage people to take on a tool builder’s mindset.

To be a digital tool builder does not require knowing how to write complex software, it just requires you to do what you already do now, but with intention. When we use a broad definition of tools, it’s easier to see ourselves as tool builders, even if we’re just talking about a spreadsheet or a Salesforce flow meant to handle an administrator’s daily tasks. When we see ourselves as tool builders we are more likely to make something worth using more than once.

Why does this matter?

When we approach problems with a tool building mind set, instead of insurmountable challenges caused by gaps in our tooling, we see opportunity to create something new to make the impossible possible. Instead of facing hours of boring repetitive tasks, we have chance to build a more interesting special purpose solution.

Fight the Tool Building Excuses

There are several excuses I commonly hear from people when I encourage them to build their own tools. They range from concerns about not having the right skills, to assuming someone else already built that tool or that the time required isn’t worth the effort.

My general response to these concerns is that while people should indeed look around for tools that already solve their problem, and that some problems are very hard to solve completely, if you start to chip away at a complex problem you often will find that you can create tools that are good enough to save you time and effort.

Don’t try to build the perfect tool that solves all possible edge cases on your first go. Create a tool that takes out some annoying and repetitive task. Then create a tool that solves for another task, or builds on your first time. Chip away.

I often tell developers who are early in their career that I should never see them doing rote repetitive tasks for hours on end. Instead once they understand how a repetitive task is done, they should start thinking about how to build a tool to take over. But that’s not just advice for developers: we invented computers to do repetitive asks (calculating artillery firing tables and cracking codes), let them do that.

Pick Your Tool Building Path

When you set out to create a tool you have two main options: use something you already know, or use tool building as a chance to learn something new. I’ve used tool building as was to teach myself new features of Excel, Google Sheets, Salesforce Flows, Git, and several programming languages. This can be a great way to learn how to use the tool that’s just right for the job. But learning a new tool or technique takes time, and if you have a deadline you may need to move faster.

Personally I try to take both paths from time to time. I use things I know when: they are exactly the right tool, I am under time pressure, or I want to keep my skills sharp. I will take the time to learn something new when: it’s something I need to learn anyway, I am building on my own time, or it’s exactly the right tool for what I need to do.

Neither path is correct 100% of the time. By using them both I am able to create the tools I need, and broaden my skills over time.

Just Start Building

The next time you’re faced with a task that is repetitive or hard with the tools you have: create yourself something new. Don’t get hung up on being perfect, just create something that’s better than what you have at the start.

Then save your tool to use again later. Share it with colleagues, friends, or as an open source project.

When in doubt, just start building.

The post Tool Building Mindset appeared first on Spinning Code.

Posted on behalf of the Drupal accessibility maintainers and written by Mike Gifford.

Drupal has built a reputation around being standards compliant and accessible. Drupal made an early commitment to meeting the Web Content Accessibility Guidelines when building Drupal 7. In Drupal 8 this was expanded to support the Authoring Tool Accessibility Guidelines. Both times the release was delayed to help make it more accessible. The Drupal community is always working to be more inclusive, and accessibility is a big part of this. 

The GAAD Foundation nominated Drupal for the 2022 GAAD Pledge. Accessibility is a cornerstone of quality open source projects. Other winners have included OpenFL, EmberJS, React Native, and most recently Joomla! 

The GAAD Pledge committed projects to formally update their guidelines to WCAG 2.1. Drupal is currently developing to WCAG 2.2 AA, which is the latest W3C WCAG Recommendation. 

We have published a draft Accessibility Coding Standards, and we are still working to enhance this guidance. The Accessibility Team has documented many of the best practices that we have built into Drupal. Our Accessibility Coding Standard document has been useful in educating our community about best practices.

We have been tracking accessibility issues in Drupal Core and Contrib (themes and modules) under the accessibility tag. This is already a long-standing practice, and we have a total of 1063 open issues in our issue queue. If we look just at Drupal 11 accessibility bugs, there are 510. For Drupal Core, this includes known accessibility issues, but also issues which could affect accessibility. Bringing it down to those which have been tagged against a WCAG SC, there are only 188 issues. Even these issues are mostly edge cases which do not affect most users. 

These are still too many errors, but it is about proving progress, over perfection. Drupal is still evolving, as our Starshot project demonstrates. Our community is constantly striving to improve the user, developer and author experience. 

Let’s reach for the stars and bring the Open Web to all.
    — Dries Buytaert, creator and project lead of Drupal

The WCAG Success Criteria (SC) which fail most often in Drupal are: 

• 1.1.1 Non-text Content 
• 1.3.1 Info and Relationship 
• 1.4.3 – Contrast Minimum 
• 2.1.1 Keyboard 
• 2.4.7 Focus Visible 
• 3.1.2 Language of Parts 
• 3.3.1 Error Identification 
• 4.1.2 Name, Role, Value 

This has also helped us create an Accessibility Conformance Report (ACR) using the US General Service Administration’s OpenACR. Our current process is outlined Drupal and ACRs. 

We always need more members of the Drupal community to become involved. The earlier we catch accessibility issues, the cheaper it will be to fix them, and the more robust our solutions will become.  We also hope that everyone takes time to engage in Global Accessibility Awareness Day, where we can share best practices and learn from each other. 

Image used with permission from Michael Richardson from Ironstar.io.

I took a lot away from DrupalCon Portland 2024, and while one of my lasting memories from the main keynote (the Driesnote) will be the introduction of Starshot, something that has occupied a good amount of space in my brain is what happened just prior to Dries’ Starshot announcement.

At the start of his presentation (the 21:15 mark of this video,) Dries asks everyone with at least one year of Drupal experience to stand up. He then asked everyone with less than three years of experience with Drupal to sit down. The results were scary. As Dries reacted:

Oh wow. Almost nobody sat down.

This really shouldn't surprise anyone who has been developing Drupal sites for more than a few years. Drupal 8+ (modern Drupal) was considerably more difficult to get started with, and definitely geared toward more experienced developers.

Another data point

The 2024 Drupal Developer Survey results were recently announced (thanks to Ironstar.io for the huge effort in making this happen) and while there's a ton of great data in there, I'd like to focus on the Age and Experience section, which shows that only 9.1% of the 648 respondents were under the age of 30, with no respondents under the age of 21 (insert standard disclaimer about survey size and sample and this not necessarily being a scientific survey.) This is troublesome.

Maybe we shouldn't be focusing on age, but rather experience. However; the How long have you been working with Drupal question results didn't make me feel any better. Only 9.6% of the respondents have been working with Drupal for less than 4 years. Yikes.

Is this as scary as it looks?

I really don't know the answer to this question. Both of the data points listed above are somewhat anecdotal. The first can be mitigated by the fact that you're probably much less likely to attend a DrupalCon if you're new to Drupal. The second can be accounted for by the assumption that only folks who are experienced enough with Drupal to be on the right mailing lists and/or follow the right social media accounts would know about the survey in the first place.

All that being said, I don't think the trend that the data is showing us is wrong: Clearly Drupal needs new developers.

What's the solution?

Obviously, there's not a single solution. I think there are a few things that we (yes you,) the Drupal community, can do to help entice new developers to Drupal.

1. Keep Drupal's code modern - we do a pretty good job of this, but we can definitely do better by better integrating with front-end developer/designer tools like Storybook and whatever the cool Javascript front-end tools are this month (mostly kidding, of course.) These efforts are critical, but these types of solutions tend to be longer-term.
2. Get more people using Drupal - the more people using Drupal, the more likely they'll become invested in the platform and likely to become full-time Drupal developers. We don't need to convert all Drupal users to developers, just a portion. Clearly, Drupal Starshot is a well-placed effort to do this, but again, I think it'll be a bit of time before this has a significant effect.
3. Create programs that introduce Drupal to students - as a Drupal trainer who is active in the community, I've heard about a few attempts at this in local communities, but nothing at scale. This is definitely a long-term goal, and will take time, money and leadership from the Drupal Association, including a hopefully re-imagined and more ambitious Discover Drupal program. 
4. Entice organizations that build Drupal sites to hire new developers - Money (in this case job opportunities) talks. If there are entry-level jobs in Drupal, then new developers will come. Of course, there are plenty of jobs in Drupal, but not the kind of entry level positions that are going to provide an on-ramp for aspiring Drupal developers. If jobs for those new to Drupal aren't there, then the effect of the first two items above will be muted. There is an exciting, thoughtful short-term solution to this called the Drupal IXP community initiative, which will (hopefully later this year) begin to incentivize organizations to hire new, inexperienced ("IXP") Drupal developers in exchange for Drupal community contribution credits. You can get involved with IXP today by completing this survey to help us figure out which skills a new Drupal developer should have (survey closes June 1, 2024). 
5. Attract good Drupal developer candidates with a leg up  - Companies (like Palantir.net,)  who have become involved in scholarship programs, including (the currently dormant) Discover Drupal (which aimed to not just build the Drupal talent pool, but do it with an eye toward diversifying our ranks,) and providing their own training scholarships, initiating internship programs and providing mentors for newbies have had success in building their talent benches over time by training up the people that are a good fit their organizations. It takes a bit of investment and patience, but the returns are usually worth it.  

How can you help?

If this nagging issue of too few new Drupal developers is becoming a growing concern for you, like it is for me; then perhaps you’d like to get involved in one of the above efforts to help move things forward and, maybe even spread the word to help inspire others to get involved as well.   

Acquia’s partnership with Conductor marks another milestone in our journey to deliver the best-of-breed digital experiences for our customers. The collaboration between Conductor and Acquia will concentrate on incorporating the advanced SEO insights of Conductor's premier organic marketing platform into both Acquia's Open Digital Experience Platform (DXP) and its Drupal CMS. 

As part of this partnership, Acquia has developed a new Drupal module called Acquia SEO Content Insights powered by Conductor. Creating compelling content requires leveraging SEO insights and content intelligence, and the subsequent publishing and administration of this content are contingent upon a strong content management system (CMS).