Ask HN: Do pure math grads make better software engineers than CS grads?
What has been your experience in this regard?
With that said this question really has no answer, some math grads are better, some CS grads are better and some beauty school dropouts are better.. as with anything that requires learning and applying a skill those who work harder or are blessed with a talent in the subject tend to be more successful.
Of course there are better math major programmers than CS major programmers, just as there are better CS programmers than math major programmers. It goes without saying that asking a question which has multiple truths as answers is equivalent to asking a question with no answer. It would then beg to ask the question, "Why are you asking questions with no answer?".
My advice is to ask a better question next time!
I prefer farm mechanics and philosophers to cs grad when it comes to software.
I have met many programmers. I have met many new grads. Of the new grads that I have met who learned programming at school, I don't think I have ever met one that was a good programmer right out of the gate. Certainly many can code and make things work. None of them are good enough for me to look at their code and have it influence me in a positive way.
That's not to say that I haven't met good, young programmers. It's just that all of the ones I've met had been programming regularly for 10 years or so before they went to university... Some of them didn't go to university at all.
I should say as well that I have never met a really good programmer that has less than about 10 years of coding experience, either. I've met lots and lots and lots of people with less experience who thought they were great programmers, but that's different, isn't it?
So, from my perspective the answer to the question is "No". Working with great people and devoting yourself to improving makes better software engineers than either doing a math or CS degree in university.
And a lot of 25-year old professionals with 4 years of experience in the software industry wonder what they were thinking at 21, now that they know how you really build software.
And a lot of 30+ year-old professionals wonder how a 25-year-old who had so little experience after working on just one or two different projects for only a couple of years each could possibly have believed they were such an expert.
I wonder what 50-year-old me will one day think of 30-year-old me. I have concluded that I will probably think I was ignorant and naïve back then, and that this feeling that everything you did a long time ago was terrible is called being alive. :-)
I don't look back at 30yo me with disdain. I do find all of normal programmming pretty mundane and cookie cutter. Design this way or that way, pick your trade offs, investigate gotchas, think about what this code will be like in 10 years (most stuff I write has a long life, I don't do web stuff), trade off robust design with get it out the door, and so on. No biggie.
I get my challenges now with new domains - computer vision, computation, math, etc - stuff that requires reading research papers. It's fun. There is always a universe of things you won't know, you just need the humility to understand that, and I think by 30 or so most of us figure that out. If you don't you are pretty bull headed, as the compiler will tell you 1,000 times a day that you don't really know something if you don't. Most people get the clue after awhile ;)
Facebook is 11 years old now; Google is 17, and I'd bet there's a line of code somewhere in both of them somewhere there that hasn't been touched in 10 years.
> I don't do web stuff)
Feel free to pigeonhole yourself like that, but I've learned not to overlook large swaths of industry because it's not 'serious'.
Reading research papers? Both Google and Facebook have been writing research papers in many areas, including Computer Vision. As you point out, you need humility to take the time to understand what's come before you, but you also need the hubris to say "we can do better". In the case of FaceNet (Google) or DeepFace (Facebook), much better than state of the art a few years ago.
He never said that web programming wasn't serious. He just said he doesn't do work in that area. I'm sure there are lots of areas of computing that the average web programmer "doesn't do" either, like kernel hacking or embedded systems or computer vision.
"Reading research papers? Both Google and Facebook have been writing research papers in many areas, including Computer Vision."
I'm not sure what your point is. Reading research papers is how you learn what's the state of the art in any field of research (ask any PhD student). If computer vision is a new domain for him, he has to begin by reading, not writing. Even the people who write research papers read many more papers than they write.
At around 30 I started to clue in and I can recall some designs which were actually not too bad in retrospect. Of course, a lot of the stuff that is taken for granted now (design patterns, TDD, etc) was not well known at that time and so I was exploring and learning things that few other people had experience with.
As another person posted, I'm also nearing 50. I would say that my code has improved a fair amount and I have learned a lot of other techniques which I didn't really know in my 30s (like FP). Rather than technique, though, I think the biggest thing I've learned is patience. I code very slowly compared to how I coded 20 years ago, but I think a lot more about every line. Kent Beck once said that when he wrote Smalltalk Best Practices that he started to evaluate every keystroke and to think why he was pressing that key. I find that I am doing that a lot now and it is very beneficial. The advice I give the young guys on the team the most is, "Stop typing so fast! You need to think about what you are typing" :-)
As I said, the biggest revelations for me are less about pure technique and more about how everything fits together. For example, my less experienced colleagues are often distraught over the perceived sins of the other people on the team. They worry endlessly about how to stop the "crappy programmers" (in their eyes) from "ruining" the code base. Nearly 50 year old me weighs the options and realizes that complaining/campaigning/scheming/negotiating/etc will take an order of magnitude more time than refactoring and will suck the fun out of the room. I like refactoring code and I hate arguing, and besides young people tend to be crap at cleaning (in general). So I clean things and eventually most of the others catch on -- not everybody, but it's enough.
I still get stressed out a lot and I'm hoping by the time I hit 60 I will have resolved those issues :-)
Pure math people are significantly worse devs in their first jobs. Significantly. Why? They just don't have the language or training so you can't really give direction that assumes anything. And interns are raw enough anyway, this lack of shared language hurts.
My experience is based off of interns though. I'm sure given 2-5 years, it will depend on the person/continuous learning, blah blah rather than what courses they took in college.
Now, another aspect of the question seems to be: are pure math grads smarter than cs grads?
Nope again. Put a pure math and CS guy in the room together and I'm sure either could flummox the other with arcane jargon/an exercise. We choose what to do in college based on our interests at that time rather than only basic ability. I have CS, Stats, and Math degrees from college and I didn't notice any difference in raw mental horse power or work ethic or work load amongst those 3 majors.
Aside: there was a marked difference in work load when comparing my engineering/math/stat classes and my econ minor classes though: weekly assignments for econ took 30 mins before class whereas cs/math assignments easily took a whole day or two of the week each.
Aside2: And no, you can't generally say philosophy or physics grads make better software devs too.
The maths background was helpful for developing logical reasoning, rigorous arguments, and working with abstractions.
Studying CS exposed me to a wider range of computing ideas than I’d encountered before, from formal models underlying relational databases to functional and logic programming. It also provided some basic but useful general knowledge about things like data structures, algorithms and complexity along the way.
I’m glad I studied both areas during my academic career, but for me neither is “better” than the other for someone starting out in the software industry. They just prioritise different skills and mindsets and provide different background knowledge, so each gives a different kind of head start.
I wouldn’t say either course taught me anything of great value about software engineering specifically, if we’re talking about the processes and tools used to actually design and build production software here. I think SE is more of a vocational/industrial field, and I wouldn’t necessarily expect a new grad in either math or CS to have much experience in, or even awareness of, the kinds of issues that come up in practice.
[1] Very roughly speaking, the diploma course was a one-year conversion course for people with a technical but not CS background, which included the same kinds of topics you’d study in the first couple of years of an undergraduate CS course. Sadly, I don’t know of anywhere that offers a similar course any more.
Most people who go into software without a CS degree learn the practical side of things quite well out of necessity. I expect math majors are more likely than most to pick up the theoretical side even when self-taught, since the level of math involved is what makes it difficult for most people.
But regardless of the greater level of self-teaching, the math major is unlikely to have had as good a survey of CS ideas as the CS major.
Edit: I agree with everyone else who says that major in school isn't a very good predictor of software engineering ability. This is just my opinion on the direction of the small part that does come from major is.
So, pick any random math major and any random CS major, and at the very least, the CS major has a better chance of having the foundations needed to become a good programmer.
On the other hand, pick math and CS majors from among the ones who have actually shown enough interest in programming to steer their careers in that direction... now the gap is potentially much smaller.
Now compare math and CS majors who have worked for 10 years in software development...
To the question, Math is an exact science. Building software is a creative architectural and design process. My guess is that Math can be very helpful on a algorithmic level but not so much on an software application level.
The reverse OTOH seems more challenging. I’ve seen many CS graduates who tried to self-study their Black-Scholes, but rarely do they achieve anything more than a superficial understanding of the underlying theory.
[I’d except HFT from the above. That specialty seems to reward programming skills more than math skills.]
I'm a programmer by trade but I trade options on the side. A long time ago, I read Hull's and Sinclair's derivation of BSM line by line. Nowadays, I totally forget all the math except the intuition as it relates to the greeks and base all my trading on those.
Talking as a non-professional, I found the math of BSM to be helpful for me to understand better the option greeks and the model's limitations (assumption of smoothness, doesn't take into account volatility simile's).
But not sure how the theory can really help me hedge better, come up with better implied volatility as compared to the current open source plug n' chug frameworks that computes Black-Scholes pricing (e.g., QuantLib).
Options trading is a hobby of mine and I'd love to hear a pro's take on these. Thanks!
In everyday terms, BSM vols are also what's used to talk about what the price IS. So even if you're using a fancy model, to talk to someone else about it you pull out the BSM vol and tell him that way.
What will help you hedge better is finding a way for your surface to fit what actually happens when the market moves. It isn't an exact thing; many traders ask for a little more or a little less floating skew from their quant guy.
The financial stuff is IMO not complicated. Anyone (a lot of the traders left school at 16) can understand how the option Greeks behave intuitively. Since I went to uni, I picked up the classics (Hull, Wilmott, Niederhoffer) and read through them. After a while, you get it. You may not be able to derive all the little things (options on options, Asians, whatever) but you'll still have a reasonable idea of how it works.
The programming side is a whole other can of worms. You think you get it. Take Excel. Put in BSM. Make a vol surface. Do a VLOOKUP on a grid, remembering to do the $ signs. Float it to adjust the calls when the market rises. Hey, it's easy right? You can just make some VBA code, dump it somewhere. Put some intermediate calculations on a hidden sheet.Boss wants an alternative model? Copy-paste and edit the formula. Call Bloomberg for some data on another sheet, use it to calculate some parameter. Save it as ESX-jumpmodel.xls. There's a get-it-done-quickly mindset that isn't great, but creates the illusion of working well.
Code written by finance people has a reputation for being incredibly spaghetti-like.
When I started off coding, I thought it was easy too. But it's the most time consuming part of all my financial work. Each time I had some new interesting thing to do, a huge gap in my knowledge was uncovered:
- Started using Excel to do end-of-day reconciliation, the bottom rung task of junior traders. Took me a week to do something that today would take me half an hour.
- Coding a NIG model to price options: took me ages as well, and the guy at the trading software company said it was easy. Spent a LOT of time getting Cygwin to work, had to go through loads of compile fails in gcc (I didn't even know what that was when he told me). What's static typing? Why can't they all be variants? The easy part was finding a formula for the Bessel function.
- Coding a spreadsheet for fixed income arbitrage: once again the easy part was understanding basis, swaptions, asset swap, carry. The hard part was organizing all these sheets in a sane way, for 10 currencies and terms from overnight to 50 years. Also, calibrating/fixing conventions was easy. Call your broker, ask him what he uses for his curves.
- Writing an FX feed multiplexer. Easy on paper: you get a better price by comparing feeds from different banks and picking the best one. In practice: you need to read all the intricacies of the FIX protocol. You need to know how service oriented architecture works (all those banks aren't going to run in a monolith, are they?). You need to know how a network works. You need something that isn't Excel, so now you need a UI as well. Oh, and you're saving trades in a database, right? Hello SQL 101.
- Glueing a trading engine on to the multiplexer. Easy on paper: model tells you what to trade, and you already have a multiplexer. Now you need the UI changed to put knobs on the model. And you're sure you won't machine gun the trades right?
- Making a thing that looks at the orderbook to trade: now you need to be fast. Is the math any harder? IMO no. But what does fast mean to a guy who's never had a speed issue? What's c++ anyway? And why is there an allocator on all the constructors? How do profiling tools work? What's this 200ms delay (I kid you not, forgot Nagle once!)? Why does everyone talk about Big-O? It never came up when I was does the spreadsheets.
- Making a thing that looks at an exchange binary feed: uhm, what's binary? What is this endianness? What's a lockless ring? What's a kernel, and why do I have to bypass it? Branch prediction? False sharing? Cache invalidation?
IMO it would all have been easier to teach a CS grad about finance than a finance grad how to program.
But majoring in math is (or should be) a sign you actually enjoy math. That's important for a few domains like computer graphics and data science/machine learning.
I think most CS majors are good at math, but that doesn't mean they enjoy it. Furthermore, there is a huge gap between getting good grades in math and actually understanding it. For most coding jobs, that's OK.
The workaround is simple: get a graduate degree. If you get a CS PhD (maybe an MS) specializing in a math-heavy domain, you'll end up with the fundamentals and domain knowledge you need. For many positions, it could be a requirement.
Doesn't matter that much (to a certain degree) if you are the CS Master, Math Wiz or the Alchemist, you have to program, program and program to become a better software engineer.
It's true that studying CS will give you the privilege of understanding some pretty darn complicated concepts that you wouldn't actually read in your free time.
And the same for studying Math, picking up all the good logic and proper way of writing your algorithms.
But again, the only way to become a better software engineer is to do software engineering.
Faster? Math grads might be able to use some mathematical trick to dramatically speed up the code.
Better modularity? Version control? Tests? Experience with SDKs?
What math trick? You mean knowledge like how caches work? Or, how to spot n^2 solutions that could become n? Or, dynamic programming? Or, linear optimization?
Unless you are doing something math specific(in which case you should have someone with more math knowledge than a new grad who can spot these. My first internship had a math phd in the team just for that reason), you will fare much better with your CS grad.
Advice to students: Pick the area that interests you more. If you plan on pursuing a software career, pick at least a minor in CS.
By your logic a pure physics grad would be an even better software engineer, as physics is even more "low-level".
How would Physics be more low-level than mathematics?
A mathematichian who knows some code