3 ms·

Yes, but then you need to be able to market your DSL and get buy-in. Otherwise you will forever be just a team of one. And then need to sell to all the stakeh

Yes, but then you need to be able to market your DSL and get buy-in. Otherwise you will forever be just a team of one. And then need to sell to all the stakeholders of the project the idea of trusting one person for all the development. So in addition to the skill of creating a DSL, you need the skills of thoroughly documenting it, training other people to use it, creating tools for it, and explaining the benefits in a way that gets them more excited than just using an existing Boring Old Programming Language. Which is certainly possible. You can get non developers excited if they can use it for answering their own questions or creating their own business rules, for example. But it's a distinct skill set from cranking out code to solve problems. It requires a strong understanding of the UX (or DX) implications of this new language.

travisjungroth 3y ago
I’m of the mindset that API and DSL are more of a continuum than categories. As soon as you write your first abstraction, you’re making a little language. In the same way, what you listed isn’t a distinct skill set from cranking out code to solve problems. What happens is those skills are now levered. Not the good vibes “leveraged”. I mean in the “impact to success and failure is 100x baseline” sense. If those skills are in the red, you get wiped out.
couchand 3y ago
Every word you wrote is true. It's all still true if you replace "DSL" with any project and "Boring Old Language" with the competitor. This is the stopping at 90% problem somebody just posted a link to in another thread. edit: https://austinhenley.com/blog/90percent.html https://austinhenley.com/blog/90percent.html
- jimbokun 3y ago
  No, for Boring Old Language other people have already solved those problems for you.
  - couchand 3y ago
    Regardless of how supposedly non-controversial each technical design decision is, you will find that the entire scope of them never is. So you will always be working to bring people along to your design choices and help them understand the (relative) value, or risk forever languishing as the sole contributor. You don't get buy-in with technology, you get buy-in with ideas.

travisjungroth 3y ago

I’m of the mindset that API and DSL are more of a continuum than categories. As soon as you write your first abstraction, you’re making a little language. In the same way, what you listed isn’t a distinct skill set from cranking out code to solve problems. What happens is those skills are now levered. Not the good vibes “leveraged”. I mean in the “impact to success and failure is 100x baseline” sense. If those skills are in the red, you get wiped out.

couchand 3y ago

Every word you wrote is true. It's all still true if you replace "DSL" with any project and "Boring Old Language" with the competitor. This is the stopping at 90% problem somebody just posted a link to in another thread. edit: https://austinhenley.com/blog/90percent.html https://austinhenley.com/blog/90percent.html

jimbokun 3y ago
No, for Boring Old Language other people have already solved those problems for you.
- couchand 3y ago
  Regardless of how supposedly non-controversial each technical design decision is, you will find that the entire scope of them never is. So you will always be working to bring people along to your design choices and help them understand the (relative) value, or risk forever languishing as the sole contributor. You don't get buy-in with technology, you get buy-in with ideas.