Live data from Hacker News

We have used too many levels of abstractions

unixsheikh.com

41–50 of 564 posts

Re: We have used too many levels of abstractions

#41
post #39

> Question everything. Especially things that don't make any sense to you. Don't just assume that someone else knows better - that's how you quickly turn into a blind follower. That’s what I do by default since I was a kid, and I can tell you the social pressure not to is significant. I recall an interview I did once, and one reason I failed it was "questioning everything". It didn’t even felt like it, I was just ask…

Questioning everything also gets you stuck in bed asking why the sky is a different shade of blue. Others might have accepted the unknown and ate breakfast.

See, that’s the kind of social pressure I was talking about.

Re: We have used too many levels of abstractions

#42

> Question everything. Especially things that don't make any sense to you. Don't just assume that someone else knows better - that's how you quickly turn into a blind follower. That’s what I do by default since I was a kid, and I can tell you the social pressure not to is significant. I recall an interview I did once, and one reason I failed it was "questioning everything". It didn’t even felt like it, I was just ask…

Avoid architects who are not on pager duty.

Re: We have used too many levels of abstractions

#43
post #22

I think a good first step towards improvement in this space is by separating the terms 'abstraction' and 'indirection'. Programmers too often add indirections which don't provide abstraction: * The programmer wants to POST an object to a web server. * The programmer also wants to think about it at the level of POSTing an object to a web server. * And yet the programmer creates an HttpClient.java and an AbstractClient…

I think the reason people do that stuff is because they do provide abstraction, but they only do it in UML diagrams, not in the code.

I've found the shittest programmers to work with are the ones that think visually, because in their head they just deleted two boxes and four lines, but in reality all they did was add 40 lines of code that do nothing.

Re: We have used too many levels of abstractions

#45

I think there is one interesting angle to this problem. I am someone who grew up with the technology, as the levels of abstractions were being added. I am now benefiting from all those accumulated decades of knowledge. As the IT / development world was changing, I had enormous privilege and comfort to learn the things at the pace they were happening. Being able to assimilate changes over long decades. Be a witness to…

There will be an increasingly important history component in comp sci., software engineering, infosec, and associated fields. I think this is a place where the IT field has done a bad job and, as a result, we've had unbelievable amounts of "wheel reinvention".

I'd love to hear from somebody with experience in scientific or other disciplines and IT who could contrast their fields with ours. I only know that I have had to go out of my way to pick up a historical component to my IT education, whereas it seems like a historical foundation is part of traditional math, science, and engineering training.

Vernor Vinge was right, though-- software (and hardware) archaeologist will be a real job.

Re: We have used too many levels of abstractions

#47

I think there is one interesting angle to this problem. I am someone who grew up with the technology, as the levels of abstractions were being added. I am now benefiting from all those accumulated decades of knowledge. As the IT / development world was changing, I had enormous privilege and comfort to learn the things at the pace they were happening. Being able to assimilate changes over long decades. Be a witness to…

> spending a decade working with a low level programming language before you jump into high level programming language is simply not an option.

Nobody said that. But spending a week is definitely an option to all programmers, and many would benefit from it.

Re: We have used too many levels of abstractions

#48
In other words, cargo cult programming. I wrote about this two years ago [1] and received only polarised responses that either agreed with the point wholeheartedly, or attacked me viciously for gatekeeping. I wish there was a better way to cure this disease without triggering the professional immune systems of engineers who are highly vested in their favourite technologies.

[1] https://medium.com/the-engineering-manager-guide/cargo-cult-...

Re: We have used too many levels of abstractions

#49
post #38

It's not only developers we had a regress in skill in the art/vfx world as well. If there are no tutorials with step by step instructions on youtube most people can't resolve visual/art/vfx problems anymore. It's about the most basic things if you get people with "art" degrees today maybe 3 out of 10 can draw or sketch. If they are not in front of a computer they can't communicate visually. They are also not able to…

[deleted]

Re: We have used too many levels of abstractions

#50

One thing to keep in mind is that software for a dialysis machine requires a different approach from some overly generic CRUD app exposing how many mansions you have or something. There is a lot of asinine software in the world and that’s fine. Lots of “real problems” are pretty asinine and don’t require heroic engineering feats. Just slapping some bullshit together is good enough in a frightening number of cases. Ha…

> Software for dialysis machines

A sizeable percentage of which is made without source control, unittests, and just slapped together like the rest you described

Hospitals don't check software quality when making purchasing decisions (much beyond "this button doesn't work")

Post reply on HN