←back to thread

628 points kiyanwang | 3 comments | | HN request time: 0s | 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 #
noduerme ◴[] No.43631275[source]
This is a hard take, just because we all build on stacks. When we trust that Math.Abs() is going to work in some language, or that some socket library is going to do what it says on the tin, we're standing on the shoulders of giants. I also avoid frameworks as much as possible, but by frameworks I mean anything I'd rather roll myself in a scripting language, particularly when learning and keeping up with the framework seems like more of a hassle. But for the layers and layers of underlying software and hardware behind me writing REST calls and async functions?

Also, there are higher level libraries that are sometimes good, because why reinvent the wheel every time you make something? Pixijs is one I use a lot. Also, Chart.js. Jquery. Moment.js. Good ol' Bootstrap 4 alpha's CSS handles a ton of use cases, and I never need to think about it again. There's very little in those that I haven't at one time or another rolled myself, but having a toolkit that you know and doesn't change much saves you a lot of time. The danger is more getting into libraries that aren't already dead, and are still in active development ;)

replies(1): >>43631652 #
chrisweekly ◴[] No.43631652[source]
Moment.js is one of those libraries to avoid; the bloat....
replies(1): >>43632154 #
1. aabaker99 ◴[] No.43632154{3}[source]
I still like Moment because it offers better control of time zones that aren’t the browsers time zone when compared to the builtin Date APIs.

Do you have a recommendation to replace Moment for that use case?

I’m hopeful for the future with JavaScript Temporal.

replies(2): >>43632877 #>>43637534 #
2. microflash ◴[] No.43632877[source]
dayjs is a similar library that I’ve used to replace Moment with minimal effort.
3. g8oz ◴[] No.43637534[source]
A maintainer of moment.js has moved on with an immutable rewrite called luxon.js. Highly recommended.

https://github.com/moment/luxon/blob/master/docs/why.md