Quite good re chem lab, except he missed two points. In more senior labs, there might be a resource that has to be used such as a spectrometer to test the results. Thus, being in better control of one’s schedule (get there first) or having partitioned tasks (what can we do while waiting) is a win. And the more important omission is that the TA must remain there until all groups are finished…. You might miss your dinner but odds are they’re going to miss most of theirs.
Their solution is to eat a larger lunch. And to track how people progress. Yeah, they can and usually do help the slowbies, but it’s best to work or train yourself out of such “negative visibility”. Do it before there’s more on the line that a lab grade or comment.
When you know what module and functions you will need to work on for the next feature, pointing out what lines of code you will need to work with isn't hard. Making people look around where in the code they are supposed to work on shows lack of preparation, which is against what this article is about.
If you know what line of code I should change, especially on a code base I'm unfamiliar with, just tell me. If you're going to have to do as much work as I am going to have to to figure it out, then you should probably leave it up to me (given the apparent power dynamic, it's safe to assume that your time is more expensive than mine).
In complex unfamiliar code bases especially, finding the line of code can easily be 95% of the work. Not communicating that information is making the task you are asking an order of magnitude harder for no reason.
Communicating what you already know (or even just suspect) isn't micromanaging. Micromanaging would be saying something like "and if it turns out I'm wrong and you need to change some other line of code instead, you need to come ask permission".
As someone who never did lab work before lab, and now maintains a healthy work-life balance where I do work during work hours, I got a different message.
It gets worse, the deeper you get into it. The reason is that your work hours are rarely dictated by a boss, as much as by the progress of the experiment itself. In my case while in grad school, if an experiment was "running," after multiple false starts, it could be anywhere from 0.1 to 100 hours away from breaking down, and everybody in the group -- including the professor -- worked in shifts to reel the data in. I was good with hardware, so I was on call for repairs. In my wife's case, some reactions and tests just took a certain amount of time, and stuff began to deteriorate if you walked away from it.
There are people who accept these kinds of situations, others who are forced into it by circumstances. I'd never force anybody into it. There should be plenty of 9-5 careers.
At college, its expected you do prep and reading before the lab. If your first time reading the procedure is when you are in the lab, you are going to lose time.
Usually the prep work beforehand takes less time than bumblefucking it in the lab on the day of, results in cleaner work, and better grade outcomes.
Also, with chemistry lab work in a lot of cases you can't just abandon your work because its time for chow, that creates a safety hazard (grade loss being incidental).
Same as you are meant to do reading before lectures or seminars, or assignments.
In professional labs in industry, things are different. You are a cog in a machine, usually doing the same standard operating procedure daily, and you do tend to go home on time and get that balance.
My chemistry lab experience was a lot like software development, but not in the way the author means.
We were often given open-ended or under-specified chemistry problems that required some analysis work in the lab before you could develop a strategy toward whatever the assignment objective was. Also, in some instances each team was given different problems that required different approaches, so to some extent you were on your own if you got stuck. Our lab was unsupervised most of the time, though we were well-drilled on lab safety and procedure. The professors only reviewed our plans in case we were using unusually dangerous chemistries -- not to stop us but to provide specific additional safety information related to that chemistry.
It was fun but I spent at least 25 hours per week in the lab for a few years. And the structured planning in the article really wouldn't have helped much because we didn't know what we didn't know, by design as a teaching tool. It wasn't paint-by-numbers. In hindsight, I appreciate that they made us learn chemistry this way. It was a struggle at times but it forced us to grow and learn how to deal with unknowns.
This maps much more closely to my early years as a software developer -- being comfortable educating myself on the fly in order to tackle an unavoidably under-specified software problems. I appreciate the benefit of efficiently structured processes, but that won't help you be a successful software developer if you don't know how to systematically grapple with unknown unknowns effectively. Or perhaps more accurately, those skills are most useful if "software development" is limited to domains where the software problems are usually well-specified, like enterprise widget factories.
12 comments
[ 3.6 ms ] story [ 32.8 ms ] threadTheir solution is to eat a larger lunch. And to track how people progress. Yeah, they can and usually do help the slowbies, but it’s best to work or train yourself out of such “negative visibility”. Do it before there’s more on the line that a lab grade or comment.
I did what he did plus worked the extra hours to boot.
>BE THE FIRST ONES IN LAB. Get started immediately.
Q. Why did the chemist come to work in the lab especially early?
A. To check the reaction.
Now when it comes to software, sometimes the documentation is so poor you're going to have to be pretty good at experimentation & discovery.
In complex unfamiliar code bases especially, finding the line of code can easily be 95% of the work. Not communicating that information is making the task you are asking an order of magnitude harder for no reason.
Communicating what you already know (or even just suspect) isn't micromanaging. Micromanaging would be saying something like "and if it turns out I'm wrong and you need to change some other line of code instead, you need to come ask permission".
The other thing is that I feel studying chemistry directly made me a better programmer - a lot of the skills are transferable.
It gets worse, the deeper you get into it. The reason is that your work hours are rarely dictated by a boss, as much as by the progress of the experiment itself. In my case while in grad school, if an experiment was "running," after multiple false starts, it could be anywhere from 0.1 to 100 hours away from breaking down, and everybody in the group -- including the professor -- worked in shifts to reel the data in. I was good with hardware, so I was on call for repairs. In my wife's case, some reactions and tests just took a certain amount of time, and stuff began to deteriorate if you walked away from it.
There are people who accept these kinds of situations, others who are forced into it by circumstances. I'd never force anybody into it. There should be plenty of 9-5 careers.
Usually the prep work beforehand takes less time than bumblefucking it in the lab on the day of, results in cleaner work, and better grade outcomes.
Also, with chemistry lab work in a lot of cases you can't just abandon your work because its time for chow, that creates a safety hazard (grade loss being incidental).
Same as you are meant to do reading before lectures or seminars, or assignments.
In professional labs in industry, things are different. You are a cog in a machine, usually doing the same standard operating procedure daily, and you do tend to go home on time and get that balance.
We were often given open-ended or under-specified chemistry problems that required some analysis work in the lab before you could develop a strategy toward whatever the assignment objective was. Also, in some instances each team was given different problems that required different approaches, so to some extent you were on your own if you got stuck. Our lab was unsupervised most of the time, though we were well-drilled on lab safety and procedure. The professors only reviewed our plans in case we were using unusually dangerous chemistries -- not to stop us but to provide specific additional safety information related to that chemistry.
It was fun but I spent at least 25 hours per week in the lab for a few years. And the structured planning in the article really wouldn't have helped much because we didn't know what we didn't know, by design as a teaching tool. It wasn't paint-by-numbers. In hindsight, I appreciate that they made us learn chemistry this way. It was a struggle at times but it forced us to grow and learn how to deal with unknowns.
This maps much more closely to my early years as a software developer -- being comfortable educating myself on the fly in order to tackle an unavoidably under-specified software problems. I appreciate the benefit of efficiently structured processes, but that won't help you be a successful software developer if you don't know how to systematically grapple with unknown unknowns effectively. Or perhaps more accurately, those skills are most useful if "software development" is limited to domains where the software problems are usually well-specified, like enterprise widget factories.
The author's classmates would probably not be as impressed by that revelation as they think.