Physics A physics major is not good preparation for a career in software development

[Locrian]

Floid's stretching a weekend programming project into something that it wasn't is a lie.

He never suggested any such thing. You're misrepresenting what he said.

 

[Locrian]

Don't lie, but emphasize the strong points and don't mention the weak points unless they specifically ask.

My emphasis. That's pretty clear.

 

[D H]

My emphasis. That's pretty clear.

Here's how I read what Floid said, this time with my emphasis, comments in parentheses mine:

3.) Spin and hype. Don't lie[/size], but emphasize the strong points and don't mention the weak points unless they specifically ask. You didn't do a weekend programming project, you created a program that performed statistical analysis on a database of historical stock data. And you didn't do it to learn to program, you did because you didn't like the tools available for free on the internet or because you thought you had some novel approach to stock analysis.

In other words, Don't lie[/size] (wink, wink) but do stretch the truth beyond the breaking point. That's a lie. You might not see it as such, but a potential employer will. And they will not hire you. 93% of managers do not hire a candidate if they think the candidate lied. http://www.careerbuilder.com/share/...ail.aspx?id=pr330&sd=10/17/2006&ed=12/31/2006.

Everyone embellishes to some extent. This is beyond embellishment. It is a lie. You might not look upon this kind of "spinning and hyping" as being a lie, but potential employers will see it as one. The odds are very much against the company hiring you if the interviewer does see it as a lie. I see the example at hand as a lie, and I have interpreted this kind of ultra-embellishment as a lie with candidates I have interviewed. And we did not hire those candidates.

 

[Floid]

I think the problem is with my use of the term "weekend project" which I was using more as a figure of speech indicating a project you did on your own and not for profit than to denote the actual time investment you had in the project.

If you look at two ideas I gave for sample projects both would actually take weeks of work to produce:

Examples:

Write a program that gets historical stock data from the internet and stores it into a SQL database. Then write a program that pulls it out of the SQL database and performs some kind of basic analysis on it. Make it variable so you can examine stock or group of stocks starting at any date, for any window length, or find any stock whose price or volume deviated more than 1 STD in a certain length of time, etc. ... Throw a GUI on it and plot if if you want GUI or maybe openGL development experience.

or

If you want something more mathematical, write a set of libraries using various numerical techniques to solve ODEs or PDEs. Figure out a way to use them and compare their results, processing efficiency, etc. Even better, compare the results with different compiler options or between different compilers/programming languages.

If someone did a reasonably good job at them then I would say they have at least an entry level understanding of programming and whatever tools they used to do them in. If you think someone who completed those projects is lying if they said they had a entry level understanding of the programming language/tools they used then we have a very different expectation level on what an entry level understanding is...

 

[D H]

If you want something more mathematical, write a set of libraries using various numerical techniques to solve ODEs or PDEs. Figure out a way to use them and compare their results, processing efficiency, etc. Even better, compare the results with different compiler options or between different compilers/programming languages.

The one page resume rule still applies to people fresh out of college, which is the subject of this thread. When you use that much space to describe something you've done, I'm going to poke at it when I interview you. I might even do something unexpected if you really pique my interest (and you have piqued my interest with that little blurb).

What I might do is ask some of the really nasty physics/math/programming questions that I typically reserve for the best candidates. I don't ask those nasty questions because I'm trying to trip you up. Everyone stumbles a bit on these. I want to see how you frame the problem, how you stumble, how you recover, what kinds of questions you ask back at me. If you can't even start framing the problem, now that's a real problem. It means that I completely misgauged you. It might well mean that you have crossed that fatal line that distinguishes embellishment from lying. Now I'm really going to poke at your little writeup.

Every interviewer has a personal concept of truth / embellishment / lie. Even crossing from truth to embellishment is a problem for some interviewers. Crossing from embellishment to lie is a huge problem for all. That you don't think you lied is irrelevant. All that counts is whether the interviewer thinks you did. If your interviewer thinks you lied, you're toast. You will not get the job. Something to keep in mind when you are writing that resume.

 

[TMFKAN64]

In some sense, it doesn't really matter how much spin and hype you apply. As soon as you say "I wrote a program that..." you've identified it as a weekend programming project. Commercial software really isn't written by anyone person any more.

I think you'd be much better off getting involved with any open source programming project. At least I know I'd be much more impressed by an applicant who had submitted code and/or bug fixes to such a project than one who only wrote a few programs on their own. Plus, this solves the problem of code samples, as you can point to the specific submissions you made.

 

[Mistake]

Open source projects are pretty intimidating for me. People who have been coding for years contribute to the project and I'm supposed to do something on their level? I'm just afraid my code won't be up to their standards. Yeah, I know that's all in my mind.

But in any case, where do I find some projects that would be easy to contribute to? Projects can be huge. I'd hate to spend a few weeks learning how the code works just to give up because it's too complicated for me to understand.

 

[TMFKAN64]

Yes, open source projects are big and intimidating and staffed by people who have far more experience than you do. That's exactly why being able to contribute to one would be such good experience!

I don't have any specific recommendations for projects. But generally speaking, I'd suggest to try to find a smaller project that interests you and has a publicly accessible bug database. Look over the open bugs, and try to pick one that you can reproduce at home. Once you've managed to reproduce it, debug it and produce a fix!

When dealing with a large amount of strange code, keep in mind that you don't have to understand *all* of it in order to make a contribution. Don't let the size of it intimidate you.

If you think this is beyond your ability, I'd simply ask you what do you think software development is, anyway?

 

[AlephZero]

But in any case, where do I find some projects that would be easy to contribute to? Projects can be huge. I'd hate to spend a few weeks learning how the code works just to give up because it's too complicated for me to understand.

The projects you can contribute most to are probably the ones that you already use. That way, at least you know what the app is supposed to do, and you probably already have some ideas about how to improve it.

