Hacker News Reader

Comment by paxys | Hacker News Reader

This is exactly why so many people (myself included) advocate for a pure "software engineering" degree at more universities. Let people who are interested study graph theory, combinatorics, linear algebra, advanced probability and statistics and whatever else. For the rest, provide a path to be ready for an industry job building websites and applications, which is what 90% of graduates will end up doing.

Every other discipline out there has a clear separation of pure from applied science. Why can't we do the same for software? What we end up with is borderline fraudulent coding bootcamps to fill in the gap.

View on HN

While I spend 99% of my time doing pure "software engineering", I'm pretty grateful to have the advanced probability / graph theory / combinatorics etc. background because it helps me envision possibilities I wouldn't otherwise be able to.

That being said, there are probably lighter ways of teaching that instinct than full-depth classes. I try to listen to podcasts these days as a way of expanding my horizons.

Any recommendations for good podcasts in that vein?

I have been saying for years that we need to treat software developers like jedi when it comes to training.

Practical, industry expert-led coursework has been by far the most outstanding education I have ever received. My DSP professor was (is still) an adjunct to the university I attended and works a normal job 9-5 during the day at some engineering firm. He was easily the best educator I have ever experienced because he brought reality into the classroom every day. I still vividly recall the 20–30-minute lecture/rant about making power point presentations that don't suck.

It's all the little things for me... The nuanced details like "why are you holding it that way?" are impossible to discover until you have a customer complaining at you for a while or have someone who experienced it themselves giving you a heads-up.

For me, the future of practical software engineering education looks a lot more like a machine shop than it does a university campus.

I think this line of thinking fails to recognize what a general math background does for your critical thinking skills.

I'm sure you and I both took plenty of math classes, and therefore we won't ever really know what our computer science skills would be like without a rigorous math background. Even if I never touch anything more complex than algebra II again, taking ~30 credits of applied math allows me to think in a way that I wouldn't otherwise without that background.

Software engineering is based on applied mathematics too. You'll need at least some basic calculus to make sense of O(n) analysis, and Calc II as a prereq for probability. Then add plenty of logic, discrete mathematics (needed for algorithms and data structures), models of computation and concurrency, category theory (which is becoming a shared language of everything "compositional"), topology etc. etc.

If you really want a "math free" intro to tech, look into Business Information Systems. That tends to be more ad hoc, at least for now. At some point, people will start to care about software assurance even in that context, and the standards will rise accordingly.

Not to mention relational calculus for a deeper understanding of databases.

The relational calculus has very little to do with the calculus of infinitesimals.

You don’t. I’ve never been asked a O() that requires calculus. The vast majority is just understanding if it’s log(n), n, nlog(n), n^2, etc.

Discrete, sure, but Calc? Not for most.

You don't really need to know calculus (derivatives and such) but it's true that big O notation requires some sort of "asymptotic thinking" which is probably only explicitly taught in a calculus course.

That’s part of Pre-Calculus or general mathematics coursework at most US high schools.

Beyond that it’s a very simple idea you can cover at the same time as your doing Big O notation in the first place.

Discrete probability is probably adequate for most software engineering. Almost everything we encounter in our jobs is discrete. One thing I do think we need more of is linear algebra.

The thing is people with a maths heavy background tend to think you need a much deeper understanding of math for this than you actually do.

You need very little beyond high school level math for most CS. Some areas, sure.

I've done things in my career that touches on a lot of different areas of math. But the number of times I've regretted not having taken more math have been pretty much non-existent. I wish I remembered a bit more of my trig, mostly.

Most software engineers come into contact with far less CS subjects where math matters than I do.

I don't have an issue with a place like MIT insisting on lots of math, but this notion that you need to understand so much math for software engineering is deeply flawed - you don't need much even for a lot of theoretical computer science.

The point is that even a "shallow" understanding of math is much deeper already than many, perhaps most realize. Many high-schools don't seriously try to teach math at all - there's no such thing as "high school math" in this day and age. You need college to even have a chance of being exposed to it properly.

(Then there's the whole "learning to code" part, of course. This is actually where middle and high school math provides useful application domains for learning to code, and people have tried to teach coding in schools since the 1980s.)

I don't really think you need much math to learn to code at all. Again, some forms of code is helped by math, but I've also seen beginners struggle to reconcile differences between whatever programming language they were introduced to an mathematical notations. There's no doubt there are close relationships between math and CS, but you can a lot of CS just fine without ever being aware of those relationships.

I opted out of pretty much all the math I could at university, and at mine you could opt out of almost all of it (I had to take one introductory course which mostly served to bring those who hadn't taken much in high school up to scratch, and one introductory stats course).

Many of my other courses touches on subjects where a mathematician probably would say "but that's math". E.g. my compiler courses of course touched on a lot on parsers and grammars that are effectively just math restated. But those restatements matter. Maybe if more math was taught in ways that downplayed the dense notations more people would actually stick with it.

Code is pretty much defined by having "dense notation". Learning to code involves plenty of familiarity with formal, logical reasoning; simple math helps provide a convenient domain for applying logical reasoning to meaningful problems.

Code is nowhere near as dense as it can be in most languages - we make considerations for human readers by making languages verbose on purpose to a much greater extent than most math (of course there are exceptions like e.g. J and K and similar languages). Most math violates the intent of pretty much every coding standard there is in focusing overly on density over readability to someone not intimately familiar. On top of that, math very often omit a lot of detail in a way code can't, that requires a lot more effort from the reader. I get that it's intentional - the focus is on expressing what is different in terms of a shared context people familiar with the math already has, while in code only a few fringe languages tends to take this approach over favouring readability.

And yes, we need familiarity with formal, logical reasoning, but the primitives you need to be able to understand coding are really basic, and often easiest introduced by showing people code rather than giving it the mathematical treatment.

It's not necessarily math itself that is the issue, but mathematical notation and the way we teach it - there's a very stark divide, I've observed, between those who prefer those really terse notations that you must take time to decipher, and those who want notations that can be read like prose. For my part I'm firmly in the latter camp.

> but the primitives you need to be able to understand coding are really basic, and often easiest introduced by showing people code rather than giving it the mathematical treatment.

The primitives are hopefully simple, but the logical implications are not. That's why it makes sense to have both.

For a subset of CS that most developers will never need, sure. Nobody is arguing math is never needed for CS, but most developers, and indeed a whole lot of CS researchers will never need much of it.

If all you're interested in is getting a good job, you don't need a degree at all. The information is available for free in a variety of presentations and formats. The source code to just about all the software you'll use is available for free as are all the tools. You don't even need a bootcamp, just time and energy.

You may not need a degree to learn the material, but as someone new to the field, there are plenty of jobs that list a 2 year or 4 year degree as a requirement. Having that degree will open more doors than just learning on your own simply because that’s what they’re looking for.

Sure, but in the same vein everything you will ever learn at MIT can be found for free online as well. Ultimately a 4-year degree does have value, whether just for the brand, or as a forcing function to learn, or the constant help from teachers and peers or whatever else.

I don't think a "pure" software engineering degree really needs to be four years.

What you're talking about sounds an awful lot like the program I went into initially at a community college. They taught you some coding in a few popular languages, some database concepts and sent you on your way. I dropped out after a year and found a job.

I ended up going to a four year program after a while. Turns out, a lot of the good jobs in software engineering require understanding those peaky abstract fundamentals.

Reply on news.ycombinator.com