3 ms·

Maybe it's easy to overlook these things when you have a really deep computer science background, but coming to software engineering from a non-CS background (m

by dkarl 6y ago

Maybe it's easy to overlook these things when you have a really deep computer science background, but coming to software engineering from a non-CS background (math degree) I found lots of valuable knowledge in CS. The most important parts for me would be: - State machines. I run into a lot of state machines, especially incompletely specified ones. Not that everybody gets these wrong if they haven't studied state machines in a textbook and worked the exercises at the end of the chapter, but recognizing "oh, this is a state machine" gives me a mental framework, a notation, a vocabulary that other developers understand, and a better ability to understand when a problem is underspecified or inconsistent. - Queueing theory and algorithmic complexity. These two usually come in handy from the perspective of spotting and avoiding stupid mistakes. It's true that people can do a pretty decent job from a handful of rules of thumb, but not everybody has that minimum knowledge, and sometimes a problem has a twist that an imprecise rule of thumb doesn't account for. - Distributed systems. Just understanding the solution of a few problems in depth, and knowing from that how hard simple things really are, is incredibly valuable. Without that background, people can naively tackle extremely complex problems, bash their heads against them for years, and still underestimate the difficulty of the problems they've created for themselves by orders of magnitude. In general, the rigor of doing theoretical problems, the discipline of actually proving things, creates habits that uncover lots of non-happy path possibilities.

dgb23 6y ago
I also don't have a CS degree and am self-taught. And I very much agree with you that many CS concepts have quite a practical impact. Some of them more on the side of approach and selecting the right tech/solution, but some have a more hands-on practical use. - State machines: completely agree. I use them especially in the context of user facing stuff, like GUIs, animations and so on. In fact I would even argue that they are _inherent_: Even if you don't recognize and specifically structure your code around them, they are still _there_ just smeared all over your logic. - A&D I find ubiquitous are: sets, graphs, trees. Sets especially are underused and graphs are the most expressive data structures if you need them and can help you model complex, long lasting models. - Relational algebra is likely one of the most important concepts. It is fundamental to the Swiss army knife of databases: SQL. - Algorithmic complexity: I rarely use this formally, but it really helps to get a decent intuition for performance.
- franga2000 6y ago
  > Relational algebra Seriously? Currently working through my second databases course, I still can't help translating all of the relational algebra nonsense into proto-SQL in order to make sense of it. I was already working on large-ish business applications and databases for a few years before the first course and I didn't even know RA existed. Now it just gets in the way. Not to mention relational expressions or whatever that thing is called where you use the "exists" and "for every" operators, which I still haven't been able to apply in practice.
  - dgb23 6y ago
    For me the experience was different. I also knew SQL before, but after learning RA I first was slightly disappointed that SQL wasn’t as clean. But conceptually they’re the same. I think the interesting Aha moment was the realization that SQL is syntax on top of a mathematical concept. Before I was distracted by the practice of reading and writing stuff to disk with it, if that makes sense.
  - darkcha0s 6y ago
    Coming also from a SE/Practical background, the only time I need to use those complex expression in a SQL query, is when someone screwed up the datamodel, or over-engineered it. In theory you can do many things with SQL, but none of those things perform better than a straight up select query, which is usually what you're after-- performance.
908B64B197 6y ago
> State machines Probably one of the most powerful tool out here. You can catch a lot of things simply by identifying which state transitions should be possible and which shouldn't exist
AkshatM 6y ago
Can you please describe when you had to use formal queueing theory in your work? I have struggled - and failed - to find a use case relevant to daily SWE work, since (a) the probability distribution for most customers waiting in a queue is not known and must be "guessed" or predicted ahead of time using historical data and (b) nearly all queue requirements are simple (i.e. minimize total waiting time) and the solutions just as simple (scale up your queue consumers!)
- eindiran 6y ago
  Mostly simple things: if you have a messaging queue used for logging, and you need to predict the change in its memory footprint given some change in a message format before rolling out/testing the format change, just use Little's law. Or you need to determine the smallest number of consumers that you can have online safely to maximize how quickly you can do maintenance without degrading logging.
