/tech/ - Technology

that's not really possible, there's way too much history of technology to do it justice in brief, and if you're looking for actionable engineering insights from it you're going to have an unfortunate time

did you have a specific wheel reinvention in mind? I think frontend devs run into this the most with the constant development of novel frameworks but the real solution to that is just to keep JavaScript programmers in a dog crate when they're not working

>>18480
"Should"? Why phrase the question as a moral one. very bizarre. The answer is no.

The Art of Computer Programming is a good reference for many types of algorithms.

>>18483
Most software engineering does not deal with complex algorithms
The challenges of the field are usually not low level. They are architectural and social.

>>18482
Engineers are supposed to have ethics or some stuff liek that.

>>18485
Engineering ethics have nothing to do with this. And there are no ethics that engineers have to abide by, not in any widespread manner.

Yes, but until relatively recently no one had compiled that history. Until this great book was released near the end of 2021.

Cryptanalysis during WWII and the ENIAC are fun histories
Don't know any books on them though

I understand the idea, the arts do try to cover milestones. Yet with computing history there is far more overcoming the limitations of the tools of the time. For example if you wounder why ed fights the user to the point of making it impossible to have a practical workflow that is because it was made when teletypes were the only option. Another example is juggling two Motorola's 68k CPUs is much harder then a simple dual core CPU.

>>18491
This looks so cool

>>18481
Well there is art history despite the how much art is created every day thanks to notable examples / eras where certain styles art was trendy, certainly each field has some notable points that could be drawn from. It'd prevent some amount of wheel-reinvention. Doesn't have to be comprehensive.
>>18491
Looks interesting, saved.

>>18486
>And there are no ethics that engineers have to abide by, not in any widespread manner.
maybe not in your barbaric civilization

https://engineerscanada.ca/sites/default/files/Yukon/APEY_Code_Of_Ethics.pdf

fuck that. useless churn guarantees me job security. why the hell would i want to read anything like that? do you know boring programming is my dude.
maybe in some socialist utopia, where people pursue programming for passion, not in this capitalist hellscape.

>>18549
I made a classmate cry once by saying that lawyers who don't know history are doomed to become indoctrinated mercenaries. I think the same thing is applicable to programmers. The fields are rather similar. Also if you aren't going to fuck off and learn to be a more well rounded person in undergrad, when the hell are you going to do it?

>>18484
I don't get what "architectural and social" wheels you think are being reinvented. Wouldn't that imply project managers the ones are in need of studying history?
Regardless, Multics' history is relevant to systems programming https://multicians.org/history.html

idk some of the best programmers I have hired did not even study how to program at college.

>>18554
Dropped your flag

>>18484
>The challenges of the field are usually not low level. They are architectural and social.
i have no idea what you mean by this

>>18548
Rude
>>18551
>I don't get what "architectural and social" wheels you think are being reinvented.
I'm not OP. I didn't mean to imply such things are being reinvented. I meant to say that the challenges most software engineers face aren't due to algorithms or some weird implementation of something, rather it is all the other things, which include arquitecture and software engineering stuff like requirements, planning, design etc. Although, systems design is done very poorly so things do get reinvented (poorly) all the time. With regards to social, I swear people doing "agile and scrum" rediscover the infamous waterfall method and basic planning principles all the time.
>>18557
>i have no idea what you mean by this
Software engineering except the programming and server/CDP/CDI parts.

>>18480
most people use programming principles to 'not repeat mistakes'. however most of these programming principles (SOLID, DRY, etc)
are very dependent on context and either can be ignored or are obvious.
as for reinventing the wheel, thats what libraries are for.
as for ethics, theres tons of books on technology ethics. however, you are either a codemonkey or you are already selling your soul to porky for profit

>>18558
>I swear people doing "agile and scrum" rediscover the infamous waterfall method and basic planning principles all the time
not really, it's the managers who do because waterfall and what passes for agile in companies is basically micro-management. programmers don't "discover" it, management does because it's more attractive to them. there are charts and coloured graphics with little featureless men representing "the user" and little clouds representing "the cloud" and so on.
if you want to see a pure programmer way of doing things, look at open source development, it's all very focused on code and discussion about it in issue trackers and mailing lists, there are hardly ever any formal planning documents or endless meetings about what do we really want. generally if someone is struggling to get their idea across, they will quickly knock up a prototype and show what they mean or make a patch that adds what they want and send it to the maintainer. like Linus said "talk is cheap, show me the code".

>>18561
academic software engineering is actually more heavyweight than agile, look at formal methods and even traditional development (pejoratively called 'waterfall') uses fully fleshed use cases and design documents as per IEEE standards (still a ton of companies do this instead of agile). Sad to say but agile is still probably the methodology with the least amount of ceremony corporate environments are willing to accept.