Hacker News Reader

Comment by agentultra | Hacker News Reader

> There is no point in reinventing the wheel.

I wish there was a better way to phrase this. I understand the spirit of this advice but in software we don't get better compilers if we stick with the first compiler that gets invented.

I've reinvented many things simply to learn how they work. Sometimes I get ideas about how to do things better. Sometimes I do it for the challenge (I bet I could do that). Sometimes I find that I can cut out 2/3 of the code, half the features, and get a system that is easier to maintain and remove errors from.

It's hard to become a better software engineer if all you do is glue together libraries. It's hardly ever appropriate to write your own database from scratch in a production application. But it's also hard to understand how to write your own database if you never write one yourself.

View on HN

This one stood out to me too. One of the few things that has kept me going as a software engineer, both professionally and as an 'enthusiast', has been exactly this 'reinventing the wheel'. Just building stuff. Intentionally not researching how chat bots work and trying it myself first. Avoiding frameworks and starting with a simple HTTP server. And making all the mistakes I could've avoided.

Sure, if I want to get a job done I avoid this, or don't bill. And sure, there are plenty of programmers who get stuck in a 'local optimum' with their homebrew solutions.

But treating programming / software 'engineering' as something that is also about fun and learning and discovering rather than just income and career, has kept me from burning out and made me better at my job.

> Intentionally not researching how chat bots work and trying it myself first. Avoiding frameworks and starting with a simple HTTP server. And making all the mistakes I could've avoided.

Excellent ideas for learning about how those systems work. Honestly there's no better way. The problems arise when people assume their roll-your-own HTTP server is a good idea to deploy in prod.

Unless there's a really good business reason, take the knowledge you gained from that exercise to work, but leave the code at home.

I’ve thought of it like this. The “avoid NIH” rule guides your default attitude on any project you are getting paid to produce. You have limited time, resources, focus, or opportunity for your effort to make a difference.

The history of the Erlang language is a good example [0]. Ericsson engineers did deep dives into over 20 existing languages over three years before proving to themselves a new language needed to exist.

Totally agree that NIH applies to how you make decisions as a professional working for an organization. For personal projects, carte blanche.

0: https://www.erlang.org/course/history

> But it's also hard to understand how to write your own database if you never write one yourself.

You just took NIH to a whole new level.

Not sure if you were joking or not, but NIH doesn't really apply if it is a project for the sake of learning.

That isn't NIH. In fact it is often the opposite of NIH. It is a pre-requisite of becoming a true expert in the technologies that you are using.

NIH is writing your own database and using it in production.

But understanding how to write a database makes it easier to understand why your existing database works the way it does, and what its quirks should be.

For example suppose that you have a slow query. You EXPLAIN ANALYZE to get a query plan. Now what? It really helps if you can say, "What would a program to do this look like? How fast would it be?" And then be able to say, "And if I was to write a program to do this, how would I do it? How fast would that be?" And then if the second is faster you can ask, "How can I get the database to do what I think it should do?" (Hint, in most databases with temporary tables and indexes on them, you can force your desired query plan to within a factor of 2.)

That exercise really helps in optimization. But that exercise is only available to people who know how a database actually works.

Reply on news.ycombinator.com