this post was submitted on 12 Oct 2024
73 points (95.1% liked)
Programming
17444 readers
239 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 [email protected]
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
You've just identified the most important skill of any software developer, IMO.
The three most valuable topics I learned in college were OS design basics, assembly language, and algorithms. They're universal, and once you have a grasp on those, a lot off programming language specifics become fairly transparent.
An area where those don't help are paradigm specifics: there's theory behind functional programming and OO programming which, if you don't understand, won't impeded you from writing in that language, but will almost certainly result in really bad code. And, depending on your focus, it can be necessary to have domain knowledge: financial, networking, graphics.
But for what you're taking about, those three topics cover most of what you need to intuit how languages do what they do - and, especially C, because it's only slightly higher level than assembly.
Assembly informs CPU architecture and operations. If you understand that, you mostly understand how CPUs work, as much as you need to to be a programmer.
OS design informs how various hardware components interact, again, enough to understand what higher level languages are doing.
Algorithms... well, you can derive algorithms from assembly, but a lot of smart people have already done a ton of work in the field, and it's silly to try to redo that work. And, units you're very special, you probably won't do as good a job as they've done.
Once you have those, all languages are just syntactic sugar. Sure, the JVM has peculiarities in how its garbage collection works; you tend to learn that sort of stuff from experience. But a hash table is a hash table in any language, and they all have to deal with the same fundamental issues of hash tables: hashing, conflict resolution, and space allocation. There are no short cuts.
Thanks for the input, it will make me think about how to approach how to get the skills I need.
I'd say I am decent with FreeRTOS which is pretty much just a scheduler with a few bells and whistles.
I haven't used assembly in a long while, so I know where to look to understand all the instructions, but I can't tell right off the bat what a chunk of assembly code does.
Algorithms, I am terrible at these because I rarely use them. I haven't worked in a big enough project where an algorithm is needed. I tend to work in finite state machine which is close to algorithms, but it's not quite it. And a big part of my job is interfacing peripheral chips for other to use.
You're welcome!
Oh, me neither. And that's not what I think is necessary; what's important is that you can generally imagine the sorts of operations which are going on under the hood for any given line of code. That there's no magic "generate a hash for a string" CPU operation, and that, ultimately, something is going to be iterating over a series of memory locations and performing several math operations on each to produce a numeric output. I think this awareness is enormously valuable in developers, and helps them think about the code they're writing in a certain way, and usually in a way that improves their code.
You use them all the time! Anything longer than a single operation is an algorithm.
Nobody is going to ask you to write a search function; however, being aware of Big-O notation, and being able to reason about time and space complexity, is important. On the backbend, it's critical. It's important if you're a front end developer - I blame the whole NodeJS library fiasco on not enough awareness of dependency complexity by a majority of JS developers.
I'd absolutely call FSM work "algorithms", and it sounds as if the projects you're working on is where these fundamentals are most important. Interfaces between hardware components? It's the most fraught topic in CIS! So. Many. Pitfalls. Shit, you probably have to worry about clock speeds and communication sheer; there's absolutely a huge corpus of material about algorithms for handling stuff you're working with, like vector clocks. That's a fabulous, interesting field. It's also super tedious, and requires huge attention to detail which I lack, so in a way I envy you, but an also glad I'm not you.
Any good resources you can share for/on each topic?
College.
I'm one of those folks who believes not everyone needs a degree, and we need to do more to normalize and encourage people who have no interest in STEM fields to go to trade schools. However, I do firmly believe computer programming is a STEM field and is best served by getting a degree.
There are certainly computer programming savants, but most people are not, and the next best thing is a good, solid higher education.