9 ms·

Good code doesn’t just solve a problem, it solves it in a way that’s readable and modular. I think the problem-solving part of coding requires math skills, whi

Good code doesn’t just solve a problem, it solves it in a way that’s readable and modular. I think the problem-solving part of coding requires math skills, while the organization part requires writing skills. The organization part affects the problem-solving part, because if you write messy code (that you can’t reread once you forget or extend without rewriting) you’ll quickly get overwhelmed. Writing large math proofs also requires organization skills, since you’ll refer to earlier sections of your proof and may have to modify it when you encounter issues. But to me, math seems to have more “big steps”: sudden insights that can’t be derived from writing (“how did you discover this?”), and concepts that are intrinsically complicated so one can’t really explain them no matter how well they can write. Whereas programming has more “small steps”: even someone who’s not smart (but has grit) can write an impressive program, if they write one component at a time and there aren’t too many components that rely on each other.

QuercusMax 2y ago
Most coding doesn't need much of any math past boolean logic and very basic set operations. I'm much more likely to spend my time studying DB and interface schemas to understand how something works than doing a lot of mathy fiddling. Sure, some people write game engines and such, but even much of 3D graphics doesn't need anything more complicated than the first half of a linear algebra course.
- ajuc 2y ago
  The difficulty is in how many relationships you need to keep in mind, not in how hard each of them are. Just like in math. BTW relational DBs are math.
  - RHSeeger 2y ago
    > BTW relational DBs are math. It's funny, reading the post you're replying to, I basically read it as > I don't need math, I need <math, but by another name> My teenage daughter used to complain about math, and I spent some time trying to explain to her that we use math every day... EVERY day. Now, when I see her do something that was math (even if it's not obvious it was math), I say "Math... every day". I say that a lot. Also, yes, my daughter finds me annoying. But also funny; but likely not for the math thing.
    - godelski 2y ago
      > I don't need math, I need <math, but by another name> This seems to be how it always goes. I think we've confused a lot of people by conflating math with arithmetic. https://news.ycombinator.com/item?id=43872687 https://news.ycombinator.com/item?id=43872687
  - GoblinSlayer 1y ago
    DBs aren't math. In math it's perfectly ok for computation to take infinite time, you can just assume it already completed, but DBs don't work like that.
- Someone1234 2y ago
  Now we're getting into the "define maths" part of the discussion which is always where these discussions die. It can be argued that turning a kettle on and boiling some water is "maths" or it can be as narrow as "everything above basic arithmetic is logic, not maths." So how much of programming is maths? Before we answer that, let's answer: How much of maths is actually maths? Because first we define maths, and then we define programming based on whatever that is, but until we have that first concrete definition this discussion cannot occur. I will add that "it is taught by the maths department in college" is a flimsy argument, and frankly one the Physics department in particular would mock.
  - delecti 2y ago
    I think for this discussion, "math is stuff you'd learn in a math department" is a pretty useful definition, even if it's not a very good one. There's a lot of math involved in the design and manufacture of the kettle, electrical grid, and water utilities, but a person's ability to put a kettle on isn't going to be improved by math classes. In that way, programming probably is a bit mathy, but good programming is more like good technical writing than it is like math.
    - Someone 1y ago
      > I think for this discussion, "math is stuff you'd learn in a math department" is a pretty useful definition That means that definition shifts over time. For example, courses on numerical analysis, graph algorithms, programming, and on compilers used to be part of “what you’d learn in a math department”. It likely also even today will show geographical variation.
  - GoblinSlayer 1y ago
    Overlap between programming and math is quite small, e.g. halting problem is solvable in programming (by flow analysis) but isn't solvable in math. Programming deals only with practical problems and can be completely guided by practical considerations, while math requires abstract outlandish skills - exact opposite. Why talk about math at all if it's already well known that programming is engineering?
