[quelsolaar]

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 the format with authority.

All this have a lot of long time value.

[BoorishBears]

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 of work! Mam I can think of a lot of things I could do with that.

If it was for the fun of the experience I'd totally get it, but spinning it as an "I needed to do this", I don't think I could go that far in the areas I've worked in

[quelsolaar]

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.

[jart]

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.

[edgyquant]

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.

[sitzkrieg]

that is the most obnoxious site ive ever seen :D

[josephg]

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 port to the final version of the code). And I learned all sorts of practical physics - moments of inertia, rotational momentum, restitution, solvers, etc.

It was a silly thing to do by most standards, but acts like that make me a much better engineer.

[nullsense]

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.

[methodsignature]

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