The Code It Yourself Manifesto (2016) • Hacker News Board

Re: The Code It Yourself Manifesto (2016)

#41

Post by jariel » Sat, Nov 28, 2020, 12:02 AM UTC

andrewjl wrote: post #40

jariel wrote: post #37

Earlier quoted context omitted.

How would one justify literally building something that someone has done very well, so that you can learn, literally by building something that's probably not as good. I mean, on one's own time, this seems like rather a good thing to do. But to say "Yeah, instead of something that works now 0 days work let's spend 3 months building something that may not work very well and we have to maintain" - is not a reasonable p…

It's simpler to justify if the development process is also seen as a knowledge acquisition process. Does the knowledge acquired by re-invention and its effect on subsequent effectiveness and or productivity outweigh the cost of time expended. In many cases, especially in a mature or stable environment, the answer is yes. It's also an attractive method of learning to people who like to think from first principles, as…

"as a knowledge acquisition process" so yes, if the module is a little bit core and you would rather have it internally, the added risk of time/quality/maintenance may be worth it. Sure.

Re: The Code It Yourself Manifesto (2016)

#42

Post by cle » Sat, Nov 28, 2020, 12:43 AM UTC

malwrar wrote: post #15

I believe the first step when creating something new aught to be answering honestly for yourself why existing solutions won’t work for you. Your time is valuable and much better spent building something no one else has yet. I was once heavily afflicted by NIH, but with experience I realized how much time I was wasting stubbornly trying to reinvent the wheel. That’s actually a great analogy if you think about it—-the…

I don't think that's a useful question unless you know how to answer it within specific contexts. In other words, what does "work" mean? There are so many dimensions to consider there, including technical, social, business, developmental, and legal ones.

Sometimes the most extreme NIH tendencies are perfectly justified due to these constraints, and sometimes they're absurd. I don't think any point on the continuum is generally "correct" nor should be generally advocated for. Instead we should be discussing how to figure out where the point lies on the continuum, within the context of the software we're currently writing.

Re: The Code It Yourself Manifesto (2016)

#43

Post by twblalock » Sat, Nov 28, 2020, 12:53 AM UTC

jaaron wrote: post #38

First: If the code is for you, and for you exclusively, go ahead. If you're writing code as part of a team for a customer, then it isn't for you and it's whole purpose is to solve the problem at hand. Secondly: The primary issue I have with a NIH code-it-yourself approach is that it doesn't scale over time. Professionally, over two decades, I have seen several teams go through a technical evaluation and decide, in th…

> Fast forward three to five years and everyone regretted the NIH approach. Those open or closed source solutions had matured and easily surpassed the home grown feature set, which still required a team of engineers to invest in.

This is the root of the problem: a small team generally can't keep up with an open source project over time.

The NIH approach works well at larger companies who can dedicate a lot of engineers to working on in-house infrastructure projects full time. At smaller companies it is a distraction from building the core product.

Re: The Code It Yourself Manifesto (2016)

#44

Post by greggman3 » Sat, Nov 28, 2020, 1:42 AM UTC

lostcolony wrote: post #35

jart wrote: post #32

Earlier quoted context omitted.

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 pai…

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…

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.

Re: The Code It Yourself Manifesto (2016)

#45

Post by quelsolaar » Sat, Nov 28, 2020, 2:17 AM UTC

BoorishBears wrote: post #26

quelsolaar wrote: post #23

Earlier quoted context omitted.

A good reason to implement things yourself is to learn. I recently implemented a PNG loader saver. All in all it took me 3-4 days to do. I now have a complete grasp of the file format, and the code base. I will never need to find a library for it, or have a dependency, the code wont change without me knowing about it, and I can very accurately make decisions about when using PNG is the right format. I can speak about…

I guess it depends on the problem domains you work in because I've never once needed to speak on the PNG format with authority. Similarly, finding authoritative comparisons of which image formats do what best is pretty easy. I've also never run up against shortcomings of existing PNG solutions. Even in assembly for the Z80 I remember using a PNG converter that would handle greyscale on a calculator! But 3 or 4 days o…

I think i think of it as a investment in my career. if you can do close to 30 of these small projects each year, it starts adding up. You become an expert in many domains and you start to build up a large code base.