- switchbak 2y ago
  It's definitely a gray area. Is a DAG traversal algo "math", or is it more computer-sciencey? What if you do it in SQL? Certainly there's a mix of more or less concentrated logic/math vs glue code, and most of that is very dependent on the domain you're working in. I find this distinction useful in the abstract, that one can engage different parts of the brain for different components of development. This probably explains why a well-written DSL can be so powerful in the right context.
  - tbrownaw 2y ago
    > Is a DAG traversal algo "math", or is it more computer-sciencey? Firstly, computer science is math. Secondly, I remember covering graphs in a discrete math course back when I was in college. > What if you do it in SQL? SQL is more-or-less a poor implementation of relational algebra. Ie, math.
    - vidarh 1y ago
      Computer science is math in the same way that physics is philosophy, in that computer science certainly started as math, just like the natural sciences used to be subdisciplines of philosophy. But it's hardly a useful grouping any more. You can study and do well in computer science with minimal knowledge of most of the core mathematical subjects. While graph theory certainly crosses over into math, you can cover most of the parts of it relevant to most computer science as a discussion of algorithms that would not be the natural way of dealing with them for most mathematicians.
      - voidspark 1y ago
        > You can study and do well in computer science with minimal knowledge of most of the core mathematical subjects. You will fail at Theoretical Computer Science without mathematical proficiency. Go read some textbooks and papers in theoretical CS. It is a subfield of mathematics. Theorems and proofs. Rigorous and difficult mathematics. https://en.wikipedia.org/wiki/Theoretical_computer_science https://en.wikipedia.org/wiki/Theoretical_computer_science
- godelski 2y ago
  > Most coding doesn't need much of any math past boolean logic and very basic set operations Coding IS math. Not "coding uses math", I mean it is math. Mathematicians do not deal in objects, but in relations among objects; they are free to replace some object by others so long as the relations remain unchanged. Content to them is irrelevant; they are interested in form only. - Poincare[0] I don't know how you code, but I don't think I'm aware of code that can't be reasonably explained as forming relationships between objects. The face we can trace a program seems to necessitate this. [0] https://philosophy.stackexchange.com/questions/22440/what-did-poincar%C3%A9-mean-when-he-said-mathematicians-do-not-deal-in-objects-but https://philosophy.stackexchange.com/questions/22440/what-di...
  - xmprt 2y ago
    By that same logic you could also say that language is math. In fact I think your quote kind of disproves your point because the content/state of a program is super important in coding more than the form. Coding used to be very close to pure math (many early computer science classes were taught in the Math Department in universities) but it has been so far abstracted from that to the point that it is its own thing and is as close to math as any other subject is.
    - godelski 2y ago
      > By that same logic you could also say that language is math Not quite, but the inverse is true. The language to math direction doesn't work because a lack of formalism. I can state incomprehensible sentences or words. (There's an advantage to that in some cases!) but when you do that with code you get errors and even you do it with math its just that there's no compiler or interpreter that tells at you
      - bryanrasmussen 2y ago
        >I can state incomprehensible sentences or words. since you can express paradoxes with match, perhaps not that different.
- hinkley 2y ago
  Boolean logic and set theory are very important to computer logic, and graph theory is not far behind. But you can also learn Boolean logic in the philosophy dept. Which I unfortunately learned the hard way by taking Philosophy 101 after already having the CS class on logic. Took a semester to go over what we did for the midterm. Got a lot of naps that semester.
- yubblegum 2y ago
  Probability is math and there you have caching, hashing, etc. Then there are permutations, combinations, etc. with a lot of usecases in software. Distributing graphs across nodes? More math.
  - NegativeLatency 2y ago
    State machines too
zahlman 2y ago
> Whereas programming has more “small steps”: even someone who’s not smart (but has grit) can write an impressive program, if they write one component at a time and there aren’t too many components that rely on each other. ... In my experience, learning to write one component at a time (and try the code, and make sure it works before proceeding) is itself a skill that many struggle to develop. Similarly for avoiding unnecessary dependencies between components. Oh, and also being able to analyze the problem and identify separable components. One of the most frustrating things about teaching programming, for me, is the constant insistence from other teachers that you have to maintain an "absolutely everyone can learn to program" attitude at all times. Many people who start to learn programming have misguided or confused reasons for doing so and - to say the least - could make much more effective use of their time developing other skills. (It's not a question of elitism; I'd surely flounder at some tasks that others find natural.)
- tetha 2y ago
  I dislike "everyone can learn to program" because it conflates many, many levels of skills and expertise. I very much think many people could learn the more advanced Excel Formulas, Power Automate and even simple Bash/PowerShell scripting to make their work more effective. I've met quite a few folks who had been intimidated out of trying who could do it. On the other hand, how many people on this site could bootstrap a linux kernel on either very new or very old hardware? I know there are some, but they are certainly not the majority. I certainly won't be the first person to get linux and doom to run on a quantum computer. But that is similar to other professions. Everyone with a largely functioning body can learn to turn a few planks and some metal parts into a functional shed door with some basic tools or to put up a decent brick wall that won't topple over in a month. That doesn't mean everyone is qualified to pour concrete for a dam or a bridge foundation, or to re-do some historical work in original style.
  - switchbak 2y ago
    > Everyone with a largely functioning body can learn to turn a few planks and some metal parts into a functional shed door It's shocking how little physical and spatial ability some people have - that is definitely not true. Sometimes it might be a personal discount or lack of confidence, but this remains true regardless of the cause.
