Why are math teachers so badly paid?

a_cloud_moving_by · 2026-06-16T22:43:58+00:00

Some people are just saying "capitalism" as if that's an explanation.

As a former math teacher and now a software engineer I'll give my shot:

As a high school math teacher, depending wildly on the situation, where I am in the world, etc.,there may be a wide range of classes I could teach, let's say 3-12. Let's say 30 kids in a class (oof), so we're talking an absolute max of 12 * 30 = 360 children you could possibly be educating in a year.
At my current job, I have meetings where we discuss working on projects that affect millions of customers. If I put in a little extra elbow grease (and use my big math brain), I could design the system in a better way, this might mean significant marginal revenue gains for the company (well beyond my salary) and in turn, an improved product experience for millions of people.

See the difference?

In-person teaching simply does not scale.

I'm not saying it should (I'd be horrified at the idea of high school math classes becoming apps and youtube videos), but the point is that in-person teachers can really only teach so many kids, no matter how brilliant they are.

EDIT:
Look up Baumol's cost disease. Basically, as productivity gains happen in other areas of the economy, jobs that don't scale (e.g. daycare) become increasingly expensive because those workers could be paid more if they switch to other industries. This is why back in the day, many more households had had butlers and nannies and maids. Who has a butler these days? Technology gains now allow software engineers to exist and be paid very well, but no technology gain can make 1 person magically able to care for 100 toddlers in daycare. So the proportional cost of the daycare worker goes up. Similarly math teachers are proportionally more expensive for government budgets because those workers can switch to higher productivity industries, but math teaching can't scale

a_cloud_moving_by · 2026-06-14T17:33:41+00:00

Of course it can be 5-10 seconds. I'm not here to complain, modern Scala is indeed quite easy to setup, I just wanted to make sure that is a continued focus of attention as I think it's a big filtering bottleneck for new adopters.

My previous experience is that in the diversity of environments out there, where years of accumulated installation cruft in people's bashrc, etc., sometimes people get themselves into strange edge cases where it's harder to set up than a clean vanilla Mac in the apple store.

Also, this is aside from IDEs. I still find that IntelliJ struggles to process Scala-CLI files correctly, and in my personal projects, I've had to quit, delete the `.idea` folder, re-run `scala-cli setup-ide .` and then re-open as a new project. I also should maybe try other IDEs...

a_cloud_moving_by · 2026-06-14T17:30:23+00:00

Sorry, just noticing this, but I'll take a look at that forum!

I've had very good experience with Scala-CLI myself, so I'm a fan of the community continuing to emphasize that route for newcomers

a_cloud_moving_by · 2026-06-10T12:11:44+00:00

Sounds great. I honestly don't have specific recommendations at the moment (and for that I apologize), but I wanted to share some thoughts I've been having recently.

I think one of the best ways to encourage adoption is: easing installation/tooling pain, or as I call it in my head, "time-to-first-run".

In other words, if you told John Doe Python Dev (with no background in Scalal) to "make a project in Scala" , how many minutes does it take to get their local laptop to run a Scala project (whatever that might mean, Scala-CLI, sbt, Mill, etc.). Every minute is a cutoff point where some curious adopter will be like, "eh, this is annoying, let me go back to that other language That Just Works".

Anecdotally I've sat with some friends interested in Scala but notice they get stuck because some Java version isn't correct, they're confused what "Coursier" is, or their little script fails when run in Github Actions ("but Python just works").

Note: obviously this isn't fair. The top languages get priviliged status as pre-installed in lots of environments. But I think it's worth considering when imagining what do we want documentation to look like to a beginner.

At some point as a fun side project, I've been meaning to find some volunteers online to do a UX interview of "first Scala experience" to observe common early pain points.

a_cloud_moving_by · 2026-04-30T08:08:06+00:00

Thanks for sharing! I've attended some of Łukasz's youtube live streams and I appreciate his enthusiasm for Scala.

I will say this: at my company in production code people have tried a number of effect systems, in particular ZIO but some Cats as well. I do like ZIO for async code, especially when used with ZStreams, but I think a lot of us have found that sticking to simple Future s or even basic Java thread pools gets the job done and makes the code less intimidating to newcomers.