- dkarl 6y ago
  You might think that something as simple as Little's Law is intuitive, but people who haven't learned it don't always find its conclusions obvious, and they are less likely to see when a problem can be framed as a queueing problem. The value is really in simple stuff like this, where having something in your mental toolkit makes the difference between a problem requiring a trivial application of something you know versus requiring thought and creativity. A particular example I remember was a poorly architected system that was essentially two systems connected like queues in sequence. The first one was fast and lightweight, basically a gateway/hydrator for the second one, and could handle a very large backup with no ill effects. The second one was very slow and fell over quickly if too many items accumulated in the queue during a load spike. An easy short-term fix to make the system stable in production was to introduce artificial slowness in the first queue to buffer load spikes and prevent backups in the second queue. Little's Law points straight to this solution, but people who didn't have queueing theory in their mental toolkit had not considered fixing the system by slowing part of it down. It looked like a big leap of imagination for them, even if they found it intuitive to understand after it was pointed out.

by dkarl 6y ago

dgb23 6y ago

I also don't have a CS degree and am self-taught. And I very much agree with you that many CS concepts have quite a practical impact. Some of them more on the side of approach and selecting the right tech/solution, but some have a more hands-on practical use. - State machines: completely agree. I use them especially in the context of user facing stuff, like GUIs, animations and so on. In fact I would even argue that they are _inherent_: Even if you don't recognize and specifically structure your code around them, they are still _there_ just smeared all over your logic. - A&D I find ubiquitous are: sets, graphs, trees. Sets especially are underused and graphs are the most expressive data structures if you need them and can help you model complex, long lasting models. - Relational algebra is likely one of the most important concepts. It is fundamental to the Swiss army knife of databases: SQL. - Algorithmic complexity: I rarely use this formally, but it really helps to get a decent intuition for performance.

franga2000 6y ago
> Relational algebra Seriously? Currently working through my second databases course, I still can't help translating all of the relational algebra nonsense into proto-SQL in order to make sense of it. I was already working on large-ish business applications and databases for a few years before the first course and I didn't even know RA existed. Now it just gets in the way. Not to mention relational expressions or whatever that thing is called where you use the "exists" and "for every" operators, which I still haven't been able to apply in practice.
- dgb23 6y ago
  For me the experience was different. I also knew SQL before, but after learning RA I first was slightly disappointed that SQL wasn’t as clean. But conceptually they’re the same. I think the interesting Aha moment was the realization that SQL is syntax on top of a mathematical concept. Before I was distracted by the practice of reading and writing stuff to disk with it, if that makes sense.
- darkcha0s 6y ago
  Coming also from a SE/Practical background, the only time I need to use those complex expression in a SQL query, is when someone screwed up the datamodel, or over-engineered it. In theory you can do many things with SQL, but none of those things perform better than a straight up select query, which is usually what you're after-- performance.

908B64B197 6y ago

> State machines Probably one of the most powerful tool out here. You can catch a lot of things simply by identifying which state transitions should be possible and which shouldn't exist

AkshatM 6y ago

Can you please describe when you had to use formal queueing theory in your work? I have struggled - and failed - to find a use case relevant to daily SWE work, since (a) the probability distribution for most customers waiting in a queue is not known and must be "guessed" or predicted ahead of time using historical data and (b) nearly all queue requirements are simple (i.e. minimize total waiting time) and the solutions just as simple (scale up your queue consumers!)

eindiran 6y ago
Mostly simple things: if you have a messaging queue used for logging, and you need to predict the change in its memory footprint given some change in a message format before rolling out/testing the format change, just use Little's law. Or you need to determine the smallest number of consumers that you can have online safely to maximize how quickly you can do maintenance without degrading logging.
dkarl 6y ago
You might think that something as simple as Little's Law is intuitive, but people who haven't learned it don't always find its conclusions obvious, and they are less likely to see when a problem can be framed as a queueing problem. The value is really in simple stuff like this, where having something in your mental toolkit makes the difference between a problem requiring a trivial application of something you know versus requiring thought and creativity. A particular example I remember was a poorly architected system that was essentially two systems connected like queues in sequence. The first one was fast and lightweight, basically a gateway/hydrator for the second one, and could handle a very large backup with no ill effects. The second one was very slow and fell over quickly if too many items accumulated in the queue during a load spike. An easy short-term fix to make the system stable in production was to introduce artificial slowness in the first queue to buffer load spikes and prevent backups in the second queue. Little's Law points straight to this solution, but people who didn't have queueing theory in their mental toolkit had not considered fixing the system by slowing part of it down. It looked like a big leap of imagination for them, even if they found it intuitive to understand after it was pointed out.