ivape 2y ago
What do you mean by math? Abstractions or calculations? The effort it takes me to do long division in my head matches the effort it takes me to follow some obtuse spaghetti code. See, I can get good and fast at long division in my head, but I may never understand the fundamental theorem of calculus. Some people are really good at mucking around garbage code (they have no choice, they get paid to), but what part of programming did they get good at? Obviously, some part of it, but nothing to write home about. Whenever I sense that I'm just getting practice at doing the equivalent of mental long division at work, that's when I always seek a new job. No amount of money is worth falling behind like that.
- armchairhacker 2y ago
  I'm thinking of "computation", "intuition", and "organization". Computation is following an algorithm. e.g. long division or computing a derivative. Intuition, AKA brilliance, is finding a non-obvious solution. Think "solving an NP problem without brute force"*. e.g. solving an integral (in a form that hasn't already been memorized) or discovering an interesting proof. Organization is recording information in a way that a) is easy for you to recall later on (and get insights from) and b) is digestible by others**. e.g. explaining how to compute a derivative, solve an integral, or anything else. Math, programming, and writing each require all skills. The kind of math taught in school (e.g. long division) and your boring jobs are primarily computation. I believe advanced math (e.g. calculus) is primarily intuition; it requires some organization because big theories are broken into smaller steps, but seems to mostly involve smart people "banging their head against the wall" to solve problems that are still quite unclear***. Programming is primarily organization. It requires some intuition (I think this is why some people seemingly can't learn to code), but in contrast to math, most programs can be broken into many relatively-simple features. IMO implementing all the features and interactions between them without creating a buggy, verbose, and unmaintainable codebase is programming's real challenge. Writing is also primarily organization, but finding interesting ideas requires intuition, and worldbuilding requires computation (even in fiction, there must be some coherence or people won't like your work). > Some people are really good at mucking around garbage code (they have no choice, they get paid to), but what part of programming did they get good at? Obviously, some part of it, but nothing to write home about. I agree that work you find boring should be avoided, and I also try to avoid working with it. But some people really seem to like working on esoteric code, and I think there are some skills (beyond computation) developed from it, that even apply when working with good code. Building a mental model of a spaghetti codebase involves organization, and if the codebase uses "genius hacks", intuition. Moreover, the same techniques to discern that two code segments in completely different locations are tightly coupled, may also discern that two seemingly-separate ideas have some connection, leading to an "intuitive" discovery. There's an MIT lecture somewhere that describes how a smart student found interesting work in a factory, and I think ended up optimizing the factory; the lesson was that you can gain some amount of knowledge and growth from pretty much any experience, and sometimes there's a lot of opportunity where you'd least expect it. * Or maybe it is just brute force but people with this skill ("geniuses") do it very fast. ** These are kind of two separate skills but they're similar. Moreover, b) is more important because it's necessary for problems too large for one person to solve, and it implies a). *** And whatever method solves these problems doesn't seem to be simplification, because many theories and proofs were initially written down very obtuse, then simplified later.
hinkley 2y ago
The problem with doing things right the first time is some people look at it and just say, “well of course it should work that way.” Yes but did you think of doing it that way?
jauntywundrkind 2y ago
Its very rare imo that computational problems emerge fully formed & ready to be tackled like proofs. Usually even deciding what the problem is is in part an art, requires an act of narrativization, to shape and form concepts of origin, movement, and destination. A good problem solver has a very wide range of abstract ideas and concepts and concrete tools they can use to model and explain problem, solution, & destination. Sometimes raw computational intellect can arrive at stunningly good proposals, can see brilliant paths through. But more often, my gut tells me it's about having a breadth of exposure, to different techniques and tools, and being someone who can both see a vast number of ways to tackle a situation, and being able to see tradeoffs in approaches, being able to weight long and short term impacts.
- throwaway2037 2y ago
  > Its very rare imo that computational problems emerge fully formed & ready to be tackled like proofs. In my generation, the perfect example is Python's Timsort. It is an modest improvement upon prior sorting algorithms, but it has come to dominate. And, frankly, in terms of computer science history, it was discovered very late. The paper was written in 1993, but the first major, high-impact open source implementation was not written until 2003. Ref: https://en.wikipedia.org/wiki/Timsort https://en.wikipedia.org/wiki/Timsort It has been reimplemented in a wide variety of languages today. I look forward to the next iteration: WolfgangSort or FatimaSort or XiaomiSort or whatever.
  - jauntywundrkind 1y ago
    The a capital example of an exception that prove the rule. I absolutely value & have huge respect for the deeply computational works that advance us all along! But this is an exceedingly rare event. Most development is more glue work than advancing computional fundamentals. Very very very little of the industry is paid to work on honing data structures so generally.
owl_vision 2y ago
+1. Excellent description of how the skills relate. I often read, listen to poetry when stuck in a math or programming problem. ... or just talk to the rubber duck. :-)
leptons 2y ago
>Good code "Good code" is very subjective. Even readability and modularity can be taken too far.
walleeee 2y ago
Regarding mathematical > concepts that are intrinsically complicated, I'm not a mathematician, but I figure mathematicians aim for clean, composable abstractions the same way programmers do. Something complicated, not just complex in its interactions with other things, seems more useful as a bespoke tool (e.g. in a proof) than as a general purpose object? > Whereas programming has more “small steps”: even someone who’s not smart (but has grit) can write an impressive program, if they write one component at a time and there aren’t too many components that rely on each other. This is well put. I often wonder if a merely average working memory might be a benefit to (or at least may place a lower bound on the output quality of) a programmer tasked with writing maintainable code. You cannot possibly deliver working spaghetti if you can't recall what you wrote three minutes ago. This is a baldly self-serving hypothesis.
- MaxBarraclough 2y ago
  > You cannot possibly write or deliver spaghetti, working or otherwise, if you're not capable of remembering what you wrote three minutes ago. Forth programmers make a similar point. Forth is stack based; you typically use stack operations rather than local variables. This is ok when your 'words' (analogous to functions/procedures) have short and simple definitions, but code can quickly become unreadable if they don't. In this way, the language strongly nudges the programmer toward developing composable words with simple definitions. (Of course, Forth sees little use today, and it hasn't won over the masses with its approach, but the broader point stands.)
globnomulous 2y ago
> Good code doesn’t just solve a problem, it solves it in a way that’s readable and modular. Strongly disagree. There are plenty of cases where non-modular code is more readable and faster than modular code (littered, presumably, with invocations of modular logic). There are also countless cases, particularly in low-level languages or languages with manual memory management, where the best solution -- or the correct solution -- is far from readable. Readability is anyways in the eye of the beholder (My code is readable. Isn't yours?) and takes a back seat to formal requirements. Just as a matter of personal style, I prefer long, well-organized functions that are minimally modular. In my experience, context changes -- file boundaries, new function contexts, etc -- are the single greatest source of complexity and bugs, once one has shipped a piece of code and needs to maintain it or build on it. Modular code, by multiplying those, tends to obscure complexity and augment organizational problems by making them harder to reason about and fix. Longer functions certainty feel less readable initially but I'd wager they produce better, clearer mental models, leading to better solutions.
- quails8mydog 1y ago
  I think the important concept that "readable and modular" is trying to get at is how easy is it to continue working on the code in future. There's definitely codebases that are easier to work on than others, even when the domain is the same. I'd say that readability, which often boils down to consistency, and modularity are ways to do this, but they aren't the only ways. And as you say, sometimes there's a need for "unreadable" code, so not everything can be easy.
heisenbit 1y ago
Organization may also benefit from spacial skills.
sebastialonso 1y ago
A lot of people in this type of threads always makes the same mistake: confusing what math is with branches of math, or rather, ways in which math is used. The way the education system is built certainly contributes to this. I've always found the car metaphor to work very good to understand this: A car is a machine that can transport itself to point A to B (some other rules apply). There are different types of cars, but you certainly haven't understood the definition of you say that something is not a car because is not a Volvo, or because it doesn't look like a Ford, when it's clearly able to transport itself. Math is the study of ideal objects and the way they behave or are related to each others. We have many branches of mathematics because people have invented so many objects and rules to play with them. Programming is nothing if not this very definition. The fact that you don't have to "use math" when programming is not really addressing the point, it's like saying a car is not a car because it has no discernible brand.
- GoblinSlayer 1y ago
  Declarative construct is made of relations, but imperative execution isn't, rather it's a process in time, but time is not a thing in math.
  - sebastialonso 1y ago
    Another misconception I'd say. "Time is not a thing in math" is not understanding what math is. Time is another ideal object following certain rules under a given domain. Programming is coming up with objects of different size, with different characteristics, with interact at different points in time, i.e. following certain rules.

QuercusMax 2y ago

Most coding doesn't need much of any math past boolean logic and very basic set operations. I'm much more likely to spend my time studying DB and interface schemas to understand how something works than doing a lot of mathy fiddling. Sure, some people write game engines and such, but even much of 3D graphics doesn't need anything more complicated than the first half of a linear algebra course.

ajuc 2y ago
The difficulty is in how many relationships you need to keep in mind, not in how hard each of them are. Just like in math. BTW relational DBs are math.
- RHSeeger 2y ago
  > BTW relational DBs are math. It's funny, reading the post you're replying to, I basically read it as > I don't need math, I need <math, but by another name> My teenage daughter used to complain about math, and I spent some time trying to explain to her that we use math every day... EVERY day. Now, when I see her do something that was math (even if it's not obvious it was math), I say "Math... every day". I say that a lot. Also, yes, my daughter finds me annoying. But also funny; but likely not for the math thing.
  - godelski 2y ago
    > I don't need math, I need <math, but by another name> This seems to be how it always goes. I think we've confused a lot of people by conflating math with arithmetic. https://news.ycombinator.com/item?id=43872687 https://news.ycombinator.com/item?id=43872687
- GoblinSlayer 1y ago
  DBs aren't math. In math it's perfectly ok for computation to take infinite time, you can just assume it already completed, but DBs don't work like that.
Someone1234 2y ago
Now we're getting into the "define maths" part of the discussion which is always where these discussions die. It can be argued that turning a kettle on and boiling some water is "maths" or it can be as narrow as "everything above basic arithmetic is logic, not maths." So how much of programming is maths? Before we answer that, let's answer: How much of maths is actually maths? Because first we define maths, and then we define programming based on whatever that is, but until we have that first concrete definition this discussion cannot occur. I will add that "it is taught by the maths department in college" is a flimsy argument, and frankly one the Physics department in particular would mock.
- delecti 2y ago
  I think for this discussion, "math is stuff you'd learn in a math department" is a pretty useful definition, even if it's not a very good one. There's a lot of math involved in the design and manufacture of the kettle, electrical grid, and water utilities, but a person's ability to put a kettle on isn't going to be improved by math classes. In that way, programming probably is a bit mathy, but good programming is more like good technical writing than it is like math.
  - Someone 1y ago
    > I think for this discussion, "math is stuff you'd learn in a math department" is a pretty useful definition That means that definition shifts over time. For example, courses on numerical analysis, graph algorithms, programming, and on compilers used to be part of “what you’d learn in a math department”. It likely also even today will show geographical variation.
- GoblinSlayer 1y ago
  Overlap between programming and math is quite small, e.g. halting problem is solvable in programming (by flow analysis) but isn't solvable in math. Programming deals only with practical problems and can be completely guided by practical considerations, while math requires abstract outlandish skills - exact opposite. Why talk about math at all if it's already well known that programming is engineering?
switchbak 2y ago
It's definitely a gray area. Is a DAG traversal algo "math", or is it more computer-sciencey? What if you do it in SQL? Certainly there's a mix of more or less concentrated logic/math vs glue code, and most of that is very dependent on the domain you're working in. I find this distinction useful in the abstract, that one can engage different parts of the brain for different components of development. This probably explains why a well-written DSL can be so powerful in the right context.
- tbrownaw 2y ago
  > Is a DAG traversal algo "math", or is it more computer-sciencey? Firstly, computer science is math. Secondly, I remember covering graphs in a discrete math course back when I was in college. > What if you do it in SQL? SQL is more-or-less a poor implementation of relational algebra. Ie, math.
  - vidarh 1y ago
    Computer science is math in the same way that physics is philosophy, in that computer science certainly started as math, just like the natural sciences used to be subdisciplines of philosophy. But it's hardly a useful grouping any more. You can study and do well in computer science with minimal knowledge of most of the core mathematical subjects. While graph theory certainly crosses over into math, you can cover most of the parts of it relevant to most computer science as a discussion of algorithms that would not be the natural way of dealing with them for most mathematicians.
    - voidspark 1y ago
      > You can study and do well in computer science with minimal knowledge of most of the core mathematical subjects. You will fail at Theoretical Computer Science without mathematical proficiency. Go read some textbooks and papers in theoretical CS. It is a subfield of mathematics. Theorems and proofs. Rigorous and difficult mathematics. https://en.wikipedia.org/wiki/Theoretical_computer_science https://en.wikipedia.org/wiki/Theoretical_computer_science
godelski 2y ago
> Most coding doesn't need much of any math past boolean logic and very basic set operations Coding IS math. Not "coding uses math", I mean it is math. Mathematicians do not deal in objects, but in relations among objects; they are free to replace some object by others so long as the relations remain unchanged. Content to them is irrelevant; they are interested in form only. - Poincare[0] I don't know how you code, but I don't think I'm aware of code that can't be reasonably explained as forming relationships between objects. The face we can trace a program seems to necessitate this. [0] https://philosophy.stackexchange.com/questions/22440/what-did-poincar%C3%A9-mean-when-he-said-mathematicians-do-not-deal-in-objects-but https://philosophy.stackexchange.com/questions/22440/what-di...
- xmprt 2y ago
  By that same logic you could also say that language is math. In fact I think your quote kind of disproves your point because the content/state of a program is super important in coding more than the form. Coding used to be very close to pure math (many early computer science classes were taught in the Math Department in universities) but it has been so far abstracted from that to the point that it is its own thing and is as close to math as any other subject is.
  - godelski 2y ago
    > By that same logic you could also say that language is math Not quite, but the inverse is true. The language to math direction doesn't work because a lack of formalism. I can state incomprehensible sentences or words. (There's an advantage to that in some cases!) but when you do that with code you get errors and even you do it with math its just that there's no compiler or interpreter that tells at you
    - bryanrasmussen 2y ago
      >I can state incomprehensible sentences or words. since you can express paradoxes with match, perhaps not that different.
