Recent searches
Search options
@anze3db 1) if learning to use a library or tool is a larger task than the one you are trying to solve, solve your primary task with basic methods.
2) never take on a subtask that is harder than the primary task. For example, if you need to display HTML emails in an application, do not write an HTML rendering engine. Extreme case but you can easily wind up there.
This is true in hardware too. If you find yourself designing an op amp, and your end goal is not to make an op amp, stop.
@anze3db I'm still at the map/filter/reduce phase somewhere in the middle of the down slope.
@anze3db *whistles innocently*
@anze3db One of the worst projects I worked on was a DB that had been "future proofed" against any possible need the DBA/architect could conceive of. The result was that the simplest, most important use cases were nearly impossible to do quickly and easily.
It has been my experience that people who design such code are also the least likely to accept criticism because, of course, they are doing everything by the book w/out realizing that the expert author hasn't written real code in years.
@anze3db Spot on