You don't have to jump in at the deep end. On almost any software project, you could start by rewriting the some of the documentation so it makes more sense (or even any sense at all!). To do that, you will have to start reading the code to find out which parts of the documentation are just "spin and hype"...

Making "simple" contributions to open source projects is still useful, because it means the "project gurus" can spend less time doing the simple stuff, and more time being gurus. And once they notice you are contributing SOMETHING regularly, your questions about harder stuff will tend to get more of their attention.

 

[TMFKAN64]

The projects you can contribute most to are probably the ones that you already use. That way, at least you know what the app is supposed to do, and you probably already have some ideas about how to improve it.

You don't have to jump in at the deep end. On almost any software project, you could start by rewriting the some of the documentation so it makes more sense (or even any sense at all!). To do that, you will have to start reading the code to find out which parts of the documentation are just "spin and hype"...

Making "simple" contributions to open source projects is still useful, because it means the "project gurus" can spend less time doing the simple stuff, and more time being gurus. And once they notice you are contributing SOMETHING regularly, your questions about harder stuff will tend to get more of their attention.

This is a much better answer than mine. Documentation is something that *always* needs work and no one really wants to do!

 

[Mistake]

Sounds doable I guess. Only problem is this is something that can take months to do and I'd like a job now. Which is why I don't think software engineering is the right path. This is a pipedream. Hope I find a project I can contribute to, spend X amount of time on it hoping I actually make a worthwhile contribution, then hope potential employers actually care about it enough to interview me.

 

[StatGuy2000]

The one page resume rule still applies to people fresh out of college, which is the subject of this thread. When you use that much space to describe something you've done, I'm going to poke at it when I interview you. I might even do something unexpected if you really pique my interest (and you have piqued my interest with that little blurb).

What I might do is ask some of the really nasty physics/math/programming questions that I typically reserve for the best candidates. I don't ask those nasty questions because I'm trying to trip you up. Everyone stumbles a bit on these. I want to see how you frame the problem, how you stumble, how you recover, what kinds of questions you ask back at me. If you can't even start framing the problem, now that's a real problem. It means that I completely misgauged you. It might well mean that you have crossed that fatal line that distinguishes embellishment from lying. Now I'm really going to poke at your little writeup.

Every interviewer has a personal concept of truth / embellishment / lie. Even crossing from truth to embellishment is a problem for some interviewers. Crossing from embellishment to lie is a huge problem for all. That you don't think you lied is irrelevant. All that counts is whether the interviewer thinks you did. If your interviewer thinks you lied, you're toast. You will not get the job. Something to keep in mind when you are writing that resume.

Let me ask you something then. Suppose I am a proficient programmer with experience in say, MATLAB and C, but do not know how to program in SQL, for example. Now let's suppose that I want to learn to program in SQL because knowing how to do so will open up job opportunities. So I take the opportunity to go through the material online, write up programs, go through all the manuals and books, and I develop some code to do various things. Say, within a few months, I feel like I have a grasp on the basics of SQL.

According to you, should I include "proficient in SQL" in my resume? If not, what should I say about my knowledge in this language?

 

[coalquay404]

Let me ask you something then. Suppose I am a proficient programmer with experience in say, MATLAB and C, but do not know how to program in SQL, for example. Now let's suppose that I want to learn to program in SQL because knowing how to do so will open up job opportunities. So I take the opportunity to go through the material online, write up programs, go through all the manuals and books, and I develop some code to do various things. Say, within a few months, I feel like I have a grasp on the basics of SQL.

According to you, should I include "proficient in SQL" in my resume? If not, what should I say about my knowledge in this language?

D H will have his own take on this but I learned all the SQL I ever needed in the course of a day. That included a run through on relational algebras, projections, and the query language itself.

Unless you're actually designing databases you really don't need to know an awful lot of SQL to be productive.

 

[D H]

According to you, should I include "proficient in SQL" in my resume? If not, what should I say about my knowledge in this language?

I've learned SQL. Nonetheless, that knowledge never, ever, ever, ever goes on my resume. Sometimes a little knowledge is dangerous -- to your career, that is. Claiming knowledge of databases in the world of scientific programming is one of those "dangerous to your career" kinds of knowledge. I've seen what happens, multiple times, to people who claim to be "proficient in SQL". They no longer get to do anything related to scientific programming. Ever. Anything that is technically interesting: They aren't allowed to do that. That database knowledge is too important to waste.

 

[StatGuy2000]

I've learned SQL. Nonetheless, that knowledge never, ever, ever, ever goes on my resume. Sometimes a little knowledge is dangerous -- to your career, that is. Claiming knowledge of databases in the world of scientific programming is one of those "dangerous to your career" kinds of knowledge. I've seen what happens, multiple times, to people who claim to be "proficient in SQL". They no longer get to do anything related to scientific programming. Ever. Anything that is technically interesting: They aren't allowed to do that. That database knowledge is too important to waste.

You misunderstood the nature of my question. I was only using SQL as an example; I could have picked Java, C#, Python, Simula or any other programming language.

The point of my question was if I had studied programming language X on my own (but without any courses in school, certification or practical work experience), should I include my proficiency in the language in my resume or CV (you had argued previously that putting "proficiency in programming language X by developing Y project" would be lying if this amounted to self-study and self-developed project). If so, what should I state in my resume.

 

[twofish-quant]

This is very bad advice. Spinning and hyping a weekend programming project as a significant endeavor is a lie.

One thing that I've found with some interviewees is that *understating* your expertise can be just as bad as overstating it.

Sometimes a weekend project is a significant endeavor. What's really impressive is if someone other that you uses the project, or if the weekend project is part of an general open source routine. If you do some weekend projects writing device drivers for linux that make it into the kernel, that's worth talking about since that means that Linus Torvalds has signed off on your code.

Also, if it's something that people can download from sourceforge, that's also useful. If someone tells me that they are an expert programmer, I have to take their word for it. If I can download their code from sourceforge, I can see for myself.