hinkley 2y ago
Boolean logic and set theory are very important to computer logic, and graph theory is not far behind. But you can also learn Boolean logic in the philosophy dept. Which I unfortunately learned the hard way by taking Philosophy 101 after already having the CS class on logic. Took a semester to go over what we did for the midterm. Got a lot of naps that semester.
yubblegum 2y ago
Probability is math and there you have caching, hashing, etc. Then there are permutations, combinations, etc. with a lot of usecases in software. Distributing graphs across nodes? More math.
- NegativeLatency 2y ago
  State machines too

zahlman 2y ago

> Whereas programming has more “small steps”: even someone who’s not smart (but has grit) can write an impressive program, if they write one component at a time and there aren’t too many components that rely on each other. ... In my experience, learning to write one component at a time (and try the code, and make sure it works before proceeding) is itself a skill that many struggle to develop. Similarly for avoiding unnecessary dependencies between components. Oh, and also being able to analyze the problem and identify separable components. One of the most frustrating things about teaching programming, for me, is the constant insistence from other teachers that you have to maintain an "absolutely everyone can learn to program" attitude at all times. Many people who start to learn programming have misguided or confused reasons for doing so and - to say the least - could make much more effective use of their time developing other skills. (It's not a question of elitism; I'd surely flounder at some tasks that others find natural.)

