(On July 16, 2009, I asked for volunteers with science degrees and non-academic jobs who would be willing to be interviewed about their careers paths, with the goal of providing young scientists with more information about career options beyond the pursuit of a tenure-track faculty job that is too often assumed as a default. This post is one of those interviews, giving the responses of Tim Johnson, a software engineer.)
1) What is your non-academic job?
In a nutshell, software engineering. Started off with C/C++, TCL/TK, and a sprinkling of perl. For the last few years, it has been Java coding. Specifically started this last job with a distributed computing project on Unix, and currently working with frameworks such as Spring, JMX, etc. to write middleware frameworks (and plumbing) to support multiple products via web access for another project.
2) What is your science background?
B.S. and M.S. in physics.
Ph.D. Experimental nuclear physics from Florida State University.
3) What led you to this job?
While doing my second postdoc, I was covering the bases by applying to both academic and industrial positions. The academic market was very tight. One specific case I knew about had about 400 applicants for one position and it had gone to a fairly well known figure. The number of applicants/position at the time struck me as fairly typical. Somehow, I landed an interview for a software development position for a project that the employers were already behind schedule on ramping up for the project which was starting 2 weeks from my interview. I got the offer during the interview. After flying back and considering it for a couple of days, I decided to give it a try and see what it was like outside academia. A company move and layoff (telecom bust) later, another interview landed me where I am now.
4) What's your work environment like?
Office. Unfortunately, the cube farm is usually the norm. Our company has 1 person per cube, with completely open "doorway". I could go on about how this is exactly the wrong environment to encourage productivity for developers. As per the work environment itself, that has varied tremendously from project to project and team to team. In addition, each company has its own sense of culture. Working at Google would be a much different environment than Raytheon, for example. Which more or less sequeys nicely into the question.
5) What do you do in a typical day?
For a good project, like my first one at this company, it would be something like this: Get in somewhere between 8 and 9. Shoot the bull for a little bit. Design meetings/ discussion for new stuff. Take care of email. Write code, write code, write more code. Test, debug, step through, and fix problems. Grab coffee. Continue. Go to lunch. Continue coding and debugging and going to any meetings that scheduled. On ocassion research difficult issues, or new design approaches, depending where we are in the project. Since this was a new project we were all excited about, we would sometimes stay late (meaning 7 - after 8 or later) and ocassionally come in weekends. During crunch time, right before product release to QA or the public, the evenings could go later. Sometimes 11:00 to 3:00 in the morning. Ocassionally take a break during the day to have an interesting discussion with a coworker, browse the web a little, or whatever. Sometimes stepping away from the code a bit helps creativity.
Currently, management has overrun us with ever changing process and time tracking, so each day starts off with a status meeting. Once a week we have 2 status meeting during on one day. Every 3-4 weeks, 2 to 3 days are devoted to estimating precisely how many hours one will spend on each of many subtasks, including the other many meetings and estimating time for doing subtasks. This also includes closing out each subtask from the last iteration and recreating exactly the same subtask for the current iteration if it is continuing work. There are at least 2 meetings to go over all those numbers in detail. One also needs to keep track of which subtask one is working on (includes breaks, emailing, meetings, discussion, etc.) and how much time it takes, even if it is modifying the same code. At least 15 minutes or longer at the end of the day, I use to fill out the time sheet. Some people update their time sheet continuously. In between all this, we get to work on a minor side artifact called code. As we are now time conscious, late hours are no longer put in by anybody. I am told by friend at other companies, that larger companies than mine are not as process heavy (although I can see where defense related companies -- which is not mine-- do need more process structure in place).
6) How does your science background help you in your job?
There has not been much call to actually use my knowledge of nuclear structure to help with coding. What has helped an approach to solving problems, that is problem solving strategies. Some of the mathematics I've learned has also helped when doing algorithm analysis or design. The person you hired me for my current position said he preferred hiring physicists to computer science majors because, in his experience, we seemed to write better code and solve more complex problems (and, yes, he earlier was a computer science major himself).
7) If a current college student wanted to get a job like yours, how
should they go about it?
Run away! Seriously though, keep an indepth knowledge of the fundamentals while keeping abreast of the hottest new technologies for which companies are looking. Recruiters and hiring managers are very buzz word oriented when it comes to resumes. This include Java (still), python, Spring, hibernate, Android (Google phone), iPhone, Ajax, portlets, etc. (perhaps an iPhone or Android app related to your thesis work which you could put on the market (and your resume). If you can find a way to incorporate any of those technologies into your physics work where appropriate, that would be useful. But while using these various technologies, apply the same critical thinking you do in physics. Don't accept things as they are, but question why such a thing is designed in such a way. You'll learn much more by doing so and it a way of thinking that should be familiar to a physicist. Also, don't be afraid to just start getting your resume out there and taking on a few interviews. Even if they are not sucessful, you'll learn from the interview process.
8) What's the most important thing you learned from science?
That's a hard one. There are so many things I've learned, including the ongoing fascination with learning how nature works. Related to work, I would say developing problem solving strategies would be at the top of the list. This includes not giving up on a seemingly intractable problem, but to always look for another angle, another approach that will make the thing work. To keep trying different things. Related at some level, is the drive to keep learning different things. If you have not developed a love for learning, working at a top level in a technology field like software is going to be difficult because one is always racing to learn new things and keep up the pace with progress. Chance are though, if you're in physics, this is a drive you already have.
9) What advice would you give to young science students trying to plan
See points 7 and 8 above. Decide what is important for you. Yes, in software, it is likely you will make more money. If the physics academia market is still tough (and it looks like that to me), it's not a bad way to go. In addition to a possible higher pay, depending on what the projects are, there are interesting problems to solve and fun challenges to conquer. But it's very difficult to make a u-turn back into academia. For some reason, universities really like to see recent publications to see what you've been up to. Having never lost my own love for both teaching and research, I do keep an eye out for academic positions for which I could be a good fit and would seriously consider moving back if such an opportunity arose. I realize this to be long shot, and In the meantime, what I'm doing in industry keeps me amused and keeps the bill paid. So don't be afraid to try new things and push your own boundaries, but if you really want to stay in physics academia (can't say I can fault that), know that there will be difficulties getting back if you make the leap into the software industry.
10) (Totally Optional Question) What's the pay like?
It's about $100K (order of magnitude :) ).
I'm a software engineer too, but don't make quite as much as Tim. My day sounds a lot like his. I mostly do C++ and work a lot with xml/xsl. It does involve a lot of problem solving.