Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Code It Yourself Manifesto (2016)

pestilenz.org

Post reply on HN
Print view View original

31–40 of 57 posts

Re: The Code It Yourself Manifesto (2016)

#31

Post by enriquto »

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…

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

Re: The Code It Yourself Manifesto (2016)

#32

Post by jart »

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

Re: The Code It Yourself Manifesto (2016)

#33

Post by bullen »

spfzero wrote: post #27
bullen wrote: post #19

Earlier quoted context omitted.

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

Feinman said something like that. IIRC, “I cannot understand it if I cannot create it.” I probably butchered it.

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

Re: The Code It Yourself Manifesto (2016)

#34

Post by wizardforhire »

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…

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!

Re: The Code It Yourself Manifesto (2016)

#35

Post by lostcolony »

jart wrote: post #32
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 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 very simple, with minimal assumptions, minimal state, and simple APIs into them, because that can keep it simpler than writing myself.

Re: The Code It Yourself Manifesto (2016)

#36

Post by pgt »

jart wrote: post #32
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 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.

Re: The Code It Yourself Manifesto (2016)

#37

Post by jariel »

enriquto wrote: post #31
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…

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

Re: The Code It Yourself Manifesto (2016)

#38

Post by jaaron »

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 the end, that no open or closed source solution exactly fit their needs. So they coded it themselves.

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.

There are exceptions, of course. Sometimes you have to build it yourself. But more often than not, it's much, much more effective to let go of your ego and collaborate with others, particularly on open source solutions in which you always have the option to fork the codebase and bring it, effectively, in house.

Generally, I find those that strongly advocate for NIH overly discount the long term costs of maintaining software.

Re: The Code It Yourself Manifesto (2016)

#39

Post by bitwize »

jart wrote: post #32
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 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…

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

Re: The Code It Yourself Manifesto (2016)

#40

Post by andrewjl »

jariel wrote: post #37
enriquto wrote: post #31

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…

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.

Post reply on HN