If you look at my codebase (www.gamepipeline.org) you can see that it looks more similar to a platform holder like Microsoft/Apple/Google, then what most individuals github profiles.

The most common critique of my coding ethos is that its not efective (I write everything in C and I have Zero dependencies, so I write everything from scratch). But looking at what i have been able to accomplice over the years, I cant think of many people who have produced as many applications as I have (http://www.quelsolaar.com). If writing everything in higher level languages and using lots of dependencies was as effective as people say, then there would be plenty of people running circles around me in terms of productivity, and I just don see that.

Re: The Code It Yourself Manifesto (2016)

#46

Post by methodsignature » Sat, Nov 28, 2020, 2:19 AM UTC

quelsolaar wrote: post #23

malwrar wrote: post #15

I believe the first step when creating something new aught to be answering honestly for yourself why existing solutions won’t work for you. Your time is valuable and much better spent building something no one else has yet. I was once heavily afflicted by NIH, but with experience I realized how much time I was wasting stubbornly trying to reinvent the wheel. That’s actually a great analogy if you think about it—-the…

A good reason to implement things yourself is to learn. I recently implemented a PNG loader saver. All in all it took me 3-4 days to do. I now have a complete grasp of the file format, and the code base. I will never need to find a library for it, or have a dependency, the code wont change without me knowing about it, and I can very accurately make decisions about when using PNG is the right format. I can speak about…

Learning is nice and all, but if you didn't document well, and regardless probably the first time the next guy needs a feature that exists in off the shelf solutions, that code will likely be ripped out pdq (given the problem space was non-trivial).

Re: The Code It Yourself Manifesto (2016)

#47

Post by sitzkrieg » Sat, Nov 28, 2020, 2:39 AM UTC

quelsolaar wrote: post #45

BoorishBears wrote: post #26

Earlier quoted context omitted.

I guess it depends on the problem domains you work in because I've never once needed to speak on the PNG format with authority. Similarly, finding authoritative comparisons of which image formats do what best is pretty easy. I've also never run up against shortcomings of existing PNG solutions. Even in assembly for the Z80 I remember using a PNG converter that would handle greyscale on a calculator! But 3 or 4 days o…

I think i think of it as a investment in my career. if you can do close to 30 of these small projects each year, it starts adding up. You become an expert in many domains and you start to build up a large code base. If you look at my codebase (www.gamepipeline.org) you can see that it looks more similar to a platform holder like Microsoft/Apple/Google, then what most individuals github profiles. The most common criti…

that is the most obnoxious site ive ever seen :D

Re: The Code It Yourself Manifesto (2016)

#48

Post by lostcolony » Sat, Nov 28, 2020, 2:40 AM UTC

greggman3 wrote: post #44

lostcolony wrote: post #35

Earlier quoted context omitted.

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…

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 librar…

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).

Re: The Code It Yourself Manifesto (2016)

#49

Post by edgyquant » Sat, Nov 28, 2020, 3:42 AM UTC

quelsolaar wrote: post #45

BoorishBears wrote: post #26

Earlier quoted context omitted.

I guess it depends on the problem domains you work in because I've never once needed to speak on the PNG format with authority. Similarly, finding authoritative comparisons of which image formats do what best is pretty easy. I've also never run up against shortcomings of existing PNG solutions. Even in assembly for the Z80 I remember using a PNG converter that would handle greyscale on a calculator! But 3 or 4 days o…

I think i think of it as a investment in my career. if you can do close to 30 of these small projects each year, it starts adding up. You become an expert in many domains and you start to build up a large code base. If you look at my codebase (www.gamepipeline.org) you can see that it looks more similar to a platform holder like Microsoft/Apple/Google, then what most individuals github profiles. The most common criti…

quelsolaar.com is really bad on Safari (iPad.) Took >10 seconds to load and then I couldn’t even read most of it as animations clearly meant to pop up at a different point constantly popped up over the text.

Re: The Code It Yourself Manifesto (2016)

#50

Post by anonymoushn » Sat, Nov 28, 2020, 4:22 AM UTC

greggman3 wrote: post #44

lostcolony wrote: post #35

Earlier quoted context omitted.

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…

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 librar…

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.