tetha 2y ago
I dislike "everyone can learn to program" because it conflates many, many levels of skills and expertise. I very much think many people could learn the more advanced Excel Formulas, Power Automate and even simple Bash/PowerShell scripting to make their work more effective. I've met quite a few folks who had been intimidated out of trying who could do it. On the other hand, how many people on this site could bootstrap a linux kernel on either very new or very old hardware? I know there are some, but they are certainly not the majority. I certainly won't be the first person to get linux and doom to run on a quantum computer. But that is similar to other professions. Everyone with a largely functioning body can learn to turn a few planks and some metal parts into a functional shed door with some basic tools or to put up a decent brick wall that won't topple over in a month. That doesn't mean everyone is qualified to pour concrete for a dam or a bridge foundation, or to re-do some historical work in original style.
- switchbak 2y ago
  > Everyone with a largely functioning body can learn to turn a few planks and some metal parts into a functional shed door It's shocking how little physical and spatial ability some people have - that is definitely not true. Sometimes it might be a personal discount or lack of confidence, but this remains true regardless of the cause.

ivape 2y ago

What do you mean by math? Abstractions or calculations? The effort it takes me to do long division in my head matches the effort it takes me to follow some obtuse spaghetti code. See, I can get good and fast at long division in my head, but I may never understand the fundamental theorem of calculus. Some people are really good at mucking around garbage code (they have no choice, they get paid to), but what part of programming did they get good at? Obviously, some part of it, but nothing to write home about. Whenever I sense that I'm just getting practice at doing the equivalent of mental long division at work, that's when I always seek a new job. No amount of money is worth falling behind like that.

