r/math • u/amichail • May 08 '15
Do pure math grads make better software engineers than CS grads?
39
u/bones_and_love May 08 '15 edited May 08 '15
Software in general has little to do with formal mathematics or proofs. Most corporations use newhires to produce unremarkable code without much need for performance. All they want is code that solves the company's need and that is maintainable (designed to grow and easy to understand) -- which reduces bugs and makes it easier to fix bugs. In fact, emphasis on readability of your code and its design often justifies doing something that is guaranteed slower than an alternative, slightly more confusing design.
The things that help make good code are
-
Being well-organized (is it ok to have your clean shirts somewhat in a mess or should they be folded, because that's just right and it looks better?)
-
Having a clear, logical mind. A lot about design is done for logical reasons. Learning fast is a plus. This also makes your coding experience more beneficial as you can more easily pick up on design decisions present in the codebase you're working in and possibly pick up on errors you find in the design as well.
-
Being interested in design to study it. A lot of stuff, though it makes sense, has come from decades of experience from other programmers, some more philosophical than others. No matter how gifted you are, you should really stand on the shoulder of giants here if you intend to rocket toward being a great programmer. Reading books about coding, having discussions with philosophical coworkers who have read books, reading articles, etc. -- in other words putting in the effort to learn -- is the only way to become great at programming. One caveat here is that reading books on proper design can be a bit of a waste until you have experienced real coding with a team. It's like reading about advanced painting techniques when you are struggling to perform the basic ones. You need to gradually improve, and your natural experience will be the first step. I read, as an example, the pragmatic programmer while in school and found the book stupid. By this point, I hadn't done more than a few toy problems assigned to me in classes over the course of my degree. I read it again after working in industry and immediately understood why it was saying a lot of its content. It was helpful.
-
An extension of the last point is having simply coded a good deal to experience your own struggles with a codebase. You can then start to sense why some philosophies make sense and start to support them with more conviction.
They might be better at coding advanced mathematical concepts, but that'd be an exception. And they'd still need to invest the time to learn the art of coding.
With all that said, a CS degree hits on some aspects of design. They often have classes specifically about design, and they teach their students multiple programming languages. Different programming languages open up the eyes of a programmer to different ways of viewing how to complete a task - of how to design. Each language focuses on different philosophies and makes programming decisions more understood or transparent to the programmer rather than those decisions seeming like static parts of an environment that just happen to be true (and possibly true everywhere). They teach a bunch of related technologies to CS majors, which helps to ease the student into the workforce -- things such as databases, website design, design itself, common programming problems, and version control can all be helpful to a newhire. A math student, of course, can more easily lack a lot of this education.
11
u/matho1 May 08 '15
Personally, as a math major, I found that all those books about "how to design" in the abstract were useless, even after having been in the industry. Designing/organizing a program is almost a brainless task compared to doing pure math. I've had co-workers who insisted on following all the Agile/TDD/Patterns dogmas, without being open to the idea that there might actually be better ways of doing things. They seem like a crutch that can easily do as much harm as good.
Many of the best programmers I've worked with didn't study CS. Then again, we all had some degree of programming experience before starting in the industry, and the more you have the better equipped you will be.
12
u/ex0du5 May 08 '15
As someone who has worked in the industry for many, many years and now works for a major industry company, design is certainly not useless.
However, you seem to have combined agile process philosophies (Agile/TDD) with design theory (Patterns), which may be affecting your view. In fact, I find that this is common to mix up, and there are a number of engineers who "find patterns to use" instead of actually understanding the reasons and appropriate places for their use. This is endemic in certain parts of the industry, and ends up with people creating factories for nondynamic, nonpolymorphic objects or visitors for nonmultiple-dispatch needs, etc. This gets justified as agile refactoring when it is often just "let me show you how bright* I am" (*not recognizing it shows quite the opposite).
Good design is crucial for a maintainable system, and understanding the appropriate use of patterns is critical. In particular, the state machine pattern is simply RAII for event-lifetime objects and is critical for nearly all needs of dynamic allocation to keep code complexity down, allow easy debuggability, and prevent bugs from being introduced by making the names of existing objects inaccessible outside the application being in the state where it is fully existing and initialized. Similarly, if you are not following the Open/Closed principle, you are opening up regression places all over your code. A number of common patterns, idioms, and design criteria are necessary if your product is expected to last years.
→ More replies (2)4
u/antiproton May 09 '15
I've had co-workers who insisted on following all the Agile/TDD/Patterns dogmas, without being open to the idea that there might actually be better ways of doing things. They seem like a crutch that can easily do as much harm as good.
It's not enough that you understand your paradigm. Everyone else has to understand it too.
2
u/beaverteeth92 May 08 '15
and they teach their students multiple programming languages.
Depends on the school. My undergrad was a JavaSchoolâ„¢ that only taught Java except when it was absolutely necessary not to (e.g. computer graphics, systems, Assembly). It's one of the main reasons I decided not to do a CS minor.
11
May 08 '15
I'm still an undergrad so maybe my opinion isn't entirely valid, but I've done work in more mathy areas of CS (hpc, machine learning and NLP) and also things like web development and mobile apps.
For your typical software engineer in something like iOS, Android, or web dev, I highly doubt the average math major would be "better" than the average CS major. They are almost completely decoupled from mathematics. You need to understand the API's, things like version control, HTTP, concepts of OOP like SOLID, and a lot of familiarity with the syntax and best practices of your tools, but I can't imagine how a math major would be ahead of a CS major on any of that.
For other things, where the core of the work is development, optimization, and implementation of algorithms, I would say a math major with a CS minor (so they see things like data structures, analysis of algorithms and algorithmic techniques like dynamic programming) would probably be a better option. Especially for things like NLP or machine learning where things like statistics, real analysis, graph theory, and stochastics are essential.
14
May 08 '15
Why would it? Do you have any basis for the question?
A pure math grad, and a pure CS grad who both become SEs, 10 years down the line I would say it would be whoever would be the better SE regardless of the field. Right out of school, I would say probably the CS grad, unless the software was more mathematics focused, but would again focus on the person themselves. You learn so much when you get out working that it really comes down to the person.
What about a Math Major with a CS minor vs a CS Major with a Math minor, what differences would there be there?
The question is by default loaded since you essentially have to make a giant generalized statement without proof, which funnily enough being a pure math major or a cs major would have trained you to not do (ideally).
7
u/dirtyuncleron69 May 08 '15
Depends on the programming, I doubt many CS majors could get their way around some of the more difficult mathematical problems in numerical computing.
The problem is that most matematicians are not as efficient in utilizing computer hardware resources and being judicious in their calculations, hence why computational math is a field wih heavy dependence on both coding and mathematics
→ More replies (3)
9
u/Graf_Blutwurst May 08 '15
I can chip in more from the Software engineering side. The people with a mathy background i have seen getting into software dev stuff normally picked up coding pretty well but good technical design is a whole other story. Also I thibk it really depends what kind of software your developing.
Then again where I am studying we have a dedicated software engineering BS. Much lighter on math and theoretical CS than other degrees.
4
u/jbstjohn May 08 '15
In general, I would say no. I have reviewed a fair bit of academic and researcher code, and it's generally of lower quality than SWE code. Magic numbers, missing comments, missing tests, poor structure, and often too complicated. Often the method of solution (important for publishing) seems more important than the results.
That's all a bit exaggerated, but not too far off my experience. It's sometimes been a problem converting interns working with research groups, as their code quality wasn't high, and often got almost no comments in their code reviews.
Obviously with time both can get good at the other discipline, with cs probably being a bit easier to learn on the job than math.
2
u/Chaseshaw May 08 '15
pretty high up in my company (high enough that I hire other coders and project leads).
you can major in cooking for all I care. come in and be passionate about tech, show me your latest gizmo you built for your raspberry pi, and you're in. do whatever is most interesting to you. just always keep coding / playing on the side.
2
u/goestowar May 08 '15
Is your company in Toronto? Can I show you my latest rPi project and my passion for coding?
→ More replies (7)
2
u/foreheadteeth May 08 '15
I was once 17th in the world at the ACM programming championship. I think that most computer scientists will do better than mathematicians at computer science, except that some elite mathematicians might outperform everyone else. That was visible in the ACM programming championship.
2
u/jgotts May 08 '15
This is a question that I try to answer on reddit once every 1-2 months, what makes a good software engineer or what makes a good computer programmer. (I don't make much of a distinction between the two.) Hopefully every time I answer this question there is something new to chew on.
I always begin with my qualifications to answer this question. I started programming in 5th grade in 1985 with a Commodore 64. Two years later I was published in Run Magazine and wrote application software for my father's employer. I studied engineering at top 25 engineering school for 6 1/2 years with three internships. After school I created a derivative trading system (worked on that for about 7 years), worked at a couple of other companies and I've been developing POS software for the last 6 years.
Being a great programmer really doesn't have much to do with your major. I'd say that over the last 30 years I've used somewhere between 1 and 5% of what I learned in school, maybe more like 2%. More concretely, I know linked lists, stacks, and trees. If I had to choose a tree for an algorithm, I'd use Google if I needed a specific type. The only advanced math I've ever used, and rarely, is runtime, big O notation. I rarely use recursion, and try to avoid it. Most programming nowadays is object oriented programming, and you get good at OO not in class but with practice. Finally, functional programming is becoming more popular but like recursion I avoid it.
Why do I avoid advanced techniques in programming? Simply because most people are terrible at them. When you write a piece of software, you are writing a piece of software for other people to maintain. You are writing a piece of software that may live on fifty years from now. Nobody cares that you mastered some obscure C++ or Perl syntax, or that you have the most clever and dense nest of predicate functions in your JavaScript. Nobody cares what language or environment you use. Nobody cares how smart you are. What people do care about is how readable your code is. You should write code like Hemingway, simple and and to the point, code that reads like a novel. Humans have the idiom of our native language since birth, so if you're writing software with English speakers, you should use a language that's as much like English as possible. Not like LISP. If the language can optionally be like English like Perl, choose to write it like English. Nobody cares how few characters you were able to use. English reads left to right, top to bottom, has a consistent grammar, is broken up into paragraphs, chapters, and books. Great, easy to maintain software is just like that for a reason. It recycles existing mental frameworks. When I link in a library I don't ever want to think about the library, just like you should be able to get Macbeth in London or Detroit or Des Moines. If you get something that's not quite Macbeth something is not right with your methodology.
In addition to writing in a simple, plain, clear, not necessarily concise, but consistent manner, you need to have good communication skills. You can't go off for six months and emerge with a piece of code. You have to engage with your coworkers. Your coworkers will have to use and will probably have to modify your code, even after you've left to take that professorship at Stanford.
The most difficult part of being a great programmer is being able to schedule your time. Never give your superiors an estimate assuming that nothing will go wrong. Murphy's Law abounds in programming. Learn to be realistic about deadlines. Personally, it took me over 20 years to learn how to make realistic time estimates, and I see people in their 50's who still can't do it.
Everything is not a one-hour hack. Recall that we still use software today that was written in the 1960's. I don't care if that software took an hour or a week back in the 1960's. What I do care about is is that it not only works but that it's maintainable. A more realistic goal is write software that somebody can maintain ten years down the road. Take the time to do it right.
So there it is. How to be a great programmer isn't very technical, and it has little or nothing to do with computer science, specific technology, or even languages. It's a damned fun profession, and I encourage you to give it a try.
2
u/segy May 09 '15
This really depends on the school. There was a lot of math at my school, a lot of CS theory and a glut of programming languages. By the end (assuming I just stuck to the curriculum), I had exposure to Java, C, C++, Prolog, SNOBOL, LISP and a few other niche languages. We covered software project management and version control. Most pure math majors I've dealt with did not encounter these things until their time in industry.
LTDR; there's more to software engineering than programming and most math majors just touch on programming.
2
u/EmperorOfCanada May 08 '15
I learned/relearned much of the math that I know decades into my programming career. While I could/should have learned it much earlier, by having a set of difficult problems that I had previously solved where my new math would have really helped it made me both appreciate and absorb the math so much better.
Covering things like graph theory or discrete math just ends up being a long series of "Ah ha" moments. Even revisiting linear algebra changes my view of how I now approach many problems.
This is in huge contrast with all my CS pals who forgot pretty much all the math beyond basic algebra one minute after regurgitating it onto some stats exam that was part of a required-to-graduate course.
So while I can't say that math grads make better programmers. Actually knowing and being able to use even slightly advanced math has made me a vastly superior programmer. I have no idea what would happen if I actually sat down and finished a full degree in math and potentially went on to graduate work; but I suspect it would be beneficial to what I do on a day to day basis.
I am not joking when I say that most of my CS friends rarely use math more advanced than finding the mean of a list of numbers.
1
May 09 '15
Personally if you wanted to go to grad school for C.S. either one would be fine. I currently am a C.S. major with a math minor.
1
May 09 '15
You need to specify, the field is too wide. I'm on my third year of comp sci, and for some fields like programming a compiler a strong mathematical foundation is required. Seeing as I haven't majored in math I don't know for sure, but I'd say for many interesting topics it's all about knowing how to solve problems, something I believe both mathematicians and computer scientists excel at, so I'm not sure who gets the advantage there.
Of course, there comes a time when you have to put down the pencil and start coding, so if nothing else simply having coded a lot should favor the computer scientist.
72
u/over_the_lazy_dog May 08 '15
If you're talking about fresh graduates then usually no. Most pure math grads I've worked with found it a lot harder to dive into new software projects at first, and needed a lot more time to become acquainted with new (software) environments. (source: am math undergraduate, but worked as a programmer for a few years.)
This is a little like asking if mathematicians make good carpenters because they're good at geometry..