Comment by bruce511 | Hacker News Reader

Comment by bruce511 | Hacker News Reader

In software, as in most things, most of learning is done by doing. Creating a clone of something from scratch is a really useful learning technique and has the benefit of a defined specification.

It doesn't even really matter if the job is even completed or if the program is ever used. The important part is the doing, not the result.

I confess we did similar things at uni 30 years ago, although we mostly re-implemented arcade games, not sql databases. Databases are likely more useful to understand.

All programmers have to go through 3 stages;

A) I program to prove to myself I can

B) I program to prove to others I can

C) I know I can write this, you know I can write this, but its cheaper and easier to use this existing, available, code to do the job.

I like c) programmers in business because they understand that the goal of the business is making money not generating code. A guy who -could- write SQLite, but then understands why -using- SQLite would be better, is enormously valuable.

(Not to mention his SQL chops are probably pretty good by then)

Regarding C), I think it actually gets tough.

> but its cheaper and easier to use this existing, available, code to do the job.

What often happens is that the existing, available, sometimes even popular and well regarded code has lots of issues that you may only find after you deploy the thing. Then, you need to decide what tack to take. Can you engage upstream? Do you end up maintaining third party code yourself to fix the issues? Working around quirky bugs? You may even find yourself so frustrated with all of the above that you wind up abandoning the dependency and writing something new in-house.

But honestly, getting back to the topic, sqlite is not one of those things. Sqlite is a very solid library.

Yes, I agree not every bit of available code is perfect. A lot of it is crap. Choosing an existing library is worth taking dome time and research over.

Inevitably some libraries will need replacing. In some cases we've ended up rolling our own. But in these cases the time spent with the discarded library is not wasted. Rather it gives us a chance to understand the domain better, to understand our needs better, and ultimately to have better criteria for making our choices.

Things like documentation, support, bug fixing, source code, and so on have all become important parts of the evaluation process.

Interestingly our internal libraries are often less-well documented (if at all) the author is sometimes no longer around, and it usually has all kinds of quirks we work around. This after taking longer, and costing more, written from an unclear spec by people not terribly familiar with the domain.

And yes, we've hone the nuclear route of ripping out and rewriting, and that is expensive , but no more expensive than defaulting to "write ourselves ", and indeed usually cheaper because we have a better idea of what we want.

I think one of the things you learn on your way to C) is when it makes sense to roll your own. It is difficult, and maybe something that actually happens after c.

It seems to be very hard to make that call in time, and in the past I feel like every time we chose to implement something on our own, the existing solution would have been better in hindsight, and every time we said "ok, that existing solution looks fine" it turned out to be a dumpster fire a year down the line. But obviously the times where you made the right call just don't stick out that much because stuff "just worked", and also, in case you think you made the wrong decision, the alternative could've been ever worse. But still, I guess everybody knows that feeling? :-)

The problem is that a lot of the existing code that will be chosen by type C is written by type A.

Type B is writing code for money, so it almost never gets reused outside an organisation.

Found the js programmer

The kind of people who write code to prove to themselves that they can, may be exactly the kind of programmers whose code we should be using.

They love programming, which means they do it a lot (beyond the bare minimum), which means they're probably pretty good!

An extension of C) is that this not only applies to open source. I was in a startup where the new employees decided to throw away working stable services to write their own version and they wasted a lot of time for little benefit. In the meantime the startup failed to deliver the necessary NEW functionality and we lost a lot of potential customers and sales people who were tired of waiting.

Working with other people's code is one of the most valuable skills. Be willing to live with existing code for a while and understand why it was implemented that way. Only then can you know what you should change.

I think I've been through A, B and C... and finally got back to A :D

My problem is that quite a few libraries we use eventually stop being sufficient (either because it has bugs, performance issues, limited use-case, too-wide use-case etc), and then we have to either contribute to it, with the politics involved which can be more work than the code changes, or we just bite the bullet and write things ourselves. For that reason, I find it really good to be capable enough to write things from scratch when that makes sense.

Reply on news.ycombinator.com