Teaching someone with a physics background to code while on the job is doable if you are willing to throw the code out. Programming is as much of a learned skill as any skill and expecting someone with no programming experience to quickly catch up to someone who has been studying and actually coding for a few years is not realistic.

I haven’t met anyone with a physics degree in the past 10 years that cannot program.

Programming is required today to attain a post graduate and even graduate at physics since you’ll be programming a lot of math problems and more importantly simulations.

We have 8 CUDA programmers at my work place and only one of them has a degree in computer science/SE the rest got post grads in Physics Chemisty or Biology.

On a grad/undergrad level for the most par CompSci students would not have much advantage in programming today over Physics or other exact science/engineering students.

Then they really aren't being trained on the job are they? Thanks for the info about the programming experience they get. I know a few graduate level physicists, but they never talk about programming.

They are, everyone is being trained on a job to some degree. If you are hiring graduates you are going to be training them on the job for a while even if you hire SE/CS students only there is a big difference between knowing how to program and having experience in software development and delivery.

But some things can be trained while others realistically cannot, you can train people on the job rather quickly to develop using a given framework and toolset but giving them background in fields that require nearly decade of dedicated education is a different story.

The truth is that unless your bootcamper has had proper education they would not be able to catch up on the theory.

Forget algorithms maybe 1 out of 10 bootcamper I've interviewed understood basic mathematics like vectors and scalars, were talking about High School level Calculus here.

But again if you only build basic web applications and implement pre-defined UX/user stories there isn't much need for this.

Bootcamps aren't new I remember the Java/C++ 8-12 week night schools from the 90's which were later supplemented by .NET schools that was huge in the early to mid 2000's Microsoft was pushing Windows 2000/2003 MCSE and MCPD to highschool students in my country.

My older brother effectively use a bootcamp in the late 90's he had a masters in electrical engineering he had some programming experience mostly in FORTRAN but effectively in .com boom of late 90's he switched to programming after doing one of those JAVA and C++ evening courses. That said I don't think he would've gotten to IBM and now into Redhat without his previous education, that course was effectively just a seminar for him.

The initial comparison was between someone with little training in a discipline and someone educated in a discipline. Of course every graduate needs plenty of mentorship at their first or first few jobs. That's not the same as training someone with no exposure to a discipline.

As far as bootcamp graduates go, I would be careful about assuming that's their only exposure. I'll take someone who has been obsessed with coding since they were a kid over a uni graduate who is just in it for the money, went to class, and only wrote code to pass the classes.

Yes but it really depends on what you need. If you only need coders for standard applications there likely won’t be much difference.

If you need them to work on more complex things say computer vision it might be more tricky unless they only consume existing libraries. It’s much easier to learn RoR than it is the lean the math needed to say understand what a Fourier Transform is.

It really depends on what the programmers actually do; implement a known solution or come up with one.

I've been curious about this issue, because I've been relatively successful in my so-far short career as a web developer. Yet I'm self-taught, and can't math my way out of a paper bag. I'm good at logic so that's gone a long way in helping me.

I always wonder, though, whether I'll eventually run into a math-critical issue and cannot just reason my way through it. It's a terrifying prospect, but luckily in my 5 years of dev experience I haven't faced that scenario.

The vast majority of actual profit-generating programming that is done in the world requires almost no mathematics beyond basic arithmetic. Unless you explicitly want to get into something more maths-heavy, I think you'll be fine.

I used to do and enjoy algorithm competitions as a student, but in "real life" I've found there is almost no correlation between the complexity of the algorithms and the amount of money to be made.

I'm always surprised when people try to connect math and physics to CS/programming. I studied differential geometry in grad school, wrote proofs and read dense textbooks daily (very rarely missing a beat), then taught myself programming/CS. I'm now four years into my career, doing pretty well.

I see almost zero connection between the two:

* CS/programming: techniques (a mathematician might refer to these disparagingly as "tricks") used to make machines do things

* mathematics: foundational truths on the study of space, quantity, structure, change etc.

The most mathematics I've ever used on the job was basic (read: finite-dimensional) linear algebra, which is a part of every undergrad math student's basic toolkit.

