3 ms·
> Moore also has a corollary called Do It Yourself!, which encourages you, in general, to write your own subroutines rather than import one a canned subroutine
by acjohnson55 9y ago
> Moore also has a corollary called Do It Yourself!, which encourages you, in general, to write your own subroutines rather than import one a canned subroutine from a library.
The other side of this coin is NIH Syndrome. I've seen that go wrong in all sorts of ways.
One of the key skills of being a great engineer in the real world is exercising good judgment whether to "build or buy".
- erikb 9y agoThe steps of learning <anything>. Beginner: Learn the basics, be proud of getting something done that works, even though it might not be a useful result. Experienced: Learn the systems. Figure out which system is more helpful than others. But don't worry too much before you start learning a new system. Even a "bad" system will teach you something valuable. In the end you need to learn far more than one system anyways to progress. Expert: Learn that no system is perfect and use them freely according to context, maybe create a few yourself. See that even these "bad" systems come in handy once in a while. Master: Don't bother to get here. Even most freaks won't get here and from those who do most will tell you that they had no choice to do something else and they were just lucky that at least in this area they had talent. You're probably better off than them in general terms. If you want, learn here that <anything> is just one system. Welcome to the next abstraction level as Experienced. (This system about learning is developed by yours truly.)
- swyx 9y agohow many levels of abstraction can you name? i think that would be a useful exercise.
- logfromblammo 9y agoIn the real world, anecdotally, my employers have always preferred to buy 160 hours of my time rather than share 480 hours of someone else's time with 1000 other customers. It may have been because that person is then 1/1000th as responsive to their specific needs. It also may have been because that person wasn't cleared, and paranoia requires their code to be vetted before allowing it within breathing distance of our network. Or it may have been because buying a third-party tool requires approval of the manager's manager's manager, while rolling your own is the manager's call. I have never seen a company that makes it easy to buy a third-party license, and never a company that makes it easier to use a gratis licensed software than a paid one. They're all afraid that GPL will infect the code, and it will dance out of our source control onto the Internet like children following the Pied Piper. And on the other side of that coin, I have also seen licensed third-party software become vastly more trouble than it was worth, especially when it came time to upgrade it to a newer version. In general, though, if a third-party tool already does exactly what you need it to do, and you never need it to do anything else, it is always better to license it, configure it correctly once, and then never touch it again (aside from security-related patches).
- dllthomas 9y ago> I have never seen a company that makes it easy to buy a third-party license, and never a company that makes it easier to use a gratis licensed software than a paid one. Meeting anecdote with anecdote, I've never worked at a company that made paying for licensed software easier than using gratis.
- HumanDrivenDev 9y agoI think a degree of skepticism is required with NIH. I'm probably not going to roll my own crypto, or high performance statistical routines. But if something invented elsewhere "solves" a problem that really isn't rocket science, or if it's a framework - I will almost always avoid it.
- virmundi 9y agoout of curiosity, did you roll your own logging framework? When I read that point, logging came to mind. Should I use SLF4J, or simply print to out?
- flukus 9y agoThat's a wheel I have reinvented to good effect. Most logging libraries are quite dumb, if you set your threshold to info you get way to much information, if you set your threshold to exception you lose to much information from before the exception was thrown. Different messages from different threads are all mixed together, etc. My app specific logger is aware of the context it is running in, it will store all the context but only write it on an exception or error and discard it otherwise, so I get all the information I need without the noise from the 99.9% of the time I don't need it. I do use logging libraries, but they are for the low level stuff like file truncation, rollover, etc and I wish there were "logging" libraries that did just those tricky little parts on let me write the 50 or so LOC that the high level interface needs.