Skuunk Works

(This article is pure opinion and is not based on any facts what so ever...) At present (in April 2026) not only are most programmers not writing code directly, we are not writing Domain Specific Languages directly either. A domain specific language, unlike a general programming language, is a language written to solve a specific problem. Often a DSL is translated into a general purpose language (either by interpreter or compiler) and exists to help a programmer read code and reason about a problem in a more readable way. One example that comes to mind is a Arel which is a DSL for writing SQL queries. While SQL is already quite user friendly on the surface, queries can become complex quite easily after a few joins. Also, there are slight differences in SQL depending on which database you use (e.g. Postgres vs MySQL vs Oracle) so having a DSL smooths over these changes as well. However, sometimes achieving what you want to do in Arel can be harder than doing it in raw SQL and also Arel ...

Ok, controversial click bait title aside, personal software projects do an enormous amount of good in teaching you how to learn new languages, write better code, architect code and may even make you a buck or two on the side (if you are lucky). However, there are some things that you are not likely to learn when writing personal software projects and I wanted to discuss a few of them here. What they can't teach you How to communicate your ideas By definition a personal project is personal. You are probably the only one working on it (though you can ask a friend or two to help, which is highly advisable if you can). When you want to add a new software pattern or framework, you just do it. While that's incredibly liberating, one of the benefits of working in a team is having to explain your decisions will make you more reflective and will give you a better sense of if you are doing things the right way or not. If you meet with resistance to the idea, it means you have to th...