this post was submitted on 26 Feb 2024
137 points (97.2% liked)

Programming

17524 readers
356 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 2 years ago
MODERATORS
 

As someone who spends time programming, I of course find myself in conversations with people who aren't as familiar with it. It doesn't happen all the time, but these discussions can lead to people coming up with some pretty wild misconceptions about what programming is and what programmers do.

  • I'm sure many of you have had similar experiences. So, I thought it would be interesting to ask.
you are viewing a single comment's thread
view the rest of the comments
[–] lemmyvore@feddit.nl 15 points 9 months ago (1 children)

Which leads to the other old saying, "computers do what you tell them to do, not what you want them to do".

As long as you don't let it turn around and let the computer dictate how you think.

I think it was Dijkstra that complained in one of his essays about naming uni departments "Computer Science" rather than "Comput_ing_ Science". He said it's a symptom of a dangerous slope where we build our work as programmers around specific computer features or even specific computers instead of using them as tools that can enable our mind to ask and verify more and more interesting questions.

[–] huginn@feddit.it 6 points 9 months ago (1 children)

The scholastic discipline deserves that kind of nuance and Dijkstra was one of the greatest.

The practical discipline requires you build your work around specific computers. Much of the hard earned domain knowledge I've earned as a staff software engineer would be useless if I changed the specific computer it's built around - Android OS. An android phone has very specific APIs, code patterns and requirements. Being ARM even it's underlying architecture is fundamentally different from the majority of computers (for now. We'll see how much the M1 arm style arch becomes the standard for anyone other than Mac).

If you took a web dev with 10YOE and dropped them into my Android code base and said "ok, write" they should get the structure and basics but I would expect them to make mistakes common to a beginner in Android, just as if I was stuck in a web dev environment and told to write I would make mistakes common to a junior web dev.

It's all very well and good to learn the core of CS: the structures used and why they work. Classic algorithms and when they're appropriate. Big O and algorithmic complexity.

But work in the practical field will always require domain knowledge around specific computer features or even specific computers.

[–] lemmyvore@feddit.nl 4 points 9 months ago* (last edited 9 months ago)

I think Dijkstra's point was specifically about uni programs. A CS curriculum is supposed to make you train your mind for the theory of computation not for using specific computers (or specific programming languages).

Later during your career you will of course inevitably get bogged down into specific platforms, as you've rightly noted. And that's normal because CS needs practical applications, we can't all do research and "pure" science.

But I think it's still important to keep it in mind even when you're 10 or 20 or 30 years into your career and deeply entrenched into this and that technology. You have to always think "what am I doing this for" and "where is this piece of tech going", because IT keeps changing and entire sections of it get discarded periodically and if you don't ask those questions you risk getting caught in a dead-end.