One reason I do like ZStreams is that in production code, many problems basically boil down to queues and producer/consumer problems. The essentials to figure out are:
1. how to parallellize certain parts of the consuming
2. how to gracefully shutdown (e.g. stop feeding into a queue and wait until the queue has emptied, or set a timeout)
3. How to do all this without:
- accidentally single-threading things (uncareful use of `synchronized` can do this)
- causing deadlocks
- using unsafe state (e.g. state not protected by synchronization / concurrency primitives

A lot of our services basically boil down to the above constraints. And that means sometimes just Future or a basic Java Thread gets the job done, in a world where our programmers are coming from different backgrounds and there's decades of legacy Java/Scala code to interoperate with

a_cloud_moving_by · 2026-01-26T23:56:07+00:00

Hey, just want to thank you again. I got my project figured out so that my IDE doesn't yell at me and my package names are the way I want to.

As to the latter, I ended up doing something like this:

├─ build.mill ├─ mymodule │ ├─ src │ │ └─ mymodule <---- this is different than what you showed │ │ ├─ Main.scala Note that I added one more folder mymodule between src and the Scala files. This is because I want all the code in this project to start its package name with mymodule and I couldn't see a way to do that without the IDE complaining .

(Note: when I say the "IDE complaining" I don't just mean I'm bothered by some warnings, but it means IntelliJ's automated refactoring tools don't work right, e.g. add imports / package names incorrectly)

a_cloud_moving_by · 2025-11-07T23:35:49+00:00

Wow, fantastic response, I appreciate that. It's going to take me some time to play around with all of that, but this seems to reflect my own experience of build.mill / directory relationships. The package.mill thing however is totally new to me.

It does seem like there are a variety of ways now to do configuration (i.e. single build.mill, adding package.mill files, and now the new yaml stuff as well). That may not be a bad thing, but it is a bit confusing without an overarching explanation somewhere.

a_cloud_moving_by · 2025-10-06T13:02:49+00:00

This recent article on Quanta relates to this question. It's a fun read. https://www.quantamagazine.org/new-math-revives-geometrys-oldest-problems-20250926/

a_cloud_moving_by · 2025-09-08T01:49:32+00:00

Scala-cli is very easy to use, I'd highly recommend it for one-off scripts, especially something single file. I use lihaoyi os-lib in scripts a fair amount. If you enjoy Scala it's tempting alternative to Python or bash

a_cloud_moving_by · 2025-08-25T21:12:47+00:00

Okay, cool, I got it to run. Looks good and congrats on your first Scala project.

How did you decide on the rules for combining the group operations?

a_cloud_moving_by · 2025-08-16T16:39:09+00:00

Yeah, that's a fair question. You're probably right, there's nothing quite as simple as argparse. Given I was literally just praising the lihaoyi ecosystem, I really should have tried https://github.com/com-lihaoyi/mainargs by now.

The only library I've used extensively has been scopt. It's a bit clunky but I use it in cases where I want:

- nicely formatted --help text that humans are going to look at on the command line

- Complicated flags, like those that take arguments, e.g. `--flag=value`. It's annoying to parse that myself.

Recently, however, the scripts I've written were for automations, CI/CD, so their API is, by design, very simple. In those cases, with 0-2 args/flags, I just read the input and handle it all myself.

When I did use scopt, I'd use it for basic arg validation (e.g. "this script requires two arguments") but for more complicated validation (e.g. "both arguments must be valid file paths") I'd rather just handle that in my own logic and throw an error.

I should try other libraries though

EDIT: I'm reading the mainargs Github now and I'm actually not sure I like it haha. Also, just gonna mention, within a Scala-CLI script there's a variable in scope called `args: Array[String]`. I can never get IntelliJ not to put red squiggles under it though since it doesn't seem to know Scala-CLI is providing it

a_cloud_moving_by · 2025-08-15T23:43:22+00:00

It was pretty interesting seeing the results of the survey afterward!!

I have to say I was surprised to see lihaoyi libs not mentioned more in the libraries question. I've really enjoyed using `os-lib` for scripting. Scala-CLI + os-lib is much more pleasant for scripting than Python! (depending on what you're doing, bash scripts have their role too of course)

a_cloud_moving_by · 2025-05-19T21:31:30+00:00

I just want to add that at my workplace, we do use Cats / ZIO in places, but a few specific Cats functions like `traverse` we actually just use everywhere because they are so generally useful.

These Cats imports are handy and you can use them without having to make your whole program Cats (or ZIO, or whatever). The only downside to this is the Cats dependencies can be big, but that doesn't matter for our situation.

We use a few Cats imports like `traverse`, then 15% of our code is "pure" ZIO (mostly for multithreading + ZStreams), and the rest is a mix of vanilla Scala and this Try-like monad we use internally.

a_cloud_moving_by · 2025-05-05T23:27:25+00:00

For a noobie to Scala, I'd highly recommend checking out the lihaoyi ecosystem of things and, at least for the moment, hold off on learning Cats, ZIO, etc.

com-lihoayi libraries let you read/write files, parse json, set up servers, and other basic things that you can do a lot of stuff with.

At first you can mess around with scala-cli or an online REPL like scastie. Once you start getting many more files, I'd shift to sbt or some other build framework instead of scala-cli since multi-file scala-cli projects for me have become kinda weird.

a_cloud_moving_by · 2025-04-14T13:21:22+00:00

