[jart]

I feel like I've had the opposite experience.

Earlier in my career I could just use any old tool that got the job done with plenty of dependencies, without a care in the world. Then three things happened. First, I got exposed to some of the highest quality tools and libraries in the industry. As in, the ones that only a few people are lucky enough to get to use, and it made using anything less polished afterwards painful. Sort of like living in a mansion and then needing to move back into a slum. The other thing was just finding out about too many of the nasty corner cases that exist in technology, which in most cases are safe to ignore, but are hard to unthink about once you know about them. The third was just having too many things I depended on break over time or abandon the principles that attracted me to the project in the first place.

So now, later in my career, my biases are more tuned towards reinventing things than ever before. I'd rather minimize risk by having something perfectly tailored to my specific needs. If it breaks, I'll only have myself to blame. I view that as a fun learning experience. Much better than the alternative, which is nagging folks in the open source community and filing issues expecting them to support me, and then feeling guilty afterwards. Only thing I'm worried about is that my standings will continue to grow so high that the joy of programming is so hard to find that I'll just do management, and just let other people have fun with all the churn.

[lostcolony]

Well, there's also something similar, but related, that I've found.

Namely, the amount of understanding and effort needed to solve my problem correctly and safely...is frequently less than the amount of understanding and effort needed to use some opinionated library or framework.

Not always; there are plenty of times a library or framework is a better choice. But what tilts the scale in that direction is making them very simple, with minimal assumptions, minimal state, and simple APIs into them, because that can keep it simpler than writing myself.

[greggman3]

It all really depends on the example. I know tons of developers that skip Unity or Unreal because there is a learning curve and they can already render a cube themselves. They think "I just write a model loader" and ship and not realize how many man years of work they are ignoring in all other parts. Input systems across 10+ platforms, graphics APIs across those 10 platforms, physics libraries, post processing library, all the edge cases of importing that took man years to find, gaming networking libraries and on and on.

Of course is their choice and if they enjoy reinventing the wheel good for them. But they'll spend 6 to 18 months working on reproducing some fraction of the features they'd have for free instead of working on what makes their thing unique.

[lostcolony]

As I said, "there are plenty of times a library or framework is a better choice".

An egregious example of what I'm referring to is what we saw with the left pad library. That always blew my mind because the amount of effort to find a library, learn it, include it, and use it, seemed really high for the functionality. I don't understand why it saw such adoption - I wouldn't even -think- to Google that functionality as a library; I'd just write it (if I was unaware of the string method, which to be fair, I only know of because of the leftpad kerfuffle).

A game engine is an example where learning the framework is assuredly going to be faster; you'd need a better reason to write your own, and as a dev manager I'd be pushing back on it hard (whether it was coming from the devs or the business).

[anonymoushn]

I was excited for Unity's input system rewrite and hoped that it would allow games to put input events on the wire to the opponent/server as soon as they were received, independently of the game loop. I asked the developer about it and he said "no, it only does part of what you want, and input events for some devices are still processed on the main thread anyway." So it seems like I have to wait decades for Unity to catch up with the kind of thing one can hack into love2d in an afternoon.

[pgt]

Yes, In Defense of NIH, the stronger you become as a developer, the more of a liability other people's code becomes.

[bl0b]

Just as a quippy counterpoint (without engaging with GPs actual argument), I would say that as I've became more experienced as a developer, the more I've realized how much of a liability my own code is (and that using libraries allows me to write less code).

[bitwize]

> First, I got exposed to some of the highest quality tools and libraries in the industry. As in, the ones that only a few people are lucky enough to get to use, and it made using anything less polished afterwards painful.

If any Hackernews wondered why anyone would want to live and do all their work from within Emacs, this alone would explain it.