Never lie on a resume or during an interview, and that includes excessive stretching of the truth. If you are going to lie about something as petty as a weekend programming project, what are you going to lie about when it comes to something significant?

On the other hand, we've hired several people on the basis of weekend projects (including me). The thing about those projects is that the code was available online, and if you want to see my skill as a C++ programmer, I can point you to several websites where you can see for yourself.

 

[twofish-quant]

Suppose even one person detected that that claimed experience in programming and statistics was a merely weekend project to learn how to program and how to do statistics.

On the other had if said candidate was the author of several very complicated bits of mathematics in an open source package, that's impressive. If the author has no formal training in statistics, that's even more impressive.

One thing that makes the type of programming we do amenable to "weekend projects" is that often the type of programming that we do involves one or two day bug fixes to a larger system. If you've debugged and tracked down bugs in the linux kernel, that's the skill set we want.

The other thing is that if you've participated in any large open source project, that means that you can work with other people, which is also a useful skill.

 

[twofish-quant]

Everyone embellishes to some extent. This is beyond embellishment. It is a lie. You might not look upon this kind of "spinning and hyping" as being a lie, but potential employers will see it as one.

Whether it's a lie or not depends the underlying reality of the situation. If you go to a Wall Street interview, and you talk about your stock analysis program, then you are putting a big sign on yourself saying "crush me with questions on stock analysis." At that point you are going to be grilled with questions about sharpe ratios, VaR, transaction costs, no-arbitrage theorems, GARCH models etc. etc. Can you write five lines of code that tests for zero-root processes? Let's talk about market microstructure, can you tell me off the top of your head the margin rules for the NYSE? Tell me how the order book works.

The cool thing is that if you've done your homework, then you may seriously impress the interviewer. Wall Street loves people that are self-taught. If you write a stock analysis program and you can talk about the Markowitz model, then this is great!

As far as spin and hype. Do you best to spin and hype me. We'll see if you are good at it. Spin and hype aren't necessarily bad things. If you don't mention that you've done stock analysis in your resume, then I won't be able to grill you about GARCH models. If you spill and hype me and you have no idea who Markowitz is, then you've just wasted my time and yours.

One thing about spin is that it's a skill. If you know *nothing* about stock markets, but you can convince an expert that you do. If you manage to convince me that you are a C++ expert but you know nothing, then I'll very strongly recommend that you be hired, on the basis of your acting skills.

However, even at "spin and hype" you probably aren't that good, because if you are trying to get a job on Wall Street on the basis of your ability to BS, then we'll bring in our world class BS'er to grill you to see how good you are at that.

 

[D H]

Whether it's a lie or not depends the underlying reality of the situation. If you go to a Wall Street interview, and you talk about your stock analysis program, then you are putting a big sign on yourself saying "crush me with questions on stock analysis."

Exactly. When you boast about something in a resume, be prepared to be grilled about it. If it turns out to be all spin and hype, but nothing's there, no job.

You work in a very small niche of the programming world, twofish, a world that lives and breathes spin and hype. You guys might even relish spin and hype on a resume. Don't take your narrow view of how your small corner of the world works as exemplary of how things work outside of Wall Street. Excessive spin and hype on a resume are not appreciated elsewhere. Almost everyone embellishes their resumes to some extent. There's a line where embellishment becomes a lie, and that line is one that in general should not be crossed. Outside of Wall Street, that is.

 

[twofish-quant]

You guys might even relish spin and hype on a resume. Don't take your narrow view of how your small corner of the world works as exemplary of how things work outside of Wall Street.

Sure, but then this gets to the issue of communications. Different words have different meanings in different places. Where I work "spin" and "hype" are considered *good* things. If you are dishonest, then the spin doesn't work, so that's considered bad spin.

Also this isn't just Wall Street, pretty much every job that involves sales and marketing has this things.

Honesty and integrity are extremely important in finance. The best spill and hype is that which is backed up by facts.

Excessive spin and hype on a resume are not appreciated elsewhere. Almost everyone embellishes their resumes to some extent. There's a line where embellishment becomes a lie, and that line is one that in general should not be crossed. Outside of Wall Street, that is.

In fact, it's a *bad* idea to embellish your resume. Even a little. People forget the purpose of the resume is not to get the job, but to get an interview. If you embellish the resume, and you get an interview for a job that you won't get in the end, this is a *BAD* thing because you are wasting time interviewing for jobs that you won't get.

It's also *bad* to embellish your resume since that focuses the interview on things that you are bad at. For example, if I were to write a resume, I'd like to mention a lot about neutrino diffusion and not on stock analysis. The reason for this is that if they bring out the world expert on radiation hydrodynamics and we talk for an hour on Boltzmann methods, I'll shine. If I mention stock analysis, then they will bring out the world's expert on stock analysis, and I'll get killed. The questions that I was talking about were kindergarten ones.

Finally, one of the biggest problems for physics Ph.D.'s is overqualifications. There are many times in which you want to deliberately *understate* your qualifications, because stating them in full gets you killed.

 

[twofish-quant]

The point of my question was if I had studied programming language X on my own (but without any courses in school, certification or practical work experience), should I include my proficiency in the language in my resume or CV (you had argued previously that putting "proficiency in programming language X by developing Y project" would be lying if this amounted to self-study and self-developed project). If so, what should I state in my resume.

Just say that you developed Y project, and go into specifics. How many lines of code? How many users? What was the size of the team? How long did you spend on it? Give me URL so that I can download it.

Project based metrics, means *more* than certifications. Computer certifications are completely useless, and degrees are only useful as an initial filter. No one cares how many classes you took. What people want is for you to **show** that you do something useful. Trying to *demonstrate* something is what "hype" and "spill" means in my world.

There's a difference between "I play chess" and "I have a ELO rating of 2300 and have competed as a national chessmaster." However, if you say something like that, don't be surprised if someone shows up to the interview with a chessboard. I know people that have gotten interviews because they mentioned that they were marathon runners or champion video game players.

