Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We have used too many levels of abstractions

unixsheikh.com

Post reply on HN
Print view View original

551–560 of 564 posts

Re: We have used too many levels of abstractions

#551

Post by seabass-labrax »

BigJono wrote: post #521
_moof wrote: post #512

Earlier quoted context omitted.

Ask a pilot to recite Navier-Stokes from memory. They won't even know what you're talking about. Building a gas turbine engine without training? Forget it. The only electrical engineering a pilot needs to know is the difference between volts and amps, and what it means when a breaker pops. The EEs who design the avionics are not so fortunate.

Nobody is talking about building the engine lol, you're all making the exact "just program everything in assembly" comment the author was taking the piss out of. You have probably 80% of people using React that have absolutely no idea how the three main functions in it's API work. That's the equivalent of a 747 captain having no idea what the TOGA button does and only knowing that that's the one you press to do a tak…

To support your point, having a locked TOGA mode can be extremely dangerous even if the pilots know exactly what it does. The equivalent would be a risk of death if you just once wrote a React component that had an infinite loop in its render function; I would venture a guess that if there was that kind of risk, most programmers would resign in very short order!

Re: We have used too many levels of abstractions

#552

Post by seabass-labrax »

ahazred8ta wrote: post #524
steeleduncan wrote: post #151

There was a point in the history of aviation where anyone who could fly a plane was also capable of constructing and designing one. I wonder if there were similar concerns at that time about a future where someone could be in a cockpit of a plane without truly understanding how the machine works from first principles? Today that type of concern would seem absurd, and we've gotten used to the idea that flying a plane…

"One day the stars will be as familiar to each man as the landmarks, the curves, and the hills on the road that leads to his door, and one day this will be an airborne life. But by then men will have forgotten how to fly; they will be passengers on machines whose conductors are carefully promoted to a familiarity with labelled buttons, and in whose minds knowledge of the sky and the wind and the way of weather will b…

Thank you for sharing that here. Your post is why there should be a 'favourite' button for comments as well as posts. Edit: there is one, and I've just clicked it!

Re: We have used too many levels of abstractions

#553

Post by LorenzoGood »

joschi03 wrote: post #161
donatj wrote: post #139

> Power steering is yet another level of abstraction that further improves the driving experience. I am a pretty firm believer that antilock brakes are a bad abstraction that might cause fewer accidents, but often more dangerous accidents than they prevent. They avoid a class of accident caused by the brake’s locking limiting your ability to steer. They cause a whole class of accidents where you hit things at a highe…

On tarmac you slow down faster with ABS. The friction is higher when the tires are _not_ sliding. Fastest deceleration happens just at the point before tires would start to slide. On gravel/snow, ABS perfoms worse. But 99% of the time you likely are not in such a context.

Unless you live in a place with snow 50% of the year.

Re: We have used too many levels of abstractions

#554

Post by ndjfkfbfnrk »

steeleduncan wrote: post #151

There was a point in the history of aviation where anyone who could fly a plane was also capable of constructing and designing one. I wonder if there were similar concerns at that time about a future where someone could be in a cockpit of a plane without truly understanding how the machine works from first principles? Today that type of concern would seem absurd, and we've gotten used to the idea that flying a plane…

[dead]

Re: We have used too many levels of abstractions

#555

Post by gavinhoward »

sarchertech wrote: post #205
BiteCode_dev wrote: post #109

Earlier quoted context omitted.

You can actually see this with new frontend devs. They know only full SPA frameworks, they have never seen a dump of an HTTP message, headers and verbs are abstract things to them. Hell, many of them don't know you can have fully functional websites with zero JS, including payment, video, login, etc. I started to write an HTMX tutorial ( https://www.bitecode.dev/p/a-little-taste-of-htmx-part-1 ) because I noticed a l…

I started writing a book for exactly this reason. https://www.networksfromscratch.com/ It will take me 10 years to finish it at the pace I’m going though :)

Oh, please, oh please! Get that thing done as fast as you can!

And for once in my life, I'm actually going to sign up for your email list because I want to know when this thing is done!

Re: We have used too many levels of abstractions

#556

Post by epalm »

It’s not possible for everyone to know everything. Almost no one knows how to fix their , but at some point in history the opposite was true. Abstractions make technology available to the masses.

However, too much abstraction, on a long enough timeline, where does it end? The blob-humans in Wall-E, where no one knows anything and everything is done for us?

I’ve definitely felt in the last ~10 years of my career that the tools and libraries I use in development contain “too much magic”.

Re: We have used too many levels of abstractions

#557

Post by klysm »

euniceee3 wrote: post #368
klysm wrote: post #275

Earlier quoted context omitted.

Although I agree that many sites could get away without the bloat of client side JavaScript frameworks, sometimes the complexity is truly justified and it enables you to deliver a better product. Complex dashboards with data intensive interactions and explorations are so much easier with React or something similar

Agree with you here. Also need the frameworks to scale work out to a team. But that is what subdomains are for, dashboard.example.com will deal with all that over head, but forcing the marketing-friedly splash page on example.com to be in React is overkill.