armchairhacker 2y ago
I'm thinking of "computation", "intuition", and "organization". Computation is following an algorithm. e.g. long division or computing a derivative. Intuition, AKA brilliance, is finding a non-obvious solution. Think "solving an NP problem without brute force"*. e.g. solving an integral (in a form that hasn't already been memorized) or discovering an interesting proof. Organization is recording information in a way that a) is easy for you to recall later on (and get insights from) and b) is digestible by others**. e.g. explaining how to compute a derivative, solve an integral, or anything else. Math, programming, and writing each require all skills. The kind of math taught in school (e.g. long division) and your boring jobs are primarily computation. I believe advanced math (e.g. calculus) is primarily intuition; it requires some organization because big theories are broken into smaller steps, but seems to mostly involve smart people "banging their head against the wall" to solve problems that are still quite unclear***. Programming is primarily organization. It requires some intuition (I think this is why some people seemingly can't learn to code), but in contrast to math, most programs can be broken into many relatively-simple features. IMO implementing all the features and interactions between them without creating a buggy, verbose, and unmaintainable codebase is programming's real challenge. Writing is also primarily organization, but finding interesting ideas requires intuition, and worldbuilding requires computation (even in fiction, there must be some coherence or people won't like your work). > Some people are really good at mucking around garbage code (they have no choice, they get paid to), but what part of programming did they get good at? Obviously, some part of it, but nothing to write home about. I agree that work you find boring should be avoided, and I also try to avoid working with it. But some people really seem to like working on esoteric code, and I think there are some skills (beyond computation) developed from it, that even apply when working with good code. Building a mental model of a spaghetti codebase involves organization, and if the codebase uses "genius hacks", intuition. Moreover, the same techniques to discern that two code segments in completely different locations are tightly coupled, may also discern that two seemingly-separate ideas have some connection, leading to an "intuitive" discovery. There's an MIT lecture somewhere that describes how a smart student found interesting work in a factory, and I think ended up optimizing the factory; the lesson was that you can gain some amount of knowledge and growth from pretty much any experience, and sometimes there's a lot of opportunity where you'd least expect it. * Or maybe it is just brute force but people with this skill ("geniuses") do it very fast. ** These are kind of two separate skills but they're similar. Moreover, b) is more important because it's necessary for problems too large for one person to solve, and it implies a). *** And whatever method solves these problems doesn't seem to be simplification, because many theories and proofs were initially written down very obtuse, then simplified later.

hinkley 2y ago

The problem with doing things right the first time is some people look at it and just say, “well of course it should work that way.” Yes but did you think of doing it that way?

jauntywundrkind 2y ago

Its very rare imo that computational problems emerge fully formed & ready to be tackled like proofs. Usually even deciding what the problem is is in part an art, requires an act of narrativization, to shape and form concepts of origin, movement, and destination. A good problem solver has a very wide range of abstract ideas and concepts and concrete tools they can use to model and explain problem, solution, & destination. Sometimes raw computational intellect can arrive at stunningly good proposals, can see brilliant paths through. But more often, my gut tells me it's about having a breadth of exposure, to different techniques and tools, and being someone who can both see a vast number of ways to tackle a situation, and being able to see tradeoffs in approaches, being able to weight long and short term impacts.

throwaway2037 2y ago
> Its very rare imo that computational problems emerge fully formed & ready to be tackled like proofs. In my generation, the perfect example is Python's Timsort. It is an modest improvement upon prior sorting algorithms, but it has come to dominate. And, frankly, in terms of computer science history, it was discovered very late. The paper was written in 1993, but the first major, high-impact open source implementation was not written until 2003. Ref: https://en.wikipedia.org/wiki/Timsort https://en.wikipedia.org/wiki/Timsort It has been reimplemented in a wide variety of languages today. I look forward to the next iteration: WolfgangSort or FatimaSort or XiaomiSort or whatever.
- jauntywundrkind 1y ago
  The a capital example of an exception that prove the rule. I absolutely value & have huge respect for the deeply computational works that advance us all along! But this is an exceedingly rare event. Most development is more glue work than advancing computional fundamentals. Very very very little of the industry is paid to work on honing data structures so generally.

owl_vision 2y ago

+1. Excellent description of how the skills relate. I often read, listen to poetry when stuck in a math or programming problem. ... or just talk to the rubber duck. :-)

