Live data from Hacker News

The Code It Yourself Manifesto (2016)

pestilenz.org

11–20 of 57 posts

Re: The Code It Yourself Manifesto (2016)

#11
Nowadays an approach that I find often worth trying is:

- download a project in a suitable language that claims to do what you need

- read its list of direct dependencies

- implement your own thing using those same libraries

- write your own replacement for any of those libraries that seem more trouble than they're worth.

Indications for when this is likely to go well:

- the top-level piece of software has grown its own configuration language

- the the top-level piece of software has dozens of options for tuning its behaviour

- the maintainers of the top-level piece of software have spun parts of it out as libraries, and they're being used by other people.

Re: The Code It Yourself Manifesto (2016)

#12
post #4

It is generally good to depend on well-tested, large and reliable libraries. I have done the code-it-yourself thing to smaller libraries, though. The quality of the maintenance work done on smaller libraries is by no means guaranteed. They can acquire bugs at any point in time and when they do it may be best to just replace them by home written replacements.

A large complicated well maintained and widely used library is infinitely preferable to a large complicated library you need to maintain yourself and used only by you. In a similar vein, a well known standard format (or encoding) will always be a better choice than some ad-hoc format you create yourself because not only will that standard have encountered and dealt with problems you haven't even considered, but there are also likely to be a plethora of libraries, frameworks, and tools that support that format, where as if you create something yourself you end up needing to create anything you need.

Your time is generally better spent working on solving your core problem rather than the dozens of ancillary problems that end up needing to be solved along the way (particularly where a whole bunch of other people have spent a whole bunch of time already solving those problems).

Re: The Code It Yourself Manifesto (2016)

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

Re: The Code It Yourself Manifesto (2016)

#16
I agree completely.

After dealing with the same sort of rot pattern in both software and services for years, I've set out to replace as much as I can with my own tooling.

Mostly this has meant developing a hybrid blogging, forum, note-taking and writing, DAG database, information archiving and retrieval system and dogfooding it as much as possible.

Re: The Code It Yourself Manifesto (2016)

#17

While I certainly would encourage and do encourage people to code (it) themselves, the claim that using that not doing so > mean[s] endless seeking, evaluating and further deviation from our goals. is simply not true. Only if software were written to serve ultra-particular and individual goals would that be the case. Software is written to serve needs - of fewer or of many. And while it may serve a more constrained s…

I don't know, it's certainly been the pattern I've experienced with Slashdot, reddit, Facebook, Twitter, Instagram, Windows, Debian, Ubuntu, Mac, Firefox, Chrome, Hotmail, Yahoo Mail, Gmail, Android, iOS, and so many other services and software that I'd be sitting here all day counting them all.

First, I find something which suits me.

Then, it starts growing from under me, typically in the direction of bloat and feature removal.

Then, the usefulness to abuse ratio drops gradually.

Then, I'm faced with having to migrate or simply abandon yet another platform.

It's a serious issue, but I believe we can overcome it with just this sort of approach combining FLOSS and dogfooding.

Re: The Code It Yourself Manifesto (2016)

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

Re: The Code It Yourself Manifesto (2016)

#19
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 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 even worse.

Rules for a good life: 1) own 2) understand 3) change!

Re: The Code It Yourself Manifesto (2016)

#20
I see the philosophy of "don't reinvent the wheel" taken to extremes in the React world, and before that, in the jQuery world. There is simply a plugin/component library for anything and everything you need to do, so relatively simple applications have monstrous dependency trees because it's easier to `npm install` the whole kitchen sink and use the little bits you need, than taking some time to understand & implement a smaller, focused alternative that could live in a `util.js` file in your project.

At least thanks to tree-shaking and bundler innovations, the end-users don't suffer from bloated bundle downloads, but your node_modules folder is still 600MB large.

Post reply on HN