If you're concerned about holes in your knowledge as a self-taught web dev, I'd study core CS courses like architecture, operating systems, networks. Know what you don't know that matters (hint: it's not "math").

EDIT: there may be a strong connection between computability theory and math https://en.wikipedia.org/wiki/Computability_theory, but I don't think this field is mainstream in either core CS (could be wrong here?) or math. I've certainly never encountered it on the job.

I'm in a sort of same place. What I found out is that it's never too late to go back and open a math book. It can actually be pretty fun! Especially if math is the only way toward achieving something you want.

For me for example the turning point was having to learn a lot of trigonometry to apply to an AR app. No way I could have done without, but because I was still doing something I love I got the motivation to learn.

If you don't use math, it's almost certain that you're writing inefficient code. There's no way to estimate big-O complexity of the procedures you're writing without at least some math. Unfortunately these days it's considered ok to write chat applications that consume several gigabytes of RAM, so maybe nobody cares about efficient code anymore.

I see tons of people online writing algorithms in python and ruby, that will run against a few megabytes of data, and worry about getting the "big-O" of their algorithms right.

Then I go ahead and show them that just by doing the same thing in C++ you get a 10x speedup if you know what you're doing, sometimes more.

And then they say "but I'd never get an optimal algorithm done" (that C++ is typed actually makes this easier for me then python as soon as we get past the "trivial" complexity level, but to each his own I guess).

