> 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.
We have used too many levels of abstractions
41–50 of 564 posts
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…
Re: We have used too many levels of abstractions
#43I 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'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
#44Re: We have used too many levels of abstractions
#45I 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…
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
#46Re: We have used too many levels of abstractions
#47I 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…
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[1] https://medium.com/the-engineering-manager-guide/cargo-cult-...
Re: We have used too many levels of abstractions
#49It'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…
Re: We have used too many levels of abstractions
#50One 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…
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")