1. What you said about matching the way you think and your personal style.
2. Longevity. If you use someone else’s peoject, it’s dependent on them maintaining it. Assuming you don’t want to take it over at some point, making your own thing means you know how it all works so you can fix/maintain it if needed, and build it in a way that requires as little or as much maintenance as you want.
3. Building the tools is more fun than what you will ultimately do with it. I find the idea of writing my own site building compelling. Based on how many blogs I’ve started and never wrote in regularly, I don’t actually find the act of blogging compelling. People who have something to say and want an easy way to get the message out just pick a tool and stick with it. Others like myself, will build platforms to say things, then never actually say anything. I just build blogs from scratch over and over again, because it’s an easy, but semi interesting project that can be solved in countless ways. This could be called procrastination, but I think it’s something else, as I’m not actually trying that hard to have a blog or a site with traffic that people care about and visit. It’s just for me.
Yeah, man. I think this was the reasons I initially had: ergo, longevity, fun. Thank you!
Also I love the idea of - blogging creating specifics is boring, but creating platforms/tooling to express is fun! Totally I get this. Funny never thought of it that was as a dichotomy/alternate expression, but it is! :)
I find blogging so boring, but love making stuff, that I get AI to write the blogs.
People do this because on one hand they want something better but on the other hand are limited to zones of comfort, as in familiar patterns. There is a psychological measure for this called uncertainty avoidance.
As for myself I have learned to avoid certain things that only induce complexity and as result feel confident I can build almost anything in JavaScript/TypeScript. Here are my zones of avoidance.
* DOM abstraction. Working with the DOM is stupid simple, so don’t use unnecessary abstractions to make it something it isn’t. Sometimes I do find the DOM is missing important features so I will extend the DOMs API with original methods, such as getNodesByType.
* No OOP. I avoid classes and inheritance as entirely unnecessary. Functions and objects are all I need for architecture.
* Know your platform. In the browser it’s the DOM and Web APIs. In Node it’s their direct module APIs. Get comfortable working as close to the platform as possible. It’s less to troubleshoot later.
* Avoid unnecessary string parsing. This includes things like querySelectors, innerHTML, and a lot of insanity from framework template systems. This is by far one of the two biggest performance boosts.
* Preference WebSockets over HTTP. This also dramatically boosts performance and significantly reduces application complexity.
I appreciate your comments here. Your insight is always valuable! Thank you.
I also have a purity or “web grain” mindset towards the web platform. It’s nice to see someone else share that sensibility, even though I know it’s not a super uncommon thing to appreciate and utilize the design of the web system as is.
People love their craft and want to really understand how a tool works. They might start with taking a tool apart, looking at how it works, putting it back together and then using it for a bit. Then they need a similar tool for a slightly different use case, so they start making one themselves. Maybe they have more specific, detailed needs than existing tools. Maybe there is something about the tool that annoys them or they think they could make it work better. This keeps going over time.
> This was the craftsman’s ‘Golden Age’ and much time and trouble was taken over the design of tools. Craftsmen were being called upon to do more skilful and exacting work and the use of tools and the interest in development had become very widespread.
Above pulled from A Brief History of the Woodworking Plane [0]. A woodworking tool that has evolved over 2,000 years. Now there are electric planers, handheld electric planers and lots of heavy machinery that do the same thing in a very automated way. If a company is mass producing kitchen cabinets, they aren't hand planing edges on boards, a machine is doing all that work.
I feel like with AI we are on the cusp of moving beyond a "Golden age" and into an "industrial age" for coding, where it will become more important to have code that AI understands vs. something that is carefully crafted. Simple business pressure will demand it (whether we like it or not). The difference with hand planes (and other woodworking tools/concepts) is that a lot of people can appreciate a piece of furniture and the craft that went into it by opening a drawer and seeing hand cut dovetails for example. When it comes to digital products, none of the consumers of the product will really care about the craftsman that created a JS library that they are indirectly using on a web site that has its "view source" hidden with minification/obfuscation.
This is a really insightful perspective. I like how you weaved AI and hand-working wood in too. Really helped illustrate - thank you!
I think your idea that we will make more code that is AI-readable is probably true. Incentives seem to be aligned like that. Nice 2nd order effect identification!
2. It is not (and probably never will be) solved universally.
3. Even if someone comes close to universal solution initially (react, nextjs) they eventually evolve into over complicated shit (partly because of greediness and arrogance of authors - who would not want to rule all and make as much profit, partly because never ending stream of edge cases pushes it to evolve in unpredictable directions).
4. New generations of creators see better new ways and new requirements on the market.
You can only last so far fixing an old car. You eventually would have to get a new one. Even if the main idea (moving you from A to B) stays exactly the same
I’m doing this exact thing now with a web framework. For me, it comes down to tailor making it to the way I want to build. In some cases this is for efficiency, in others it’s ergonomics. And it’s also a rewarding process to create the tool and then use it to build with.
I agree - it's rewarding! Another guy just commented that NIH is a factor. I think that could be a thing. I wonder how to be on guard against that, but take the positives we've identified here (ergonomics, longevity, fun, reward)?
I can think of a few reasons.
1. What you said about matching the way you think and your personal style.
2. Longevity. If you use someone else’s peoject, it’s dependent on them maintaining it. Assuming you don’t want to take it over at some point, making your own thing means you know how it all works so you can fix/maintain it if needed, and build it in a way that requires as little or as much maintenance as you want.
3. Building the tools is more fun than what you will ultimately do with it. I find the idea of writing my own site building compelling. Based on how many blogs I’ve started and never wrote in regularly, I don’t actually find the act of blogging compelling. People who have something to say and want an easy way to get the message out just pick a tool and stick with it. Others like myself, will build platforms to say things, then never actually say anything. I just build blogs from scratch over and over again, because it’s an easy, but semi interesting project that can be solved in countless ways. This could be called procrastination, but I think it’s something else, as I’m not actually trying that hard to have a blog or a site with traffic that people care about and visit. It’s just for me.
Yeah, man. I think this was the reasons I initially had: ergo, longevity, fun. Thank you!
Also I love the idea of - blogging creating specifics is boring, but creating platforms/tooling to express is fun! Totally I get this. Funny never thought of it that was as a dichotomy/alternate expression, but it is! :)
I find blogging so boring, but love making stuff, that I get AI to write the blogs.
People do this because on one hand they want something better but on the other hand are limited to zones of comfort, as in familiar patterns. There is a psychological measure for this called uncertainty avoidance.
As for myself I have learned to avoid certain things that only induce complexity and as result feel confident I can build almost anything in JavaScript/TypeScript. Here are my zones of avoidance.
* DOM abstraction. Working with the DOM is stupid simple, so don’t use unnecessary abstractions to make it something it isn’t. Sometimes I do find the DOM is missing important features so I will extend the DOMs API with original methods, such as getNodesByType.
* No OOP. I avoid classes and inheritance as entirely unnecessary. Functions and objects are all I need for architecture.
* Know your platform. In the browser it’s the DOM and Web APIs. In Node it’s their direct module APIs. Get comfortable working as close to the platform as possible. It’s less to troubleshoot later.
* Avoid unnecessary string parsing. This includes things like querySelectors, innerHTML, and a lot of insanity from framework template systems. This is by far one of the two biggest performance boosts.
* Preference WebSockets over HTTP. This also dramatically boosts performance and significantly reduces application complexity.
I appreciate your comments here. Your insight is always valuable! Thank you.
I also have a purity or “web grain” mindset towards the web platform. It’s nice to see someone else share that sensibility, even though I know it’s not a super uncommon thing to appreciate and utilize the design of the web system as is.
People love their craft and want to really understand how a tool works. They might start with taking a tool apart, looking at how it works, putting it back together and then using it for a bit. Then they need a similar tool for a slightly different use case, so they start making one themselves. Maybe they have more specific, detailed needs than existing tools. Maybe there is something about the tool that annoys them or they think they could make it work better. This keeps going over time.
> This was the craftsman’s ‘Golden Age’ and much time and trouble was taken over the design of tools. Craftsmen were being called upon to do more skilful and exacting work and the use of tools and the interest in development had become very widespread.
Above pulled from A Brief History of the Woodworking Plane [0]. A woodworking tool that has evolved over 2,000 years. Now there are electric planers, handheld electric planers and lots of heavy machinery that do the same thing in a very automated way. If a company is mass producing kitchen cabinets, they aren't hand planing edges on boards, a machine is doing all that work.
I feel like with AI we are on the cusp of moving beyond a "Golden age" and into an "industrial age" for coding, where it will become more important to have code that AI understands vs. something that is carefully crafted. Simple business pressure will demand it (whether we like it or not). The difference with hand planes (and other woodworking tools/concepts) is that a lot of people can appreciate a piece of furniture and the craft that went into it by opening a drawer and seeing hand cut dovetails for example. When it comes to digital products, none of the consumers of the product will really care about the craftsman that created a JS library that they are indirectly using on a web site that has its "view source" hidden with minification/obfuscation.
[0] https://www.handplane.com/879/a-brief-history-of-the-woodwor...
This is a really insightful perspective. I like how you weaved AI and hand-working wood in too. Really helped illustrate - thank you!
I think your idea that we will make more code that is AI-readable is probably true. Incentives seem to be aligned like that. Nice 2nd order effect identification!
1. UI is a hard multidimensional problem
2. It is not (and probably never will be) solved universally.
3. Even if someone comes close to universal solution initially (react, nextjs) they eventually evolve into over complicated shit (partly because of greediness and arrogance of authors - who would not want to rule all and make as much profit, partly because never ending stream of edge cases pushes it to evolve in unpredictable directions).
4. New generations of creators see better new ways and new requirements on the market.
You can only last so far fixing an old car. You eventually would have to get a new one. Even if the main idea (moving you from A to B) stays exactly the same
I’m doing this exact thing now with a web framework. For me, it comes down to tailor making it to the way I want to build. In some cases this is for efficiency, in others it’s ergonomics. And it’s also a rewarding process to create the tool and then use it to build with.
I agree - it's rewarding! Another guy just commented that NIH is a factor. I think that could be a thing. I wonder how to be on guard against that, but take the positives we've identified here (ergonomics, longevity, fun, reward)?
Because all of them is free.
Why reinvent televisions and speakers?
Look up “not invented here” syndrome (NIH)
This is a great answer too, seriously. I think it's good to be aware of or on guard against this kind of stuff.
I don't think that captures all the reasons but it definitely could be a factor.
I wonder what psychological attitudes you need to embody to embrace NIH and give it fair treatment in decisions?