Slashdot Mirror
You Don't Have To Be Good At Math To Learn To Code
HughPickens.com writes: Olga Khazan writes in The Atlantic that learning to program involves a lot of Googling, logic, and trial-and-error—but almost nothing beyond fourth-grade arithmetic. Victoria Fine explains how she taught herself how to code despite hating math. Her secret? Lots and lots of Googling. "Like any good Google query, a successful answer depended on asking the right question. "How do I make a website red" was not nearly as successful a question as "CSS color values HEX red" combined with "CSS background color." I spent a lot of time learning to Google like a pro. I carefully learned the vocabulary of HTML so I knew what I was talking about when I asked the Internet for answers." According to Khazan while it's true that some types of code look a little like equations, you don't really have to solve them, just know where they go and what they do. "In most cases you can see that the hard maths (the physical and geometry) is either done by a computer or has been done by someone else. While the calculations do happen and are essential to the successful running of the program, the programmer does not need to know how they are done." Khazan says that in order to figure out what your program should say, you're going to need some basic logic skills and you'll need to be skilled at copying and pasting things from online repositories and tweaking them slightly. "But humanities majors, fresh off writing reams of term papers, are probably more talented at that than math majors are."
Programming -- I don't think that word means what she think it means.
I've fallen off your lawn, and I can't get up.
As an obsessive pure mathematician who is obsessed with twisted forms of coding minimalism to stave off boredom and so on, and who did his PhD in arithmetic.
1. You learn to count from 1 to 100 so well it is effortless.
2. You do so in a way that is fun (e.g. snakes and ladders).
3. You learn to code.
4. When your coding problems require mathematics, you look it up in a book.
Crucially, if you do it this way, you will have motivation to learn the hard maths. Really, motivation does seriously make a difference here.
John_Chalisque
...when you need to google the hex representation of 'red'. *much* better to understand the encoding, and it certainly isn't hard or requires tricky math. it's literally RRGGBB
This is why so much poor software exists in the world. I can only imagine what nightmare code is being generated by such efforts. Yes, anyone can code, just as anyone can build a house. Whether or not the house collapses immediately, whether it has any real value, or by any other measure still depends on the skill of the builder, just as in software. Garbage in -> Garbage out, applies to the code as well as the data. -AB
You don't need to be good at math to learn to code...... but as programming at its core *is* mathematics, learning math will almost certainly help you to write better code.
File under 'M' for 'Manic ranting'
I've been writing software for more than 20 years at this point. While yes, if you're doing anything involving creating algorithms or computer graphics/gaming you will likely need higher level math, the average programmer (making websites, making desktop business apps) does not need to learn anything more than basic mathematics.
It irritates me when I hear elitist coders or hiring managers harp on about the need to be a PhD Mathematician on the side while also being an expert in coding. Just as you don't need Picasso painting your bathroom, you don't need a rocket scientist to code your shitty business app.
We have Google!
Lord, help us!
“He’s not deformed, he’s just drunk!”
And there's a shit ton of CRUD apps that people want written that don't need anything of the sort. There's a world between high-performance computing and the most superficial use of a computer. Excel macros spring to mind, as an example. We can also draw a line between simple computation and more complex mathematics -- simple calculations are absolutely the computer's job.
To answer your "So what?": useful shit can be done even without having learned everything that you did. What useful purpose does elitism serve?
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
The author doesn't seem to understand what math IS, how and why programming IS math. The author writes that you don't do a lot of algebra and such in typical web pages. Does your PHP script use SQL? That's algebra, relational algebra. It's not that you need to remember mathematical formulas; it's that have a half decent design for your software, you need mathematical THINKING. If your high school algebra homework was wrong, your sql is probably wrong too.
The author likes to copy and paste a lot. Yeah, I've seen a lot of that kind of code, mostly while rewriting it to work properly.
Programmers with a clue #include, they don't copy-paste.
It's not that you need to write the tangent function from scratch, and purely from memory. It's realizing that tangent() SHOULD be a function, which you should call from libmath. The author managed to copy-paste code that computes a tangent into the middle of the onclick() handler. That's Doing It Wrong.
Based upon my three decades of programming experience, programming at rare times may require you to brush up on what you learned in engineering school, but essentially your degree is mostly a worthless piece of paper in terms of career usefulness. I've used much less than 5% of what I learned there, and probably more like less than 1%. My most useful class was software engineering, because it touched on the non-technical aspects of being a programmer.
There are small subsets of programmers that use geometry and calculus, but even if we only remember the basics those types of programmers don't need to worry about nit picky details because we all use libraries. You'd be absolutely foolish to open up a calculus book and write your own library function, unless you're doing something extremely novel. Novel is bad when you are trying to write maintainable code.
What is useful to you as a programmer is to understand what big O notation is. It's advanced math beyond calculus, but it always seemed like common sense to me. If you have to do n^2 operations for every n, that's worse than having to do n operations. In 30 years I've never had to worry about little o or logarithms. Google gets specific in interview questions about all of these notations, but I'm telling you what is actually useful.
What is not useful to you is mastery of the syntactical details of any language. Try to program as if you're writing English. Write software in such a way that you could be doing it in any language. Write software that the next person can read, instantly understand, and begin modifying.
Programming isn't purely doing Google searches. What I spend most of my time on is seeing how the software I'm working on already solves a problem and to use as similar techniques as possible, so that the next person who works on it will encounter consistency. Every change I make I make for a reason, and I understand every change I make well enough to explain it to my mom.
Another way of looking at it is the technical interview is almost completely useless. You can ace a technical interview and write the shittiest code I've ever seen. You can perform average on an interview and write the cleanest code I've ever seen. If anything, detailed technical knowledge should count against you. The next person to maintain your code might not know every trivial little feature of the language you're using and has no admiration for your cleverness.
Write software like Hemingway, not Thomas Hardy, and don't sweat the math.
I have no idea what is Combinatorics, and I would have to google many of the words in your comment, yet I've been programming for a living since the late 90s.
Not everyone in IT is coding videocard firmware.
lucm, indeed.
You don't have to be good at anything to plagiarize
We have Googling and trial&error because documentation of APIs is universally deficient.
I just spent two days trying to figure out why my OpenGL 3.2 context would not initialize on Linux. In the end I found it was because I was not using a private colormap. It doesn't make any kind of sense to me, even now, and even knowing what to look for I wasn't able to find any kind of warning in what is laughably called a "manual" (it sure looks like a quick list of function calls without any structure and barely any explanation to me, but YMMV).
How many times do we have to see this:
int CreateContext (int, void*)
"this function creates a context. The first parameter is flags. The second is used to pass additional information."
and are left wondering:
- what _is_ a 'context', what do I need one for, and what is its lifetime?
- what flags can I pass? What do they do, _in detail_?
- what "additional information" can I pass? Is it mandatory? Is it flag-dependent? What structure should it have?
- can there be errors? How do I see them? How do I decode them into something human-readable?
- if I delete the context, will it take any associated items with it, or do I need to free those manually?
- what sort of thread-safety can I expect?
The problem is not skill level, although it certainly helps to be equipped with knowledge of other APIs and the right level of paranoia. It is, for a very large part, badly designed and even badlier documented APIs. And it really doesn't matter where it comes from, amateurs or pros, open source or closed, it's all painfully bad. The best you can usually hope for is a list of function calls, but almost never any sense of how it hangs together, good explanations of parameters and return codes, and let's not even start about thread safety...
As an example of good documentation, I'd like to point out Postgres. These guys really work hard on documentation, and it shines as a result. MSDN, assuming you can find what you were looking for to begin with, is not bad either. And on the other end of the scale we have things like OpenSSL, where I believe lack of documentation is in fact part of their business model. That alone should be reason to avoid it...