Finally, don't try to please everyone. You only need one job.

 

[twofish-quant]

What I might do is ask some of the really nasty physics/math/programming questions that I typically reserve for the best candidates. I don't ask those nasty questions because I'm trying to trip you up.

I **am** trying to trip you up with nasty questions. Part of the purpose of the interview is to see how you behave when you are working at the limits of your knowledge and how you react under stress. I will make up questions that I do not know the answer to, or maybe that no one knows the answer to, in order to see how you react.

The reason for this is that I'm trying to avoid "cookbook" interviews. You have tons of books out that that tell you the "right" answer to an interview question. What I'm trying to do is to trip you up so that you can't answer the questions via rote memorization. If you know what a "virtual function" is, I'll start asking questions about functors and template metaprogramming. You can memorize in one minute "what is a virtual function?" so I'm trying to make you uncomfortable so that you really *know* what a virtual function is. Can you put a virtual function in a template?

If you can't even start framing the problem, now that's a real problem. It means that I completely misgauged you.

It could mean that you also behave badly under stress. I'll then pull back and see if that's the problem or if you really don't know anything. If you really don't know anything, then it's a waste of time to ask more questions, so I'll start fishing for something that you are good at.

All that counts is whether the interviewer thinks you did. If your interviewer thinks you lied, you're toast. You will not get the job. Something to keep in mind when you are writing that resume.

Where I work, it's unlikely that you can get as far as an interview if you outright lie. Before you get to the interview, there are some written tests and a phone screen, and if you really have no skills, you aren't getting past those.

 

[twofish-quant]

Open source projects are pretty intimidating for me. People who have been coding for years contribute to the project and I'm supposed to do something on their level? I'm just afraid my code won't be up to their standards. Yeah, I know that's all in my mind.

Yup. But think of this as practice for the "real world." You are going to be interviewing for a job in which you are working with people who have been coding for years, and you are supposed to do something on their level. If you have a psychological block to this, then it's something that you have to deal with in before the interview.

But in any case, where do I find some projects that would be easy to contribute to?

sourceforge and freshmeat. Also finding a project that you can contribute to is also part of your education. There are some teams that are *nice*. There are some teams that are *nasty*, find a team that is nice.

Projects can be huge. I'd hate to spend a few weeks learning how the code works just to give up because it's too complicated for me to understand.

Well that's part of your education. Look on the bright side. On an open source project, if you get totally over your head, you can just give up and no one will know or care.

You won't have that option when someone pays you for real...

It's pretty common where I work for someone to dump code that you haven't ever seen, and you are expected to do something in hours. One thing that I've gotten paid for is to be an "emergency room code surgeon."

 

[twofish-quant]

According to you, should I include "proficient in SQL" in my resume? If not, what should I say about my knowledge in this language?

I think that you are asking the wrong question, because the way that you are structuring your resume will make you look very inexperienced. People with little programming experience worry too much about particular languages, and if you are "language-focused" then that means that aren't a good programmer at all.

The situation is as follows:

1) don't learn SQL, learn database theory. Knowing SQL is useless. Knowing how databases work is *extremely* valuable, but it's also very uncommon and very difficult. Learn relational database theory, locking, commits, deadlock, data normalization, keys, indices, hashing, btrees, etc.

2) if it takes you several months to learn SQL, then I can't hire you. You should have enough programming competence so that you can figure out how to write SQL in two to three days. The reason for this is that it's unlikely that you will be programming directly in SQL. You will be programming in two or three random and undocumented languages that probably don't exist outside our company. It should take you at most a week to figure out those languages.

3) Don't say I know database theory. Say "I've done this." Also be realistic. You are *NOT* going to be an expert database programmer in six months, so we can't hire you to be a Oracle guru DBA. With six months, it's possible that you've created a PHP application with a MySQL backend that your bridge club uses to track tournaments, and if you can talk sensibly about how you created the data model. That looks good. I'll ask you about your data model, and how you handle locking and concurrency. If you can give me sensible answers, then that's excellent.

Also if you are writing your own database application for the first time, you are going to do something seriously, seriously stupid. That's good. I'll ask you what stupid thing that you did, and it will be good that you did that stupid thing on your time and not company time.

4) Don't get in over your head. If someone asks you to be a senior database guru for a police department or hospital, say no. If you get it wrong, someone is going to die. You might be qualified as a "code monkey" for those positions.

I've had one or two people offer me interviews for jobs that I knew I was totally unqualified for, and I turned them down because if they were asking me to do something, they were obviously incompetent employers.

 

[twofish-quant]

This is a much better answer than mine. Documentation is something that *always* needs work and no one really wants to do!

Which means that there are a lot of jobs for technical writers. I know more than a few science fiction writers whose day job is technical writing.

 

[twofish-quant]

Exactly. When you boast about something in a resume, be prepared to be grilled about it. If it turns out to be all spin and hype, but nothing's there, no job.

However, I don't see why we should assume that this is not the situation. Part of it is that we've hired enough people who have demonstrated *extremely impressive* amounts of knowledge based on weekend projects. If you put a stock market statistics program on your resume, prepared to be grilled to death on it, however, more often than not, people that put this sort of thing in their reason turn out to be *extremely* knowledgeable. It's not uncommon that we have an interviewee, I ask them a few questions, and it turns out that he or she knows more about the topic than I do.

If nothing else, the fact that you did something without being asked shows initiative, which is a good thing.

You work in a very small niche of the programming world, twofish, a world that lives and breathes spin and hype.

I've worked off Wall Street. Spin and hype are part of any high technology company that I've seen, and no spin+no hype = no sale. The *WORLD* breathes spin and hype.

But spin and hype has to be based on reality. Look at the iPhone. It was massively hyped as being easy to use and fashionable and guess what... It *is* easy to use and fashionable.

