Paid Software and what to do.

Learn the tool once, benefit for a decade. That’s compound interest for your career.

If you’re committed to long-term projects—whether it’s a PhD, a book, or building your career—then mastering the right tools and workflows isn’t optional. It’s foundational. A John Kitchin quote that’s stuck with me for nearly a decade captures this perfectly:

Scientific publishing is a career-long activity, and one should not shy away from learning a tool that can have an impact over this time scale.

This is true for anything you spend time doing. Tools for accountants, programmers and writers. A message I provide to individuals I mentor is learn tools that have long term impact allowing benefits to compound.

I’ve wrestled with this myself, indeed I’ve grappled with before in the sciences and within IT, but I was really struck by EndVertex video - For-Profit (Creative) Software. Here EndVertex clearly breaks down the issues she has with the energy barrier to learn a new tool within the creative field and what happened when companies inevitably destroy the products we need to make a living.¹

Not only is this a cost of time but, as she highlights throughout, this can have a monetary cost as well. Some software she highlights is only viable for enterprise users where someone else foots the bill. Lose your job, and you are locked out of the thing that could help you land another.

So what is the answer here? Well EndVertex lays out some options:

• Prioritize open-source tools to avoid dependency on corporate software.
• Join creator communities for support, shared resources, and learning.
• Keep learning: Stay adaptable by exploring new tools regularly.
• Support open projects—through donations, advocacy, or contributions.
• Choose tools wisely: Invest time in those likely to last.

I agree with most of these, especially the point about making communities. Something that I believe is not only the antidote to megacorps. ruining our software, but also a sustainable way out of the current political hellscape we are in.

The big takeaway, however, was her focus on learning fundamentals. In her example, if you learn node editing then your skills should, at least in part, be transferable to another product that uses the same approach. Taking time to learn how the software works, not just what it can do. This is something I’ve internalised a long time ago and something I encourage everyone to reflect on.

I’d love to hear from you: What foundational tools or principles have made the biggest difference in your journey? Drop a comment or connect with me. I’m always up for exchanging ideas.