No.18481
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
No.18482
>>18480"Should"? Why phrase the question as a moral one. very bizarre. The answer is no.
No.18483
The Art of Computer Programming is a good reference for many types of algorithms.
No.18484
>>18483Most software engineering does not deal with complex algorithms
The challenges of the field are usually not low level. They are architectural and social.
No.18485
>>18482Engineers are supposed to have ethics or some stuff liek that.
No.18486
>>18485Engineering ethics have nothing to do with this. And there are no ethics that engineers have to abide by, not in any widespread manner.
No.18493
Cryptanalysis during WWII and the ENIAC are fun histories
Don't know any books on them though
No.18501
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.
No.18502
>>18491This looks so cool
No.18512
>>18481Well 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.
>>18491Looks interesting, saved.
No.18549
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.
No.18550
>>18549I 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?
No.18551
>>18484I 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 No.18554
idk some of the best programmers I have hired did not even study how to program at college.
No.18557
>>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
No.18558
>>18548Rude
>>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 thisSoftware engineering except the programming and server/CDP/CDI parts.
No.18559
>>18480most 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
No.18561
>>18558>I swear people doing "agile and scrum" rediscover the infamous waterfall method and basic planning principles all the timenot 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".
Unique IPs: 16