Technology

59405 readers

2612 users here now

This is a most excellent place for technology news and articles.

Our Rules

Follow the lemmy.world rules.
Only tech related content.
Be excellent to each another!
Mod approved content bots can post up to 10 articles per day.
Threads asking for personal tech support may be deleted.
Politics threads may be removed.
No memes allowed as posts, OK to post as comments.
Only approved bots from the list below, to ask if your bot can be added please contact us.
Check for duplicates before posting, duplicates may be removed

Approved Bots

founded 1 year ago

MODERATORS

[email protected]

Older Computer Programmers & Engineers (lemm.ee)

submitted 8 months ago by [email protected] to c/[email protected]

20 comments fedilink hide all child comments

Lately, I was going through the blog of a math professor I took at a community college back when I was in high school. Having gone the path I did in life, I took a look at what his credentials were, and found that he completed a computer science degree back sometime in the 1970s. He had a curmudgeonly and standoffish personality, and his IT skills were nonexistent back when I took him.

It's fascinating to see the perspectives on computing and how many of the things I learned in my undergraduate were still being taught way back to the 1950s. It also seems like the computer science degree was more intertwined with its electrical engineering fraternal twin.

Although the title of this post is inherently provocative, I'm curious to hear from those of you who did computer science, electrical engineering, or similar technical degrees in decades past. Are there topics or subjects that have phased out over the years that you think leave younger programmers/engineers ill-equipped in the modern day? What common practices were you happy to see thrown in the dumpster and kicked away forever?

The community also seems like it was significantly smaller back then and more interconnected. Was nepotism as prevalent in the technology industry then as it is today?

This is just the start of a discussion, please feel free to share your thoughts!

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 11 points 8 months ago (2 children)

I did a computer science degree in the equivalent of a community college then followed with software engineering in an engineering university. Graduated in 2008.

I find that software development and IT in general was a lot simpler back then than today. Nobody required any kind of certification to get a job.

Early 2000s, when you had a problem in your project, you really had to mess around and try things to find the solution. You couldn't really so much on stackoverflow or similar sites.

[–] [email protected] 10 points 8 months ago (2 children)

Things are much simpler now. Even little things. For instance error messages. They used to be cryptic as hell, but these days there is more of an emphasis on communication.

The only thing more complex is the volume of choice. There are just soooo many ways to do something that picking a way can be daunting. Its led to a situation where you have to hire based on ability to learn rather than ability with a specific toolchain.

[–] [email protected] 5 points 8 months ago

Things are much simpler now. Even little things. For instance error messages. They used to be cryptic as hell, but these days there is more of an emphasis on communication.

I don't know. I worked with old IDEs like Turbo C, Turbo Pascal or some of the earliest versions of Visual Studio and I was able to know from the output where the error occurred from the error message and could work with a debugger to find the true source.

The only thing more complex is the volume of choice. There are just soooo many ways to do something that picking a way can be daunting. Its led to a situation where you have to hire based on ability to learn rather than ability with a specific toolchain.

That's true though. And also how IT evolved into different other fields, line DevOps for example. Now there's an *Ops for almost everything. The latest bring machine learning. And each have their own million ways to do things with so many certifications.

[–] [email protected] 14 points 8 months ago (1 children)

I wouldn't say that.

Software today, in the real business world, is extremely complex, simply because of all the layers you have to understand.

Today I have to know about Kubernetes, Helm, CI/CD, security/policy scanners, Docker, Maven, Spring, hibernate ,200 libraries, Java itself, JVM details, databases , and a bit of JavaScript, Typescript, npm, and while we're at it, react. And then of course the business logic.

I'd argue, in today's world, nobody actually understands their software completely. I'm not sure, when exactly the shift from raw dogging assembler and counting cycles to the mess of today happened, but I'd argue, software today is much much more complex and complicated.

[–] [email protected] 3 points 8 months ago (1 children)

I’d argue, in today’s world, nobody actually understands their software completely. I’m not sure, when exactly the shift from raw dogging assembler and counting cycles to the mess of today happened, but I’d argue, software today is much much more complex and complicated.

It seems from history that things nobody actually understands eventually implode and are rebuilt from scratch, Samsara wheel and all that.

I'm waiting with anticipation for Kubernetes and the Web (as it exists) to die, die, die.

I’m not sure, when exactly the shift from raw dogging assembler and counting cycles to the mess of today happened, but I’d argue, software today is much much more complex and complicated.

There are concepts of layering and modularity. At some point the humanity in general has mixed them up. One can treat a module like a black box in design. One can't treat layers as if they were completely independent, because errors and life cases cross layers. I mean, the combinatorics of errors in module separation and layer separation are different.

Ah, many words to try to say a simple thing.

[–] [email protected] 1 points 8 months ago (1 children)

I thinke leaky abstraction is the word you're looking for, and I agree.

My goto comparison is file systems. I can call open() on a file without being bothered about almost anything behind the file descriptor. I don't care whether it's a ramdisk, an SSD, a regular hard, SMB mount over Tokenring or whatever. There is a well defined interface for me to work on and the error cases are also well defined. The complexity is hidden almost completely.

But if I want to do anything in k8s, the interface is usually exposing me to anything that goes wrong under the hood and doesn't hide anything at all.

The absolute worst example of the is Helm. It adds almost nothing for 99% of the use cases except complexity, actively stands in your way many times and the entire functionality actually used in most cases is Bash-style Variable expansion.

[–] [email protected] 0 points 8 months ago

I thinke leaky abstraction is the word you’re looking for, and I agree.

More or less yes.

+1 for Helm hate.

[–] [email protected] 7 points 8 months ago

I'm around the same time. At my first job I had a stack of reference books for the languages and technologies I use.

I would actually argue things are simpler now based purely on the fact that there is such a big ecosystem of libraries and services available that you don't need to write everything yourself.

It's true it can be hard to find what you want but I've found LLMs (at least ones that search the internet like copilot) are really good at pointing you to existing options.