leptons 2y ago

>Good code "Good code" is very subjective. Even readability and modularity can be taken too far.

walleeee 2y ago

Regarding mathematical > concepts that are intrinsically complicated, I'm not a mathematician, but I figure mathematicians aim for clean, composable abstractions the same way programmers do. Something complicated, not just complex in its interactions with other things, seems more useful as a bespoke tool (e.g. in a proof) than as a general purpose object? > Whereas programming has more “small steps”: even someone who’s not smart (but has grit) can write an impressive program, if they write one component at a time and there aren’t too many components that rely on each other. This is well put. I often wonder if a merely average working memory might be a benefit to (or at least may place a lower bound on the output quality of) a programmer tasked with writing maintainable code. You cannot possibly deliver working spaghetti if you can't recall what you wrote three minutes ago. This is a baldly self-serving hypothesis.

MaxBarraclough 2y ago
> You cannot possibly write or deliver spaghetti, working or otherwise, if you're not capable of remembering what you wrote three minutes ago. Forth programmers make a similar point. Forth is stack based; you typically use stack operations rather than local variables. This is ok when your 'words' (analogous to functions/procedures) have short and simple definitions, but code can quickly become unreadable if they don't. In this way, the language strongly nudges the programmer toward developing composable words with simple definitions. (Of course, Forth sees little use today, and it hasn't won over the masses with its approach, but the broader point stands.)

globnomulous 2y ago

> Good code doesn’t just solve a problem, it solves it in a way that’s readable and modular. Strongly disagree. There are plenty of cases where non-modular code is more readable and faster than modular code (littered, presumably, with invocations of modular logic). There are also countless cases, particularly in low-level languages or languages with manual memory management, where the best solution -- or the correct solution -- is far from readable. Readability is anyways in the eye of the beholder (My code is readable. Isn't yours?) and takes a back seat to formal requirements. Just as a matter of personal style, I prefer long, well-organized functions that are minimally modular. In my experience, context changes -- file boundaries, new function contexts, etc -- are the single greatest source of complexity and bugs, once one has shipped a piece of code and needs to maintain it or build on it. Modular code, by multiplying those, tends to obscure complexity and augment organizational problems by making them harder to reason about and fix. Longer functions certainty feel less readable initially but I'd wager they produce better, clearer mental models, leading to better solutions.

quails8mydog 1y ago
I think the important concept that "readable and modular" is trying to get at is how easy is it to continue working on the code in future. There's definitely codebases that are easier to work on than others, even when the domain is the same. I'd say that readability, which often boils down to consistency, and modularity are ways to do this, but they aren't the only ways. And as you say, sometimes there's a need for "unreadable" code, so not everything can be easy.

heisenbit 1y ago

Organization may also benefit from spacial skills.

sebastialonso 1y ago

A lot of people in this type of threads always makes the same mistake: confusing what math is with branches of math, or rather, ways in which math is used. The way the education system is built certainly contributes to this. I've always found the car metaphor to work very good to understand this: A car is a machine that can transport itself to point A to B (some other rules apply). There are different types of cars, but you certainly haven't understood the definition of you say that something is not a car because is not a Volvo, or because it doesn't look like a Ford, when it's clearly able to transport itself. Math is the study of ideal objects and the way they behave or are related to each others. We have many branches of mathematics because people have invented so many objects and rules to play with them. Programming is nothing if not this very definition. The fact that you don't have to "use math" when programming is not really addressing the point, it's like saying a car is not a car because it has no discernible brand.

GoblinSlayer 1y ago
Declarative construct is made of relations, but imperative execution isn't, rather it's a process in time, but time is not a thing in math.
- sebastialonso 1y ago
  Another misconception I'd say. "Time is not a thing in math" is not understanding what math is. Time is another ideal object following certain rules under a given domain. Programming is coming up with objects of different size, with different characteristics, with interact at different points in time, i.e. following certain rules.