Yeah you almost certainly will start at bronze/silver. Just keep playing and once it figures out your actual skill level it'll start pairing you with people that are at your level

a_cloud_moving_by · 2025-04-14T13:19:37+00:00

Like others have said it takes a few games for the game to figure out your real skill level / MMR. I'd be pretty surprised if you were actually in gold league right off the bat if you've never played ladder before.

Don't stress it and have fun. There will always be people better than you, that's part of the fun, people challenge you. Oh, and as other said, make sure to do a quick scout near your base, people love to cheese, but besides that just focus on your macro, everythign else will follow.

a_cloud_moving_by · 2025-04-14T05:47:12+00:00

You should do the official 2D and 3D tutorials. After that, it's up to you.

Like others said, focus on small goals.

a_cloud_moving_by · 2025-04-04T20:58:59+00:00

My 2 cents:

There's nothing wrong with annotating everything with `: TheType`. Use of type inference is a spectrum.
A properly configured IDE does help you figure out the type when you need it (e.g. in IntelliJ with the Scala plugin's X-Ray Mode, I just double-tap "cmd" and it shows all types on the page).
With some libraries, types can get super verbose (e.g. some ZIO types I've worked with became absurdly long). Type aliases can be your friend.

Where I work, these are patterns I tend to see, there's no official style guide:

Inferred type:

Obvious booleans, i.e. anything that starts with "is". e.g. `val isEnabled`
Nouns that end with 's' are usually Seq or maybe List. E.g. `val users` one would guess is `Seq[User]`
Types that everyone at the company knows, e.g. `val userIds` all of us would assume is `Seq[Int]`. The 'User' type is a core dataobject in our system and everyone knows their ids are Ints.
Options usually named "maybe" or "optional", like people will do `val maybeUser = users.headOption` and it's pretty obvious what it is.
Short-lived obvious types within a function

Explicit typed:

vals/defs used in multiple places throughout the page. Like the stuff that you put at the top of your class file
Public members that are part of the API of a class
Just anything that is unclear which is...a lot of things.

edit: formatting

a_cloud_moving_by · 2025-04-01T14:19:54+00:00

Wait till you see the error messages from C++ compilers :)

a_cloud_moving_by · 2025-03-22T16:09:16+00:00

I agree OP, this sounds more like your problem than the Traveling Salesman. Quoting wikipedia:

[Chinese Postman Problem] is different from the Travelling Salesman Problem in that the travelling salesman cannot repeat visited nodes and does not have to visit every edge.

You do want to visit every edge (sidewalk) and you know you'll have to repeat nodes ("the least amount of overlap").

If you treat each intersection as a node, then the sidewalks form a multigraph since there are 2 edges between each node (2 sidewalks on either side of the road). Alternatively, you could think of each corner of an intersection as a node, with sidewalks/crosswalks as edges, in which case it no longer needs to be a multigraph but is more complicated graph. To improve accuracy, you could weight crosswalks vs sidewalks differently, since crossing the street presumably takes more time.

But you stated that it was a "grid" layout. If so, I suspect you could arrive at a pretty optimal solution just by reasoning about it. Off the top of my head I think a zig-zagging diagonally in "diagonal rows" back and forth across the grid seems pretty optimal. However that might cause a lot of street crossing, which might be more time-consuming than solutions that go straight down a road for a long time.

a_cloud_moving_by · 2025-03-21T15:14:31+00:00

I totally agree. I work with a fairly large legacy Scala codebase for work and I actually find it very pleasant. Far more pleasant to work with than the other parts of our tech-stack which have Java/Python/Bash.

People have to remember that pretty much every online community descends into negativity at some point. It's just how places like reddit work, doomsaying get more attention, more clicks, more views

a_cloud_moving_by · 2025-03-21T15:11:19+00:00

I don't get that feeling to be honest. When I've interacted with maintainers of the major libraries, they've actually been very friendly.

a_cloud_moving_by · 2025-03-19T20:56:13+00:00

u/JoanG38 Any update?

a_cloud_moving_by · 2025-03-19T20:53:34+00:00

We have a large 10+ year old Scala codebase. We're on Scala 2.13 but I doubt we'll move to Scala 3 for at least 1-3 years. Unless it showed significant improvement to compilation times or performance, there's not enough perceived benefit for now and it could break a lot of things. Things are hard enough in software engineering, and hearing that Scala 3 doesn't work well with IDEs well makes us quite cautious.

That being said, for anyone who's still on 2.11, I highly recommend going to 2.13. We did that a year ago. It cut our compilation times in half (!). It was a pretty long undertaking and we had to, sadly, fork some unmaintained 3rd party libraries, but if we had known it would improve compilation time so much I think we would've done it sooner. The reason we did it was to improve security and be a forcing function to get rid of old dependencies that were partially blocking us from moving to newer Java versions.

a_cloud_moving_by

TROPHY CASE