6 ms·

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 valuabl

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 original wheels were fashioned out of wood and are quite simple in concept, but creating modern wheels require s tons of specialized tools and knowledge to build. It doesn’t make sense to attempt this if I can just buy a premade one that suits my needs. That premade wheel also has the benefit of huge amounts of iteration in response to problems encountered over time, and I would probably need to replicate at least some of that in order to build something competitive with the existing solution. In the realm of code, using other people’s solutions when available lets me focus on the original problem I want to solve. It also allows me to minimize the amount of code I need to actually maintain myself, since typically there’s a group of people that are collectively much more knowledgeable than me doing that for free. If I ever do have a reason to know how the library works (patches, bug fixes, behavioral questions, curiosity), I’ve found it much quicker to figure out how the code works rather than write my own.

asddubs 6y ago
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.
- nullsense 6y ago
  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.
bullen 6y ago
I think you mean re-implement the wheel, people often misuse the term re-invent the wheel. You actually need to change things for it to be called an invention: http://move.rupy.se/file/wheel.jpg http://move.rupy.se/file/wheel.jpg That said I always write everything from scratch, to me it's the meaning of life; If you are only using things you don't understand, you cannot (re-)invent anything. Today we also do not own anything, which makes the problem even worse. Rules for a good life: 1) own 2) understand 3) change!
- spfzero 6y ago
  Feinman said something like that. IIRC, “I cannot understand it if I cannot create it.” I probably butchered it.
  - bullen 6y ago
    "What I cannot create, I do not understand" - What he meant by this was re-implement more than re-invent... re-invent is an oxymoron I just realized; you cannot re- something that needs to be new.
quelsolaar 6y ago
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.
- josephg 6y ago
  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 6y ago
    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.
- BoorishBears 6y ago
  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
enriquto 6y ago
> 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 spend nearly all of their time training, and just a tiny (but very focused) amount of time competing. Likewise, scientists spend most of their time preparing experiments and reproducing results of others, and a tiny amount of time "creating". I do not believe that programmers can successfully escape this scheme. The best programmers I know, spend an inordinate amount of time rewriting well known algorithms (and oftentimes, improving them with slight variations).
- jariel 6y ago
  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 premise in most scenarios. It defies the very point of trade specialization upon literally which the economy is built. So while we should always be learning, learning in and of itself in most instances is not a good enough reason to do something at least at work.
  - andrewjl 6y ago
    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 it involves developing a bottom-up understanding of whatever "the wheel" in this case is via practice. I find that strong opinions either way on this question to be indicative of time preference. My own view is there's a time to do it and there's a time to avoid it. It becomes very valuable when ones navigating an unfamiliar area or is in the midst of a fundamental shift in the landscape. It's best to avoid it if the team or project is an a do-or-die scenario where certain milestones must be met to ensure it remains a viable team or project.
jart 6y ago
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 6y ago
  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 6y ago
    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.
wizardforhire 6y ago
In addition to this I’ve found if its something too big for my current capabilities and I don't mind not owning it, just putting it out into the world and being patient yields wonders! Its almost a super power. For instance if you want a new material or something fabricated and it doesn't exist but is physically capable of being manufactured just steamrolling alibaba, ebay and other chinese manufacturers with searches from different IP addresses will convince the powers at be that a sufficient market potential exists for what ever you want. Do this enough, sit back, wait... and voila! Dichroic fabric, holographic fabric, weird whatever you want will magically appear on your store shelves in just a matter of a year. Wait another year and it’ll be 40% off!
cle 6y ago
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.
c22 6y ago
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.

asddubs 6y ago

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.

nullsense 6y ago
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.

bullen 6y ago

I think you mean re-implement the wheel, people often misuse the term re-invent the wheel. You actually need to change things for it to be called an invention: http://move.rupy.se/file/wheel.jpg http://move.rupy.se/file/wheel.jpg That said I always write everything from scratch, to me it's the meaning of life; If you are only using things you don't understand, you cannot (re-)invent anything. Today we also do not own anything, which makes the problem even worse. Rules for a good life: 1) own 2) understand 3) change!

spfzero 6y ago
Feinman said something like that. IIRC, “I cannot understand it if I cannot create it.” I probably butchered it.
- bullen 6y ago
  "What I cannot create, I do not understand" - What he meant by this was re-implement more than re-invent... re-invent is an oxymoron I just realized; you cannot re- something that needs to be new.

quelsolaar 6y ago

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.

josephg 6y ago
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 6y ago
  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.
BoorishBears 6y ago
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

enriquto 6y ago

> 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 spend nearly all of their time training, and just a tiny (but very focused) amount of time competing. Likewise, scientists spend most of their time preparing experiments and reproducing results of others, and a tiny amount of time "creating". I do not believe that programmers can successfully escape this scheme. The best programmers I know, spend an inordinate amount of time rewriting well known algorithms (and oftentimes, improving them with slight variations).

jariel 6y ago
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 premise in most scenarios. It defies the very point of trade specialization upon literally which the economy is built. So while we should always be learning, learning in and of itself in most instances is not a good enough reason to do something at least at work.
- andrewjl 6y ago
  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 it involves developing a bottom-up understanding of whatever "the wheel" in this case is via practice. I find that strong opinions either way on this question to be indicative of time preference. My own view is there's a time to do it and there's a time to avoid it. It becomes very valuable when ones navigating an unfamiliar area or is in the midst of a fundamental shift in the landscape. It's best to avoid it if the team or project is an a do-or-die scenario where certain milestones must be met to ensure it remains a viable team or project.

jart 6y ago

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 6y ago
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 6y ago
  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.

wizardforhire 6y ago

In addition to this I’ve found if its something too big for my current capabilities and I don't mind not owning it, just putting it out into the world and being patient yields wonders! Its almost a super power. For instance if you want a new material or something fabricated and it doesn't exist but is physically capable of being manufactured just steamrolling alibaba, ebay and other chinese manufacturers with searches from different IP addresses will convince the powers at be that a sufficient market potential exists for what ever you want. Do this enough, sit back, wait... and voila! Dichroic fabric, holographic fabric, weird whatever you want will magically appear on your store shelves in just a matter of a year. Wait another year and it’ll be 40% off!

cle 6y ago

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.

c22 6y ago

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.