Almost everyone embellishes their resumes to some extent. There's a line where embellishment becomes a lie, and that line is one that in general should not be crossed. Outside of Wall Street, that is.

I still have no idea why you think that the OP is embellishing or even lying. He says

You didn't do a weekend programming project, you created a program that performed statistical analysis on a database of historical stock data. And you didn't do it to learn to program, you did because you didn't like the tools available for free on the internet or because you thought you had some novel approach to stock analysis.

There are lots of different ways of describing something, and part of marketing in any company is to figure out how to describe something *truthfully*.

If you take a package and label it "dead animal parts" you aren't going to make the sale. If you label it "grade A steak" when in fact it *is* "grade A steak" that's a good thing, and it's a bad thing if you "dead animal parts." If I don't put on my resume the fact that I take may clothes off when I shower, I'm not lying. If I do put on my resume, that I'm slight fat, people wonder why I'm mentioning that.

When done well, "spin", "hype", and "marketing" makes things *more* truthful, not less. The recruiter hypes someone as a mathematical genius, and guess what? He is.

 

[chiro]

I like the way two-fish is describing the process for the interview (and I assume they have a good filtering out process before this stage).

One thing that I have noticed in my limited experience (in the past) was that getting in a situation where you are just dumped a tonne of code and asked to do something relatively quickly is pretty much a good test of how you will do since this is what happens anyway.

So the weekend project is actually a good indicator of being able to at least handle these situations and show not only what you did but what you got out of it and what you learned.

Also I get a feeling that a lot of people who call themselves "programmers" (and apply for jobs) really underestimate the actual screwing around that it takes to just get to the level where you jump in and can suck up the information to be able to do what you need to do very quickly.

It took me personally many many years after being introduced to programming (for me this was at the start of high school or what the US call junior high: I'm basing this off the TV show degrassi junior high).

Most of the time was spent watching everything crash again and again and again. Then at some point things started to become highly organized mentally and I knew what to look for, and could decipher the code for what it was and not for what it "says".

I can't really see how it's possible to really do dev work without spending many years and more time than what you would spend in university learning to code. If you don't do a lot of those weekend projects, the screwing around with your own projects or with other code, on top of all the really over-simplified assignments in uni (yes that's what I think of them) then I can't really see how you could develop code for a living.

To me 3 or 4 years is too short to become the kind of developer that is expected nowadays due to so many things attributed to the realities of modern software development: it's just way too short IMO.

 

[Dickfore]

I just want to say that there are undergraduate programs in Computational Physics, which DO give a solid foundation in programming and knowledge in hardware.

