Recently, a friend let me know that the SQL style guide I wrote was back on Hacker News. Against my better judgement, I took a moment to read the latest comments.

One recurring theme stood out—a misunderstanding of code portability. Although I’ve addressed this before in SQL Style Guide Misconceptions, it seems worth revisiting, as many readers still seem to struggle with the concept.

Many readers who have commented in the past and probably will comment in the future have a very limited vision of code portability and its benefits.

What is code portability?

Code portability is generally refers to the ability to move code from one environment to another with minimal changes. For example, in the context of the SQL style guide, this might mean taking code written for MySQL and adapting it easily for PostgreSQL.

The same principle applies across software development: keeping your business logic decoupled from specific frameworks ensures it can be migrated to another framework with minimal effort.

However, this is unlikely to be something that many developers will experience in their careers. It is rare that a project will move to a different environment once it has been established. Where it does happen it is likely to be larger body of work and changing the SQL queries will be the least of your worries.

Whilst this is one aspect of portability it is not the only one. In my opinion it is not the most compelling reason to write portable code either.

What is the real benefit of code portability?

Reuse

One major benefit of portability is the ability to reuse code. You can reuse code in a different project, even if it’s running in a different environment, without making any changes. For example, a query written for a MySQL-based project could be reused in another project running PostgreSQL with minimal effort.

Reusing code saves time and ensures we avoid reinventing the wheel.

You, the developer

A very real benefit of writing portable code that is very often overlooked is that it makes you, the developer, more portable. If you write portable code then you are able to move between projects, companies and teams more easily.

Take SQL as an example: why would want to pigeonhole yourself as a MySQL developer? Your next project might use PostgreSQL or MS SQL Server. If you have only learnt vendor specific SQL functionality then your skills are not going to be transferable to your new environment.

Instead of learning the Laravel way of doing something, learn the PHP way of doing something. Instead of learning the React or NestJS way of doing something, learn the JavaScript way of doing something. Sure, use the framework to make your life easier, but do not compromise your business logic to accommodate the framework.

Maintainability and ease for others

Portable code is easier to maintain and understand, both for yourself and for others who might work on it in the future. Standards-compliant, portable code ensures a wider audience of developers can quickly grasp its intent, making debugging, updating, and extending the codebase simpler.

Remember, you’re not just writing code for now—you’re writing it for your future self and your colleagues.

Tooling

When you are writing portable code you are writing code that is more likely to be supported by the tools you use. This can be your editor, code linters, code formatters, other static analysis tools and dashboards.

In the case of SQL, this could be your desktop database client and its internal code formatting, syntax highlighting and code completion features.

Vendor lock-in

Writing portable code reduces the risk of vendor lock-in. Relying on vendor-specific features ties your code—and your team—to that vendor.

While this might not seem like a concern for individual developers, it can pose significant challenges for organisations. However, by writing portable code you are reducing the risk of this happening and you get this advantage for free.

That said, let’s be realistic: with many of us relying on specific cloud providers, some level of lock-in is often inevitable.

What if I can’t?

Sometimes it is just not possible to write portable code and you have to use vendor specific functionality. This is fine and completely unavoidable. Do it. There is no need to self-flagellate.

Seriously, just move on and implement the feature.

Conclusion

If you have the option to write portable code, you should. Choosing to write vendor-specific code unnecessarily forfeits the benefits I have outlined above. Most commenters appear to be blind to this and I hope that this article has helped to explain why I think it is important.

Ultimately, I am some bloke on the internet and you can choose to ignore me. The results of your choices will be yours to live with. I would urge you to think of others that will come after you though and make their lives easier by writing portable code where you can.