131–140 of 269 posts
It's a case by case basis. I wonder why people try to encapsulate these things into "philosophies" that are simple minded and stereotypical.
Choose what's better. That's not always necessarily boring technology. Sometimes it is... sometimes it isn't.
> Let’s say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while. This is one of my favorite blog posts, and it can basically be encapsulated in the idea of "innovation tokens." It is one of the most useful concepts I have had as a PM / eng leader in my career. It helps actually make the the right tradeoffs, and helps even more in explaining…
I wish there was a jobs board for companies that are somehow vetted for this type of engineering culture. So many jobs are sold as “we’re pragmatist's” and when you show up there’s 5 devs, 50 repos and most of the work is discussing if x requirement should be a new micro service. The product is usually an web app with 10 entities and and an API. Suppose it’s keeping people in jobs
Earlier quoted context omitted.
> Now it's a sure fire sign that the project was probably vibe coded. Groan. That's sad.
Compare to what happened to Python. That will cheer you up!
I remember in the pre-AI era I was doing a quick sample contract employment with a company that had >200 columns in their user table and was manually enumerating them in every query, multiple times. They were using SELECT $1,$2,...$184,$185 from tablename with an enormous list of columns referenced only by offset. That's not python's fault, but I've weirdly seen it more often in python codebases.
> Let’s say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while. This is one of my favorite blog posts, and it can basically be encapsulated in the idea of "innovation tokens." It is one of the most useful concepts I have had as a PM / eng leader in my career. It helps actually make the the right tradeoffs, and helps even more in explaining…
> If you choose to write your website in NodeJS, you just spent one of your innovation tokens.
Is NodeJS still considered on the same level of "unknown" / "not-boring" technology as the others listed? By my reckoning it is plenty mature enough to be considered a "boring" choice, and going for bun would be spending and innovation token.
> Let’s say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while. This is one of my favorite blog posts, and it can basically be encapsulated in the idea of "innovation tokens." It is one of the most useful concepts I have had as a PM / eng leader in my career. It helps actually make the the right tradeoffs, and helps even more in explaining…
I also broadly agree with the post. > If you choose to write your website in NodeJS, you just spent one of your innovation tokens. Is NodeJS still considered on the same level of "unknown" / "not-boring" technology as the others listed? By my reckoning it is plenty mature enough to be considered a "boring" choice, and going for bun would be spending and innovation token.
> Let’s say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while. This is one of my favorite blog posts, and it can basically be encapsulated in the idea of "innovation tokens." It is one of the most useful concepts I have had as a PM / eng leader in my career. It helps actually make the the right tradeoffs, and helps even more in explaining…
I also broadly agree with the post. > If you choose to write your website in NodeJS, you just spent one of your innovation tokens. Is NodeJS still considered on the same level of "unknown" / "not-boring" technology as the others listed? By my reckoning it is plenty mature enough to be considered a "boring" choice, and going for bun would be spending and innovation token.
Earlier quoted context omitted.
I admit I have a hard time following this logic. If an agent has a baseline intelligence, you can... instead of using boring technology, just DIY/NIH the simplest custom solution which fulfills your requirements. And you'll usually do a better job than a general-purpose software library. Even if in the other approach, the LLM knows the stack better, you're just going to push the complexity into your client code, so i…
That’s definitely not true, and I’ll give two incredibly common examples: 1: arraylist. A library will probably do better than you. It’s already written and common. 2: webservers. Sure, you can write one yourself with sockets and a bunch of buffers and string management… or, you could use one of the 100s of existing ones. Which one? Probably a stable and established one.
Once upon a time I wanted a URL /like/this/with%2Fslashes/ where a path parameter could, in rare cases, contain an encoded slash. Legit according to every RFC I checked. Works fine in browsers. But I couldn't get the web server to not convert it to a / before hitting my code. And woe betide thee who wants to make nginx return a custom error code 444.
Earlier quoted context omitted.
I also broadly agree with the post. > If you choose to write your website in NodeJS, you just spent one of your innovation tokens. Is NodeJS still considered on the same level of "unknown" / "not-boring" technology as the others listed? By my reckoning it is plenty mature enough to be considered a "boring" choice, and going for bun would be spending and innovation token.
I think calling anything in the JavaScript ecosystem “mature” is a bit of a stretch. This is the same community that brought us left-pad.