So I say "Ok. No worries ! Let's make it inefficient !". And add an inner for loop where a hash lookup would have done it (for example). And lo and behold ! The C++ code still beats the crap out of their "optimal" python code. (this is somewhat of a cheat because the odds of making a random thing somewhat inefficient is very unlikely to be the critical point of that code, even if it's in the middle of the deepest loop). Then we replace their 100mb csv with a new 10mb memory-mappable data and they can't even measure anymore how fast the program is. As soon as we enter main, it just immediately terminates.

Algorithms start to matter when your data, optimally stored, becomes >10x all the CPU cache combined, ignoring things like strings. That means 300-400 megabytes when stored fully binary. Ie. you DO NOT HAVE ANY SUCH DATA. Your company's yearly transaction log is less than this. Before that, forget about algorithm optimization, it will bring you nothing.

TLDR: If you're not working in C++, and actually doing most of your development on data layout in memory and on disk, you don't care about performance. Math does not matter at all. Once a year I encounter a situation where math matters, and frankly I just usually find a PhD in that specific field and ask them (despite having a master degree in Math myself).

You do not need math to program.

The big secret is that for programming, there is only one thing that matters beyond basic programming skill. And that thing is domain knowledge of the problem. Exactly, I might add, what almost all programmers don't have.

No, algorithms always matter. Especially in web-development. Yes, Javascript is slow. But there's no need to make it even slower by writing O(n^2) code where O(n) suffices. You don't even need to reach large n's to feel the lag. I personally had to rewrite such code, which was causing horribly slow website performance.

The big-O thing is not about C vs Python. A slow C program will lose to a Python program with a properly written algorithm any day of the week. Just because of how the math works out. The speedup of using C is linear (in practice, worse than linear). Suppose the O(n^2) C program executes each instruction 1000 times faster that the corresponding O(n) Python program. Then you only need n to start reaching thousands to blow the C program out of the water. Meanwhile, O(n^2) Python program would be a thousand times slower than that. And to me, that's unacceptable.

Web development is about displaying ONE PAGE of data. 20 items. 40 items. 100 items. No more. A far cry from the thousands of items you say it requires (I'd argue that it's a lot more). And just so we're clear a supposed O(n^5) algorithm with n constant (like on paginated web pages), is really O(1).

The thing about O(n) algorithms versus O(n^2) algorithms is that very often rewriting an O(n^2) algorithm into an O(n) algorithm involves splitting the loops, and using way more memory.

And that's assuming you do it correctly. Mostly people don't. Example, your basic optimization of a double for loop turns into:

  # (1)
  x = {}
  for e in lst:
    x[e.field] = e

  for e in lst:
    e2 = x[e.value]
    # do something with it 

Is that x[e.field] is an allocation and takes O(n) time. So this is an O(n^2) loop, and you have saved nothing over this, even in theory

  # (2)
  for e in lst:
    for e2 in lst:
      if e2.field == e.value:
        # inner loop

So in this obvious case it takes infinite items in theory. Even that is a wrong prediction. (2) will also behave very differently depending on whether the VM is just starting up or has been running for a while. So in practice here's what's going to be faster:

  n < 10000 or so: (2) (the actual number depends on the CPU, but it'll easily be 500 even on the most pathetic atom or even mobile processor)
  n > 10000 and total size < system memory / 2.5 or so: (1)

Why, in the beginning not doing the setup is just faster by itself. This lasts a long time because when the inner loop executes in cache and the hashtable copy does not fit in cache the loop is 100 times faster (on top of that ~100 times C acceleration). This means the loop stays fast for a long time.

Needless to say, this means that for anything you should do client-side the double loop will be the faster option, even on the slowest mobile cpu any of your customers might use.

At some point the Hash table will start winning. Until it causes virtual memory activity during the lookups. At which point, it's memory usage makes it useless. I'll see about actually running this test with an actual example program.

Hence, it's good to keep Rob Pike's rules of programming into account: http://users.ece.utexas.edu/~adnan/pike.html

Rule 2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest.

Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.)

Probably not. There are jobs that might require some decent may, so stay away from them. But you're average programmer won't run into a math critical issue.

> the comparison to race or gender issues in the beginning is in extremely bad taste

Coding "bootcamps" have been broadly embraced by people trying to get programming (about as gender-selected a profession as there is) opened up to people from broader backgrounds. Obviously there are white dudes that come out of these programs too, but... no, it's not too much a stretch to imagine someone talk about "bootcamp applicants" as shorthand for post-college women looking for a change of career.

Likewise, sure, it's possible that someone is just using "bootcamp" as shorthand for "unqualified" and trying to sincerely convey the deep background required of the position. But it's not in "bad taste" to imagine something a little less wholesome either. Which is to say (pause while people get out their SJW hatchets): check your privilege a bit. It's easy for people like us who followed the rules and have the right chromosomes to imagine that injustice doesn't exist. Those closer to the problem have a different perspective.

I do absolutely believe that injustice exists. I've seen women with extensive academic and job backgrounds be treated like amateurs by guys. That is absolutely real and needs to be combated.

But don't mix those things up when it comes to the bootcamp issue. I would rather state it the other way around. Women can complete and do deserve to get a full education. We do not need to funnel them through rushed education systems, or be afraid to evaluate candidates candidly. It is not productive to keep bad and often expensive programs alive that market themselves to people looking for a career jump.

> Women can complete and do deserve to get a full education. We do not need to funnel them through rushed education systems

To paraphrase: "Women who didn't get a CS degree in their 20's can shove off, they're beyond hope and shouldn't try to break into a profession where they aren't qualified"

One man's (heh) objective and rational criterion is another's instrument of oppression.

All we hippies want you to do is just evaluate candidates on their own merits and not use shorthand like "no bootcamp applicants!" which can be easily construed as discriminatory. And it wouldn't hurt if you could try to see things from other people's perspective too, but that's optional.

that's not what I said at all. All I want to avoid is that women pick up bootcamp educations in the hope to get a job, fall short in interviews based on merit, and then end up stigmatized as second grade candidates. Which can easily happen if only certain demographics pick up a specific education path, that can't objectively compete with the expectations these people face in their jobs.

Don't sacrifice the quality of education just to pursue an egalitarian end, it will backfire and get you the exact opposite result of what you want.

> that's not what I said at all

Whoosh, as it were. The point is that when you say that, it is what some other people hear. And that forcing disadvantaged demographics to read your mind to tell whether you're simply naive or a sexist jerk is hurting all of us. There are principles at work here beyond "sacrificing the quality of education".

The bottom line is that you aren't being nearly as welcoming as you think you are.

sorry but my job when interviewing someone isn't to be welcoming. My job is to be fair, assess the person's qualification and experience because businesses work with restricted time and information.

The interviewer will never know your entire backstory and needs to make a decision relatively quickly. If I would start to be overly empathetic or sensible, I would arguably start making biased and bad decisions based on personal gut feelings. That's what I need to avoid, not encourage.