3 ms·

"I have not written any code in a little over 3 months. I have not learned anything new in the software field in the past year. I have been putting out the sa

by bsd44 5y ago

"I have not written any code in a little over 3 months. I have not learned anything new in the software field in the past year. I have been putting out the same old fires that were here two years ago." WOW that's just like 2021! Well the tech changed, but human behaviour stayed the same.

kqr 5y ago
It's been that way at least since the mid-sixties. I recommend going back to the early written material. By learning which parts of what was hard then are still hard now, we get a sense of where to focus our efforts. (As far as I've been able to tell, only three real problems have been solved since 1968: we have faster computers, higher level languages, and version control. All the other software engineering problems are just as hard now as they were then: We're still struggling with skill drain to management, thinking knowledge workers are fungible, team organisation, verifying features with users before building them, choosing proper abstractions, testing for reliability and understanding, resource management, documentation, modeling the domain clearly, prototyping the right way, and so on.
- kasey_junk 5y ago
  Hardware acquisition has gone from something that took multiple year planning cycles to push button. I largely agree that we are still solving many of the old problems but by enumerating only three things that have improved you do us a bit of a disservice.
  - kqr 5y ago
    That's an important one I hadn't thought of! One reason is personal bias: I work in a place that still orders physical hardware for the most part. Another reason is that the early software engineering papers and articles I've read haven't brought up hardware acquisition as a problem. Maybe they just didn't know it was a problem, or software is flexible enough to make it okay with slower hardware cycles?
  - ptx 5y ago
    Someone here on HN recently mentioned Tymshare[1], which was essentially the 1964 equivalent of AWS. Apparently CompuServe also started as a similar cloud service company in 1969. [1] https://en.wikipedia.org/wiki/Tymshare https://en.wikipedia.org/wiki/Tymshare
- ptx 5y ago
  > we have faster computers, higher level languages There was already LISP, COBOL and (a few years later) Algol 68, so maybe the only real improvement is the faster computers, making the high-level languages more widely applicable?
- urthor 5y ago
  Test driven development? Variable names that aren't two digits probably gets a shout.
mhh__ 5y ago
Read some ancient Greek history texts that have been translated into English. The world is much faster now but absolutely nothing has changed with us. Favourite example (Thucydides, could be wrong) - "An old man complained to a crowd that the teenagers were spending too much time lazing around talking to the opposite sex than training to fight" (or something to that effect), ever heard that one before?
- ceejayoz 5y ago
  Or Aristotle. “[Young people] think they know everything, and are always quite sure about it.”

by bsd44 5y ago

kqr 5y ago

It's been that way at least since the mid-sixties. I recommend going back to the early written material. By learning which parts of what was hard then are still hard now, we get a sense of where to focus our efforts. (As far as I've been able to tell, only three real problems have been solved since 1968: we have faster computers, higher level languages, and version control. All the other software engineering problems are just as hard now as they were then: We're still struggling with skill drain to management, thinking knowledge workers are fungible, team organisation, verifying features with users before building them, choosing proper abstractions, testing for reliability and understanding, resource management, documentation, modeling the domain clearly, prototyping the right way, and so on.

kasey_junk 5y ago
Hardware acquisition has gone from something that took multiple year planning cycles to push button. I largely agree that we are still solving many of the old problems but by enumerating only three things that have improved you do us a bit of a disservice.
- kqr 5y ago
  That's an important one I hadn't thought of! One reason is personal bias: I work in a place that still orders physical hardware for the most part. Another reason is that the early software engineering papers and articles I've read haven't brought up hardware acquisition as a problem. Maybe they just didn't know it was a problem, or software is flexible enough to make it okay with slower hardware cycles?
- ptx 5y ago
  Someone here on HN recently mentioned Tymshare[1], which was essentially the 1964 equivalent of AWS. Apparently CompuServe also started as a similar cloud service company in 1969. [1] https://en.wikipedia.org/wiki/Tymshare https://en.wikipedia.org/wiki/Tymshare
ptx 5y ago
> we have faster computers, higher level languages There was already LISP, COBOL and (a few years later) Algol 68, so maybe the only real improvement is the faster computers, making the high-level languages more widely applicable?
urthor 5y ago
Test driven development? Variable names that aren't two digits probably gets a shout.

mhh__ 5y ago

Read some ancient Greek history texts that have been translated into English. The world is much faster now but absolutely nothing has changed with us. Favourite example (Thucydides, could be wrong) - "An old man complained to a crowd that the teenagers were spending too much time lazing around talking to the opposite sex than training to fight" (or something to that effect), ever heard that one before?

ceejayoz 5y ago
Or Aristotle. “[Young people] think they know everything, and are always quite sure about it.”