And one more thing, by the same token EE majors have equally bad preparation in programing, but you still see these degrees advertised for their job opportunities as a programmer even more so than physics, or math majors. And, companies even hire more of them as well (maybe it's because of the sheer discrepancy in the number of candidates).

Finally, I never knew there was a "programming major". If a company requires someone with a knowledge in SQL, they may even hire a high school graduate if they know it.


/troll

 

[StatGuy2000]

It took me personally many many years after being introduced to programming (for me this was at the start of high school or what the US call junior high: I'm basing this off the TV show degrassi junior high).

This is off-topic, but I just wanted to let you know that Degrassi Junior High is a Canadian TV show, set in Toronto!

(in fact, a few of my friends grew up on the very streets where the show was filmed)

 

[D H]

I just want to say that there are undergraduate programs in Computational Physics, which DO give a solid foundation in programming and knowledge in hardware.

And one more thing, by the same token EE majors have equally bad preparation in programing, but you still see these degrees advertised for their job opportunities as a programmer even more so than physics, or math majors. And, companies even hire more of them as well (maybe it's because of the sheer discrepancy in the number of candidates).

Back on topic!

The following is based solely on my experience, so take it with a grain of salt. The reason that physics majors, EEs, aerospace engineers, et al are hired to do what is essentially a programming job (but with a strong scientific/mathematical/engineering flavor) is that as bad as they are at programming, the typical computer science major is even worse when it comes to scientific programming. Engineers, and maybe scientists, can be taught to program well, or at least to recognize why their programs aren't so good. The engineering principles that distinguish a good system design from a bad one also apply to software. A good chunk of CS majors took that route specifically so they would never have to take another math class again. They don't grok filters and noise, ODEs and PDEs; a lot of them don't grok and can't grok F=ma.

 

[Mistake]

Isn't a CS program heavily math dependent, but more so on the proof side?

 

[jedishrfu]

Unless its changed much in the past few years, I don't recall ever doing proofs in CS. I do recall some heavy abstract math in compiler design theory but not proofs per se.

They used to teach program correctness techniques that bordered on proving the correctness of an algorithm not sure if that's still an important topic among other more important topics.

 

[Pythagorean]

Discrete mathematics was required for our CS majors. Which included proof by induction, but I don't think full blown proof were required.

 

[twofish-quant]

Also I get a feeling that a lot of people who call themselves "programmers" (and apply for jobs) really underestimate the actual screwing around that it takes to just get to the level where you jump in and can suck up the information to be able to do what you need to do very quickly.

This is another example of "spin" and "marketing." When I apply for jobs, I often specifically avoid calling myself a "computer programmer" since a "programmer" implies shoveling code and getting your job sent to India. "Software developer" is a better term and for finance "quantitative analyst" and "quantitative developer" are the preferred terms. "Scientific programmer" is also possible, but in a lot of the jobs that I apply for "scientific" is bad.

There's actually a point in this sort of spin. One reason that "programmer" has a bad connotation in the type of work that I've done is that people without too much computer ability use it it describe themselves, and avoiding using that term is something of a "hidden code" saying "I know enough about the industry to avoid using this term to describe myself."
Of course, if people with little ability break the code and start using "software developer" then that will cause that term to go bad, and people will find something else.

It works the other way. Since "programmer" means "crap job", people selling the jobs don't advertise for "programmers" in finance, the advertise for something with the word "quantitative" in it. Since that's "cool". But increasingly "crap jobs" are being labelled with
"quantitative" that's caused that term to go down in value.

This is an example of "honest spin." The person reading you resume is looking at it for five seconds. What are the three to five words that you want him to see that *accurately* and *truthfully* describes yourself. I'm not a "theoretical astrophysicist" I'm a "computational astrophysicist." There is a *big* difference when it comes to writing a resume. Companies (for good reason), hate people that are "theoretical."

I can't really see how it's possible to really do dev work without spending many years and more time than what you would spend in university learning to code.

Yes, but lots of people have that sort of experience without going taking any formal classes at the university, and lots of people that go to university are terrible coders. One thing that going to university gives you is *free time*.

If you don't do a lot of those weekend projects, the screwing around with your own projects or with other code, on top of all the really over-simplified assignments in uni (yes that's what I think of them) then I can't really see how you could develop code for a living.

And it's a moving target. One reason I'm very positive toward people who do weekend projects is that I still spend a large amount of my weekend doing projects. I *have* to do it because there is ton of technology coming down the pipe. I've programmed C++
for 20 years, and I'm "still" a student, because I'm playing with C++11 and GPU's.

To me 3 or 4 years is too short to become the kind of developer that is expected nowadays due to so many things attributed to the realities of modern software development: it's just way too short IMO.

The good news is that there are tons and tons of jobs that someone with minimal computer
training can do. The bad news is that they are all in Mumbai and Shenzhen. If a US
company needs some "basic coding" done, they aren't going to hire someone local, they are
going to ship the job off to Mumbai, and the wages there are a fraction of what they are in the US.

The jobs that stay on-shore are "emergency open heart surgery" type jobs. Some that is a
database guru for example can make hundreds of dollars an hour, but you need years maybe decades of experience for that sort of thing.

In the late-1990's people were saying that it was OK for "basic low level" jobs to go to China and India as long as the "high value" jobs stay in the US. The trouble with that plan is that if you don't have basic low level jobs around, then there is no way of training people for the "high value" jobs.

 

[twofish-quant]

Isn't a CS program heavily math dependent, but more so on the proof side?

A lot depends on the school. One thing that was an important part of my education was that the CS department in my undergraduate school was part of the electrical engineering department, which meant it had a "practical" aspect. One other important part is that my undergraduate education put a lot of emphasis on the *business* aspects of CS. There were no formal classes, but pretty much every professor was trying to start their own company, and just listening to your professor talk about how to get VC funding and management headaches was educational. You also had professors and alumni that started multi-billion dollar companies, and hearing them talk about how than did that was educational.

Also, I ended up in charge of a student government committee, and I had to manage personnel and a budget, and go begging to Deans for money. It's amazing how much of life involves begging for money.

The philosophy of my undergraduate school was that they weren't trying to teach "pure technicians" but rather "technical entrepreneurs" and "technical managers." To do this, you have to know more than programming, you have to understand business.

My graduate school experiences reinforced this. One reason I have respect for spin and hype is that I got to see one of the masters of spin and hype in action in my graduate school. There was one professor in particular that was an "astrophysicist salesman" and part of his job was to go to Congress and the state legislature, and spin and hype physics so that we'd get money.

Astrophysics has the ultimate in *hype* (For just $2 billion, we discover what created the universe, get lots of pretty pictures, and also generate jobs in your district so that you get reelected.) The fact that the spin-master and hype-master is also a world class physicist (i.e. he has a Nobel prize) made him more amazing to watch, and makes him a more effective "salesman." If I call a Congressman to lobby for more science funding, he isn't going to talk to me personally. If he calls and wants a meeting he can wave his Nobel prize and get that meeting.

You win some. You lose some. The big loss was the SSC. The big win was COBE, Hubble, and WMAP.

And he was just part of a department that put a lot of emphasis on business. Watching the process of space probes get funded (or not funded) was part of my education. Making sure that you have *pretty pictures* is part of the hype. The spin is "jobs, jobs, jobs."

Getting back to the OP. The way that physics is taught is different from place to place, but it turns out that my education in which the politics and business of science was taught along with the differential equations was excellent preparation. I remember how the "astrophysics salesman" prepared for his interviews with Congress people, and that gave me some starting points for how to prepare for mine.

 

[zapz]

Getting back to the OP. The way that physics is taught is different from place to place, but it turns out that my education in which the politics and business of science was taught along with the differential equations was excellent preparation. I remember how the "astrophysics salesman" prepared for his interviews with Congress people, and that gave me some starting points for how to prepare for mine.

Any quick tips or tricks of the trade you wouldn't mind sharing? My school has a (seemingly) similar type atmosphere as your undergrad in regards to the "technical entrepreneur" side, so I'm curious to some of the things that were highlighted for you.

 

[Best Pokemon]

This is another example of "spin" and "marketing." When I apply for jobs, I often specifically avoid calling myself a "computer programmer" since a "programmer" implies shoveling code and getting your job sent to India. "Software developer" is a better term and for finance "quantitative analyst" and "quantitative developer" are the preferred terms. "Scientific programmer" is also possible, but in a lot of the jobs that I apply for "scientific" is bad.

I look at threads on QuantNet and it seems a financial programmer is actually a different job than a quantitative analyst or a quantitative developer.

https://www.quantnet.com/search/1412652/?q=%22financial+programmer%22&o=date

http://www.google.com/#hl=en&output...4bd4d4b7cce50b&bpcl=35466521&biw=1366&bih=645

 

[chill_factor]

Back on topic!

The following is based solely on my experience, so take it with a grain of salt. The reason that physics majors, EEs, aerospace engineers, et al are hired to do what is essentially a programming job (but with a strong scientific/mathematical/engineering flavor) is that as bad as they are at programming, the typical computer science major is even worse when it comes to scientific programming. Engineers, and maybe scientists, can be taught to program well, or at least to recognize why their programs aren't so good. The engineering principles that distinguish a good system design from a bad one also apply to software. A good chunk of CS majors took that route specifically so they would never have to take another math class again. They don't grok filters and noise, ODEs and PDEs; a lot of them don't grok and can't grok F=ma.

I'm a physics grad student and I hit a brick wall in C programming in undergrad multiple times. That's why I do experiment. At least it will give me useful hands on skills with commercial materials instrumentation, designing and building basic circuits and using software packages like Matlab, Labviews, etc. rather than keep slamming into a brick wall programming.

When physicists say that they are good programmers, what they really mean is: I'm very smart and learned how to program myself. They do not mean that a BS (or even a PHD) Physics trains you to be a programmer. Like twofish said, what professors say is "oh, we have no clue what you can do with your degree, but uh, you're smart because you passed, so you'll think of something."

Well turns out that the majority of people are not smart enough to figure it out. We need guidance. We need help. We need to be specifically trained. But programming, and programming well, not the 1 file 1000 lines of mostly redundant numerical code style, is not part of the specific training.

 

[jkl71]

When physicists say that they are good programmers, what they really mean is: I'm very smart and learned how to program myself. They do not mean that a BS (or even a PHD) Physics trains you to be a programmer.

I agree that’s the expectation. Even being fairly experienced, every job I’ve had has involved a lot of learning on the fly. From my perspective the biggest challenges in writing software are understanding the business objectives and how to build a model to achieve them, understanding frameworks and libraries that are available, and figuring out poorly designed/implemented legacy code. Two of the three of these are substantially different at every development shop.

I never did any programming related to physics, so I can’t say how useful it is as a background for software development.

I do have some speculation why physics might be as useful (although I don’t believe either it or computer science is as useful as actual experience working on a real project). One thing I do think physics could be useful for is that a large part of physics is building mathematical models of the natural world, to me this is analogous to building software models of a business. However, I can’t say whether it’s just a common set of skills that make someone more likely to be good at physics and software, or the experience in doing physics substantially helps in developing these skills.

I’d expect getting your foot in the door without any professional experience is fairly hard these days, other people have offered far better advice on that than I could. Learning to program well is in large part a state of mind, being committed to doing quality work and having good attention to detail. One book that helped me when I first got started was “Code Complete” by Steve McConnell, I found the advice to be very useful (I was truly starting from zero).

 

[chill_factor]

I do have some speculation why physics might be as useful (although I don’t believe either it or computer science is as useful as actual experience working on a real project). One thing I do think physics could be useful for is that a large part of physics is building mathematical models of the natural world, to me this is analogous to building software models of a business. However, I can’t say whether it’s just a common set of skills that make someone more likely to be good at physics and software, or the experience in doing physics substantially helps in developing these skills.

Mathematical models for the natural world. True. I use Matlab for that. That is far different from programming something from scratch on C. The whole thing about "oh its just mathematical modeling"... no its not. There's a type of "programming logic", not just math, that goes into it. Some people can handle the math concepts and even do some numerical stuff on Matlab or Mathematica but can't handle the "programming logic".

 

[elkement]

Back on topic!

The following is based solely on my experience, so take it with a grain of salt. The reason that physics majors, EEs, aerospace engineers, et al are hired to do what is essentially a programming job (but with a strong scientific/mathematical/engineering flavor) is that as bad as they are at programming, the typical computer science major is even worse when it comes to scientific programming. Engineers, and maybe scientists, can be taught to program well, or at least to recognize why their programs aren't so good. The engineering principles that distinguish a good system design from a bad one also apply to software. A good chunk of CS majors took that route specifically so they would never have to take another math class again. They don't grok filters and noise, ODEs and PDEs; a lot of them don't grok and can't grok F=ma.

I agree - I have been told that nearly literally by Siemens many years ago: We rather can train physicists to become programmers, but the CS majors cannot be trained the physics / engineering basics. This was illustrated by: They will never get how a transistor really works.

 

[Mépris]

Chill_factor raises a fair point. Not everyone wants, or indeed can, be "entrepreneurial" with their physics degree. In fact, I'm willing to bet that most people would prefer a clear-cut path! Do X, do Y, this will lead to B-lambda. After that do Q2, and voila. You're set.

(or something)

Not everyone finds living in uncertainty and stress exciting!

I just want to say that there are undergraduate programs in Computational Physics, which DO give a solid foundation in programming and knowledge in hardware.

http://www.kenyon.edu/scientificcomputing.xml

 

[chiro]

Mathematical models for the natural world. True. I use Matlab for that. That is far different from programming something from scratch on C. The whole thing about "oh its just mathematical modeling"... no its not. There's a type of "programming logic", not just math, that goes into it. Some people can handle the math concepts and even do some numerical stuff on Matlab or Mathematica but can't handle the "programming logic".

Just for those who think chill_factor is fibbing:

If you look at some of the complex platforms out there that have all these crazy macro's, templates, build scripts, and a whole plethora of meta-data, interface definitions and so on, you'll see how different the environment is to software development as opposed to the environment of say MATLAB or Mathematica.

 

[jkl71]

Mathematical models for the natural world. True. I use Matlab for that. That is far different from programming something from scratch on C. The whole thing about "oh its just mathematical modeling"... no its not. There's a type of "programming logic", not just math, that goes into it. Some people can handle the math concepts and even do some numerical stuff on Matlab or Mathematica but can't handle the "programming logic".

The analogy I had in mind wasn't really about doing math with software, it was more along the lines of building an object model of a business process or perhaps a biological system.

 

[Dembadon]

I agree - I have been told that nearly literally by Siemens many years ago: We rather can train physicists to become programmers, but the CS majors cannot be trained the physics / engineering basics. This was illustrated by: They will never get how a transistor really works.

The title of the thread does not refer to programmers; it refers to software development, which is something completely different. Anyone can learn the syntax of a language and write trivial programs for computational purposes (i.e. become programmers). However, reading through an O'Reilly book on C++ isn't going to teach you how to build an operating system from scratch.

In other words, programmer is to software developer as electrician is to electrical engineer. One is a trade, the other a profession.

Moreover, it is intellectually naive to suggest that CS programs don't teach engineering basics. CS at my university requires three semesters of physics (the first two are from the standard US sequence, while the third is focused on developing programs that act as models of the physical world), 1 in electronics, and 1 in circuits. The computer engineering requirements have lab and lecture components that are largely hardware oriented.

 

[coalquay404]

Someone once said that 90% of software development consists of searches and sorts. Assuming that to be true (and ignoring the remaining 10%, which is actually a quite important 10%), a typical physics degree isn't going to teach you how to search and sort data to any acceptable degree.

Sure, you might get some basic C or C++ experience out of it, but were you exposed to the appropriate data structures and algorithms? Even assuming that you touched on binary search trees, is that going to be good enough when your new employer expects you to implement, say, a limit order book for an electronic market? Did your physics degree teach you that the appropriate structure in this case is a self-balancing tree? Can you implement a balanced tree in C++? Can you analyse the theoretical cost of each operation? Are you capable of comparing the theoretical performance with the real-world performance when your limit order book is connected to a NASDAQ ITCH feed and thousands of orders are added each second? Do you know enough about TCP/IP to be able even to connect your application to a market feed?

Software engineering is hard. A typical physics degree isn't going to provide you with the tools to be successful at it.

 

[elkement]

The title of the thread does not refer to programmers; it refers to software development, which is something completely different.

I could not agree more - I have worked in the IT industry for many years. I picked the term programmer because the posting by D_H referred to

... physics majors, EEs, aerospace engineers, et al are hired to do what is essentially a programming job (but with a strong scientific/mathematical/engineering flavor)...

and the Siemens jobs I referred to were programming jobs with an eng. flavor.

As I said in an earlier in this thread, this has changed over the past 15-20 years. When I entered the IT world my impression was that only a minority of my colleagues actually had a CS or any IT related degree or training at all - IT was a sector that was particularly open to people with uncommon CVs. Anybody from zoologist to philologist (genuine examples) could become a computer expert, developer, programmer, architect.

I guess this was simply a matter of supply and demand of trained computer scientists. Many self-educated developers or IT professionals I know went back to school later and worked towards a CS degree while employed full-time.

I do not at all underestimate the value of a CS degree.

 

[Dembadon]

I could not agree more - I have worked in the IT industry for many years. I picked the term programmer because the posting by D_H referred to



and the Siemens jobs I referred to were programming jobs with an eng. flavor.

As I said in an earlier in this thread, this has changed over the past 15-20 years. When I entered the IT world my impression was that only a minority of my colleagues actually had a CS or any IT related degree or training at all - IT was a sector that was particularly open to people with uncommon CVs. Anybody from zoologist to philologist (genuine examples) could become a computer expert, developer, programmer, architect.

I guess this was simply a matter of supply and demand of trained computer scientists. Many self-educated developers or IT professionals I know went back to school later and worked towards a CS degree while employed full-time.

I do not at all underestimate the value of a CS degree.

I should have read the thread before posting, something I normally make a point to do; my apologies for misrepresenting your position.

 

[elkement]

I should have read the thread before posting, something I normally make a point to do; my apologies for misrepresenting your position.

No problem at all - my last posting was a bit short, I should have also phrased it more carefully (that I quoted Siemens basically).

Thinking more about the long-term development of the IT pro / dev job market I sometimes wonder if the problems with older legacy systems stem from the fact that they have been once setup by all kinds of weird career changers ;-)

 

[D H]

The title of the thread does not refer to programmers; it refers to software development, which is something completely different.

It refers in particular to whether a physics major is good preparation for a career in software development. Software development is a big, nebulous term. Does it prepare you for developing a massive transaction based system that uses a number of different processes written in multiple programming languages and that needs to be extremely reliable? No. Does it prepare you for developing a massive system that simulates the weather, the performance of a new physical device, or rockets in space? That's a different question. Does it prepare you for developing a game with a significant physics engine? That, too, is a different question than that transaction-based system.

Moreover, it is intellectually naive to suggest that CS programs don't teach engineering basics. CS at my university requires three semesters of physics (the first two are from the standard US sequence, while the third is focused on developing programs that act as models of the physical world), 1 in electronics, and 1 in circuits.

That's not common. I just picked three schools off the top of my head, the University of Texas at Austin, the University of Maryland at College Park, and the University of Massachusetts at Amherst. Maybe one math class beyond freshman calculus and six to eight semester hours of science, any science. Biology and physics for poets, for example.

Someone once said that 90% of software development consists of searches and sorts. Assuming that to be true (and ignoring the remaining 10%, which is actually a quite important 10%), a typical physics degree isn't going to teach you how to search and sort data to any acceptable degree.

For a typical science-based application it's the other way around. Only a tiny, tiny percent of scientific software involves searches and sorts. Most of the software involves mathematical models of some sort.

Mathematical models for the natural world. True. I use Matlab for that. That is far different from programming something from scratch on C. The whole thing about "oh its just mathematical modeling"... no its not. There's a type of "programming logic", not just math, that goes into it. Some people can handle the math concepts and even do some numerical stuff on Matlab or Mathematica but can't handle the "programming logic".

Yep. One of the concepts that I've found is hardest to teach engineers and scientists is that a statement such as is_ok = x<y; (a) is valid, (b) makes sense, and (c) can be very useful. The things you put inside an if test can be variables? And its best to not even start talking about things such as preconditions, postconditions, and invariants. Concepts such as cohesiveness, coupling, fan in and fan out, and complexity are also hard to get across.

Software development, science, and engineering require very different modes of thinking, different world views. Someone who can bridge those different world views and do so while avoiding the "jack of all trades, master of none" problem is rare -- and worth a whole lot.