←back to thread

628 points kiyanwang | 2 comments | | HN request time: 0.405s | source
Show context
bob1029 ◴[] No.43630646[source]
Not guessing is perhaps the most important thing to the business.

I developed a lot of my problem solving skills in semiconductor manufacturing where the cost of a bad assumption tends to be astronomical. You need to be able to determine exactly what the root cause is 100% of the time or everything goes to hell really fast. If there isn't a way to figure out the root cause, you now have 2 tickets to resolve.

I'll throw an entire contraption away the moment I determine it has accumulated some opacity that antagonizes root cause analysis. This is why I aggressively avoid use of non-vanilla technology stacks. You can certainly chase the rabbit over the fence into the 3rd party's GitHub repo, but I find the experience gets quite psychedelic as you transition between wildly varying project styles, motivations and scopes.

Being deeply correct nearly all of the time is probably the fastest way to build a reputation. The curve can be exponential over time with the range being the value of the problem you are entrusted with.

replies(5): >>43631055 #>>43631842 #>>43632734 #>>43637040 #>>43638701 #
Taek ◴[] No.43631055[source]
I always get a lot of pushback for avoiding frameworks and libraries, and rolling most things by hand.

But, most frameworks and libraries aren't built to be audit-grade robust, don't have enterprise level compatibility promises, can't guarantee that there won't be suprise performance impacts for arbitrary use cases, etc.

Sometimes, a third party library (like sql-lite) makes the cut. But frameworks and libraries that reach the bar of "this will give me fewer complications than avoiding the dependency" are few and far between.

replies(8): >>43631189 #>>43631275 #>>43631326 #>>43632119 #>>43632384 #>>43635012 #>>43635674 #>>43644940 #
jppope ◴[] No.43631189[source]
I completely agree - though there are places where I trust an implementation of things like a well known algorithm.

However, to add onto this, I'm consistently shocked at how often it is much CHEAPER to "roll your own." We've done some reviews on systems after a few years and the number of bugs and security vulnerabilities we experience with code based around packages is much MUCH higher. Its hard to put a number to it because the time cost of fixing those issues is variable, but its substantial. Its also amazing to me that it can be cheaper to build your own vs using a 3rd party vendor for something that would appear to be highly specialized - of course opportunity cost is a real thing.

replies(3): >>43631311 #>>43631650 #>>43638956 #
whstl ◴[] No.43631650[source]
The low quality of modern libraries is something that REALLY shocks me.

The library space has become competitive, and people are running them as business. The goal is not to be correct or even good, but to be a "first mover" and selling tutorials, books, Github sponsorships, Patreon subscriptions...

It's bad not only in terms of security, but also in terms of developer experience.

I am constantly amazed at how little documentation things have, at how many BASIC cases they don't cover (let alone edge cases) and how many security holes those libraries have, and the number of dependencies just keeps getting bigger and bigger.

Another issue is that newer developers are being taught just the newfangled library and have zero experience with the foundations. The number of React devs who don't know how to use HTML forms without a library is nuts.

replies(1): >>43631786 #
1. GiorgioG ◴[] No.43631786[source]
> The low quality of modern libraries is something that REALLY shocks me.

How could you be shocked? Everything that's happened in the software industry outside of medical/DoD has been about delivering features as fast as you can, quality be damned.

replies(1): >>43638749 #
2. whstl ◴[] No.43638749[source]
I am shocked because this was not always the reality.

I have qualified my statement with "modern".