3 ms·

If you're smart enough to do a PhD, you're smart enough to figure out all of the scaling and operational bits. It's not rocket science. It's just operations. S

If you're smart enough to do a PhD, you're smart enough to figure out all of the scaling and operational bits. It's not rocket science. It's just operations. Simply by asking relevant questions, practicing some things a bit, you'll get used to it. And consider that it's different in every organization, and nobody does it really well frankly. Given the pace of change, the varying technologies and flavour-of-the-month processes, it may always seem a little unwieldy an opaque: the feeling of 'not knowing everything' never goes away. And I concur with the itronitron: read other people's code on the team, who are known to 'code well'. It does not mean that algorithmically it's genius or even good - it just means that those are the styles/patterns that may be expected of you. It's like learning to say certain words a certain way. You'll get it soon and then forget you're doing it. Don't fret you'll get all of this quickly.

drewmassey 8y ago
This. I transitioned from a (non-STEM) PhD and am now working as a "real" engineer. It is called a "practice" for a reason, you will get better with time as long as you are self-reflective about it. One practical tip - take a look at Dan Bader's book if you are deep in Python, it has a lot of good stuff. One philosophical tip - depending on your organization, remember that slow is fast in engineering. This is somewhat different from more academic computing environments (at least that I know of). So take the time to get it right and really deeply understand your solution.
- tamcap 8y ago
  > remember that slow is fast in engineering Coming from an academic field myself... be careful with this one. Depending on your personal habits in academia, you might have to learn the opposite - your code doesn't have to be perfect, it has to work. Be careful not to end up overthinking the code/design and under-delivering on the timeline. Missing time estimate once in a while is usually OK, missing it consistently and by a lot might become a problem.
noobermin 8y ago
The thing is "not knowing everything" is the default in science too, so that should be familiar. It's just expectations and soft stuff that you got used to in your first two years of grad school you have to relearn again, I suppose.

drewmassey 8y ago

This. I transitioned from a (non-STEM) PhD and am now working as a "real" engineer. It is called a "practice" for a reason, you will get better with time as long as you are self-reflective about it. One practical tip - take a look at Dan Bader's book if you are deep in Python, it has a lot of good stuff. One philosophical tip - depending on your organization, remember that slow is fast in engineering. This is somewhat different from more academic computing environments (at least that I know of). So take the time to get it right and really deeply understand your solution.

tamcap 8y ago
> remember that slow is fast in engineering Coming from an academic field myself... be careful with this one. Depending on your personal habits in academia, you might have to learn the opposite - your code doesn't have to be perfect, it has to work. Be careful not to end up overthinking the code/design and under-delivering on the timeline. Missing time estimate once in a while is usually OK, missing it consistently and by a lot might become a problem.

noobermin 8y ago

The thing is "not knowing everything" is the default in science too, so that should be familiar. It's just expectations and soft stuff that you got used to in your first two years of grad school you have to relearn again, I suppose.