←back to thread

628 points kiyanwang | 1 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 #
1. roguecoder ◴[] No.43644940[source]
Frameworks are just someone else's architecture.

They are helpful if you have the same problems as that other company, but I worry about software that uses frameworks because the programmers don't feel confident building their own. It means when it comes time to evolve beyond the off-the-shelf architecture, programmers keep plowing ahead far past when they should have added another level of abstraction & encapsulation.

On the other hand, I also see applications where people dogmatically avoid using pre-existing architectures but also don't take the time to build their own. You end up with references to one table scattered all across the code base in hand-composed SQL.

I'd much rather take an outgrown-framework over a spaghetti mess.