React and JSX are still my preferred method for writing HTML - so much better than templating and there's no reason you can't have the output be a static site for something like a marketing friendly splash page. Now is React a great fit for that? Probably not, but it let's me use a consistent set of tools.

Re: We have used too many levels of abstractions

#558

Post by topmax »

palata wrote: post #412
austin-cheney wrote: post #285

Earlier quoted context omitted.

Pilots must still understand how planes work. That’s called aviation. Most software devs have absolutely no idea how their software platform works. Most are overpaid API monkeys.

Tell that to the passengers of those 737 MAX flights where the pilots did not know how to disable the failing AoA correction... I wouldn't bet that most pilots know more about how the planes they fly work than software devs know about their computers. For one, most planes today rely heavily on computers. Do they teach electronics in "aviation"?

I don't think that most pilots do know how a plane work, they know the fly theory of course.

Re: We have used too many levels of abstractions

#559

Post by drzaiusx11 »

codegeek wrote: post #436
drzaiusx11 wrote: post #430

Earlier quoted context omitted.

I strongly believe tech interviews should be about seeing _how_ a candidate works and less about _what they know_. Everyone has holes in their knowledge, but can easily be filled by training or on the job experience if they have excellent problem solving skills. Maybe they never needed to know the protocol level but can deliver excellent ux results regardless. I've started nearly every position in my career in a diff…

"how_ a candidate works and less about what they know" I do get your point but depends on the role you are hiring for. I have had candidates get upset at me (for example: bootcampers) because they couldn't explain how to submit a basic HTML form but wanted me to look at their github "portfolio" that was done during the bootcamp with React/Express Code and what not. Their title was "Front end React Developer". That is…

If you're specifically _not_ looking for react front-end developers, then the on-the-job training for those candidates on the position you're filling _can_ be cost (time) prohibitive in certain orgs to "get up to speed." Likely you should filter those candidates out earlier if that's your case. Sounds like you are, but I'd like to also point out that this strategy has it's own costs.

For example, I would take a react developer with obvious gaps and a strong willingness to learn on my back-end services team over a passable back-end dev who was set in their ways (unwilling/uneager to learn new tech, entrenched opinions stated as fact, etc.)

Naturally, my approach is not a one size fits all situation and a great deal depends on org structure and mentorship opportunities being in place for it to work. The benefit being you avoid monoculture "silos", and have more cross collaboration and transfer opportunities between teams (some may call this "full stack", I wouldn't)

Several high performers on my team are "self-taught", work comfortably across several languages today and can pickup new tech easily. They came in knowing their "one stack" at the time. If they were "bootcampers" or not seems irrelevant and somewhat reductive/offensive.

That said, if the candidate in question shows _no_ understanding of their problem domain, can't reason their way out of a paper bag, and get visibility upset from questions when you try and tease that out, that is a certainly a red flag in my book.

With respect to your example given, however, it could be argued that http details because of the abstractions in place inherent in react, aren't critical domain knowledge for what is essentially a UX dev. If they can ship an experience your users enjoy more than the candidate that can recite the HTTP 1.1 RFC and cannot, then what have you gained in hiring the latter other than maintaining a culture of pedantry?

TL;DR it comes down to how much risk your team is willing to take on, as there's always risk inherent in hiring ANY candidate, including those that don't already check all your boxes in regards to tech know-how. I'm merely stating that by overlooking candidates that don't fit your self-imposed mold, you're likely missing opportunities for rewards that can pay dividends when it does work.

Re: We have used too many levels of abstractions

#560

Post by Heyso »

anonzzzies wrote: post #378

The future looks especially bleak because LLMs, for many who I work with, are doing with logic what Google did with memory. 'Just ask chatgpt' will be a thing ; maybe not chatgpt, probably indeed just google but with a their chatbot which can do 'logic' and abstractions built in. Google -> you don't need a longterm memory, just Google it. So with good LLMs (and the latest iteration of chatgpt is really good at a lot…

> ' Just ask ChatGPT '

Yeah I heard that from coworkers. Lazy mind, yes. Read the doc, look one example, check one stackoverflow link and you will know how you make a caroussel UI component...

And please do not use it to try understanding some logic in your codebase. Try even less giving him a small snippet of the codebase, thinking it will magically understand what it does and correctly imagine what all the missing related code of snippet is and does. ( ! )

Most of the time I just wanna scream "use you brain". By the time he wrote his first sentence to the IA, I've resolved the issue, or at least have a clue. It is really infuriating because what more is that ChatGPT need a -minimum- precise request to be expected to give a useful response. When the request from the user is blatantly inprecise kinda like "help, thing doesn't work", I just feel bad for the IA having to deal with terrible communication, and for myself for having to deal with that coworker. Thanksfully when I am the one being asked help, I know the project, can look into the code, and coworkers can show me the issue instead of failing to explain it.

Yeah that is why I like programming, computers only accept precise communication, it is not "move that div on the left" but "move div by id X to the left of itself" 120px over 200ms with a linear speed".

Only once ChatGPT did better than my mind or google : someone was searching the name of a bank starting wirh the letter "o".

Your statement is correct, google replace a lot of my memory, maybe someone could call me lazy too.

Maybe ChatGPT will have his use for me one day.

Post reply on HN