Ask HN: Advice for a commercial SWE moving into scientific SWE
5 comments
Having done this in a minor way, my advice is:
1) do some reading on the field, hopefully something written for the non-Ph.D. student; you will never be able to keep up with the pros but it will help you to understand what you are being asked to do
2) no one cares about your software's internals but you, probably, which has two major consequences: no one is interested in the great thing you did to the internals, and no one will keep you from getting lost in a rats nest of unmaintainable code.
3) you will need to do a bit of "code for you", stuff like unit tests and refactoring for better readability and maintainability, but no one wants to wait on you doing before you do the thing they want done. So, just allocate something like 25% of every task or project to that kind of thing, as just administrative overhead. Don't bother telling anyone else about that, except at a very high level if they ask. It's like a chauffeur getting the limo an oil change or other maintenance: the boss just wants to say "get me from A to B", and you have to make sure that the stuff to keep the car running in good order gets done without him having to tell you to do it.
4) you will not be able (or allowed) to do as much of (3) as you want, just do what you can
1) do some reading on the field, hopefully something written for the non-Ph.D. student; you will never be able to keep up with the pros but it will help you to understand what you are being asked to do
2) no one cares about your software's internals but you, probably, which has two major consequences: no one is interested in the great thing you did to the internals, and no one will keep you from getting lost in a rats nest of unmaintainable code.
3) you will need to do a bit of "code for you", stuff like unit tests and refactoring for better readability and maintainability, but no one wants to wait on you doing before you do the thing they want done. So, just allocate something like 25% of every task or project to that kind of thing, as just administrative overhead. Don't bother telling anyone else about that, except at a very high level if they ask. It's like a chauffeur getting the limo an oil change or other maintenance: the boss just wants to say "get me from A to B", and you have to make sure that the stuff to keep the car running in good order gets done without him having to tell you to do it.
4) you will not be able (or allowed) to do as much of (3) as you want, just do what you can
The tools you have as an "industry" software engineer will be incredibly useful for helping scale research.
However modern software engineering practices from industry have not all percolated into the research world, so it may be an uphill battle to get support for resources to improve infrastructure. In some cases, it may be counter-productive to implement those practices "half-way", especially if you're a one-man infrastructure team.
Iteration speed, flexibility and ease of experimentation is paramount in the research world, so pitch the work in the context of these goals.
However modern software engineering practices from industry have not all percolated into the research world, so it may be an uphill battle to get support for resources to improve infrastructure. In some cases, it may be counter-productive to implement those practices "half-way", especially if you're a one-man infrastructure team.
Iteration speed, flexibility and ease of experimentation is paramount in the research world, so pitch the work in the context of these goals.
Well, start by remembering that the software is going to be a tool not the product. Therefore it has to work correctly in terms of provable results but the longer term maintainability is less important. Slick, aside from publishable data, is less important as the users are domain experts.
Try to understand the research work being done, “going to school” on the material as needed. Scientific chauvinism can be strong at times and people who don’t know the jargon can be (or will be) dismissed as technicians. The fact that you’ll know far more about software development won’t matter as that’s not of real interest to them. Fair? No, but so it goes..
Hint: it’s pyridine not “benzene with an N in it”.
Certain fields have been well served by Foss software and even tech books. Make sure you know what’s already there in case it can be adapted or used as test tools. Understand why what you’re doing must be different so you can defend yourself. There might be commercially available options but academic research isn’t usually interested in spending that kind of money. Pharma research is totally different about this, although cheap bastards are there too.
You’re out to prove you’re more valuable than a second year grad student. Be helpful, productive and be willing (and hopefully able) to push the project forward.
Try to understand the research work being done, “going to school” on the material as needed. Scientific chauvinism can be strong at times and people who don’t know the jargon can be (or will be) dismissed as technicians. The fact that you’ll know far more about software development won’t matter as that’s not of real interest to them. Fair? No, but so it goes..
Hint: it’s pyridine not “benzene with an N in it”.
Certain fields have been well served by Foss software and even tech books. Make sure you know what’s already there in case it can be adapted or used as test tools. Understand why what you’re doing must be different so you can defend yourself. There might be commercially available options but academic research isn’t usually interested in spending that kind of money. Pharma research is totally different about this, although cheap bastards are there too.
You’re out to prove you’re more valuable than a second year grad student. Be helpful, productive and be willing (and hopefully able) to push the project forward.
Not a research env, but my approach to learning the env at new jobs regardless of industry:
-learning what business processes i need to try understand that will eventualy get converted into code. This is the hard part, requires relying on talking to other devs, any documentation, and learning what they need you to do.
-technical things i dont know but will need to know soon like we will do X written in Y to do Z (if i had never done X Y or Z i would try get familiar with that when time allowed).
-learning what business processes i need to try understand that will eventualy get converted into code. This is the hard part, requires relying on talking to other devs, any documentation, and learning what they need you to do.
-technical things i dont know but will need to know soon like we will do X written in Y to do Z (if i had never done X Y or Z i would try get familiar with that when time allowed).
Could you elaborate? Was it a lack of good practices (source control, staging, testing, etc.) or sth else?
I was mid-senior when I changed to a research SWE job. Might be able to offer some insight on some specific problems.
But in general, each place has its own expectation about code quality and process. One of the most important skill for a SWE is to not expect anything when joining a new place, but adapt to that place's way of working instead.
I was mid-senior when I changed to a research SWE job. Might be able to offer some insight on some specific problems.
But in general, each place has its own expectation about code quality and process. One of the most important skill for a SWE is to not expect anything when joining a new place, but adapt to that place's way of working instead.
Has anyone gone through this transition, in particular as a relatively junior dev? Just looking for any thoughts or advice, that might help me make the best of a new role, and adapt to a research environment. Thanks.