Live data from Hacker News

The Code It Yourself Manifesto (2016)

pestilenz.org

51–57 of 57 posts

Re: The Code It Yourself Manifesto (2016)

#51
post #36
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…

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

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

Re: The Code It Yourself Manifesto (2016)

#52
post #25

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 agree. Years ago over a Christmas break I hand ported the Chipmunk-2d physics engine to javascript because I wanted to understand how it worked. (And wanted to have a physics engine I could use for small games). It only took me about 2 weeks and it was one of my most memorable experiences of the year. I learned a few great data structures, I learned about JS microoptimization (I got an 8x speed up from the first po…

At some point in your career after you get sick of the treadmill that is trying to "keep up" and maybe have experienced or been close to burnout at least once and have gone through really asking yourself "why am I doing this?", it's the projects like these that actually help you reconnect with what it is you love about the craft in the first place.

Re: The Code It Yourself Manifesto (2016)

#53
post #18
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 would say "code it yourself, if it doesn't significantly slow you down". There's definitely something to be said for minimizing your dependencies, but if you're spending weeks implementing things completely tangential to what you're trying to do, you made a wrong turn somewhere. It's all about picking your battles, and I think you can go too far in both directions.

I'm personally starting to take the view of "sharpen your tools". That is, I'm fine with taking dependencies where appropriate, but I'm starting to contribute fixes and improvements to them as a way to derisk them. I think that benefits everyone.

Re: The Code It Yourself Manifesto (2016)

#55
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…

When I code something myself I am not reinventing any wheels and I am not building a creaky wooden wheel. As you say, the world is full of technically marvelous wheels that I can crib off of and I have access to fabulous tools that allow me to easily synthesize new wheels.

Unlike actual wheels, the ability to quickly and easily tear down, reconfigure, and rebuild my digital tool box is the defining hallmark of software.

Re: The Code It Yourself Manifesto (2016)

#56

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…

Looking at your codebase, it looks like each of these files could make excellent online tutorials. Many of the APIs you're using are tricky to figure out. It helps so much being able to google concrete usage examples, that are well organized and provide brief explanations and screenshots. It reminds me of the days when I used to used Beej's tutorials on socket programming. That's the kind of content we sadly don't see as much anymore. Online programming resources since then sadly seem to have become polarized between (a) direct answers to specific questions on stack overflow, and (b) low-effort seo-optimized blind leading the blind.

Re: The Code It Yourself Manifesto (2016)

#57
post #37

Earlier quoted context omitted.

> Your time is valuable and much better spent building something no one else has yet. I strongly disagree with this. I believe the exact opposite is true. Creation spurts from learning, so if you want to be creative it pays of to spend most of your time learning things that already exist. In the context of programming, this means implementing algorithms for which several other implementations already exist. Sportsmen…

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…

>I mean, on one's own time, this seems like rather a good thing to do.

This is an interesting example of Conway's Law. If I hire a contractor for something, I'll want them to just import something that works, not try to explore things deeply. If I have a long term employee or cofounder, I'll want to encourage that experimentation and growth.

Post reply on HN