Chem Lab Made Me a Better Dev
edweissman.com
edweissman.com
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.
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 other thing is that I feel studying chemistry directly made me a better programmer - a lot of the skills are transferable.
The author's classmates would probably not be as impressed by that revelation as they think.
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.
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".