Tag: optimization

Posted on

Feels Like Friday

Friday is not just the name of a day of the week, it is the name of a feeling. And sometimes, the whole universe feels this feeling with you (as evidenced by nothing going right and equipment often not working on a very particular day of the week).

This week, every day had been feeling like a Friday for some strange reason, and then I realized that this week really was the “Friday” of the year.

No wonder I have been running high on introspection – typical “Friday” mood. Not to mention, this “Friday” also marks the official mid-point of my PhD, which means that the time is ideally situated to look back on how far I have come and how to best manage the rest half.

So, upon the (partially) successful survival of my two years in Finland and in my PhD, I sat down to count my little successes along the way, which took me perhaps five minutes, not much there. I’m also pretty sure that I’m still navigating the unpredictable waters of culture shock and adjustment, but now I find myself on stable ground more often than not (I would probably put together my final thoughts on the subject, which are still worth about three to four blog posts). 

But there is light in the middle of this tunnel. Lately, I have finally been seeing some shape and form from my last two years of optimizations. Or that’s what I would like to believe (the human brain is really good at erasing information that causes it discomfort, so maybe I’m living in my little, custom-made, fantasy bubble).

Today, I did a little exercise. I made boxes for each week I was getting in the next two years (inspired in part by a part of this brilliant and funny TED Talk). Before this, I didn’t know how uncomfortable a task as simple as drawing and counting boxes, can be.

As of 29 December 2019, I have 105 boxes. Don’t look like all that much.

Really put things in perspective for me.

Posted on

Machine Learning

I would like to, first, apologize for the misleading title.

Wikipedia defines “machine learning” as:

Machine learning is a field of computer science that uses statistical techniques to give computer systems the ability to learn (e.g., progressively improve performance on a specific task) with data, without being explicitly programmed.

But that is not what this post is about.

You see, as a junior scientist about to embark on your career path, one thing you should do is learn to use different machines. Some machines will make something for you, whereas others will tell you that those machines are probably not working, and despite all your efforts, it will be some time before you start getting good samples or results out of any thing in your lab.

So if you work in a lab, you’ll now have a very good idea of who rules there: It’s them. Now and forward, in your time as a researcher, you’ll go into many labs, meet a lot of people, and learn a lot of new stuff… but nothing and no one will judge you like those silent machines sitting smugly atop work benches of your lab.

Many a times, I have started working with one, thinking, oh this is going to be one of the easier ones. Never has that attitude worked for me. It’s like you cannot trust any single one of them; even the ones that you think you know, won’t think twice when it is as tempting as shattering your trust in them.

They don’t care if you are enthusiastic about research and have chosen this field as your career with such joy. They will happily make you think that you have nice typical graphs* in your presentation that you are about to show in your group meeting. They want you to suffer, to taste embarrassment, like they want to see how long you are going to last in this field that you have been so passionate about …

… Until you have proven yourself worthy of research.

As a result, one of the few things I have always found myself doing in the beginning is to start gaining favor of the machines that are in my lab. To build good rapport with them. And it is not easy, not with every machine. Even after you feel you two are going along well, they will still  test you, or just throw you under the bus when they feel like it**.

If it all sounds depressing to you, let me tell you there is hope. Somehow, after you have stood beside them long hours and worked with them at odd times***, they will start to slowly accept you and let you enter the ranks of researchers. It’s blood, sweat and tears to gain that kind of trust, but you can gain the status of meh-you’ll-do in the eyes of the machines.

But don’t ever expect them to start liking you, because that’s ridiculous, they probably don’t have a heart.

 

 * Well, okay, they may have been looking a little weird to you as well, but early on, you wouldn’t know that, thinking this is probably how they are supposed to be.

** Which tends to happen most on Fridays, followed next in probability by Mondays.

*** Condition of high-levels-of-consistency needs to be met with these requirements of long-hours and odd-times.

Posted on

The Pessimist In The Lab

It’s a very good thing to practice optimism in life.  Optimism can keep you going in the face of challenges, and absurd optimism can keep you going despite past failed experiences and your knowledge of all odds being against you.

But in general, optimism is healthy, and I have been thinking about practicing more of this optimistic approach to life in general.

Except when it comes to my lab work. There, I don’t see how optimism helps me.

Because lab work, well, you can never be too sure about lab work.

And, as past experiments have shown, 95% of experiments don’t usually work the way you want them to (and if you are optimizing some procedure or recipe, the success rate can be quite close to zero).

In principle, I could be optimistic about my experiments before I start them, that may be this is THE time they will work.

But being a scientist, how can you just ignore the evidence of your low success rate of past experiments? How can you disregard all that data?

The thing is, it is easy to be optimistic and hard to be a realistic pessimist. It’s also called “the planning fallacy”, which describes how we, humans, are optimistic about our abilities and predict we can do things much faster and smarter than we actually are able to.

And I have been subject to this planning fallacy numerous times. Dozens of times I have thought I could do my part in group assignments well in time, or that I could surely submit a work update to my supervisor by the end of a week. Or that by July, I’d surely be at a stage where I’d be making my own Perovskite solar cell devices (didn’t happen, just so you know).

90% of the times, though, I have found myself not even close to meeting those deadlines.

So with the lab work, I have no choice but to opt for pessimism as my approach-of-choice to go about it. That despite every strategy that I develop to get my next solution not-cloudy, is probably not going to work, because:

1) It didn’t work the last time, when I very well thought that may be this in THE time it will work.

2) If it, by some tiny amount of chance, does work, and the cloudiness from my solutions clear up, well then, that is exactly how I’d prefer it, wouldn’t I?

So, in the long run, pessimism in the lab is a better option. If it doesn’t work, you are not disappointed, because you knew it wouldn’t work.

And if it does work, you can be twice more happy compared to if you thought that may be this in THE time it will work.

P. S. However, of course, there is a catch. If all of a sudden, everything starts going right in the lab, well, that’s enough ground to include skepticism in your mix of pessimism.

Posted on

That Doesn’t Work

For the last four months, my PhD has accumulated into wonderful experiences of “okay so that doesn’t work”.

Which is good, because every time one thing doesn’t work, there’s one thing less to discover that doesn’t work, getting you one step closer to the thing that does work.

So you have this recipe/procedure/protocol that you need to optimize, or get the best out of. You start off with rather good energies, thinking the most it will take you is, what, three weeks? It seems pretty simple. You’ll easily find the best way to do it in that much of time. 

As you try on and on, you realize there are so many factors and parameters that are affecting the whole process. And to get to the best possible option, you will need to twiddle with all of those (ALL of those, one at a time. And then of course you have to make sure that once you are checking one factor, something else doesn’t meddle in and give you some kind of false positive or negative).

But…

… Do you even have all the options jotted down? There might be more. There must be something you are missing.

… What if option G was the best recipe? It did give some results but you probably went ahead trying H, I, J, K, L because you may discover something better (there might be no “better”, but you’ll need to find that out for yourself, now, won’t you?).

… Would “better” pass off as “best”? What even is meant by “best-possible recipe/procedure/protocol”? Is there a “better” than what you are considering “best”?

After everything, you end up with lots of data, most of which is just proof of how, mostly, it doesn’t work (if you are lucky, it may be otherwise). Obviously, there’s always a chance that nothing is going to work. And it might be some time before you realize that you need to change the whole game plan.

I mean, a PhD is like life in real time. So you want to learn about life, go get a PhD: It will teach you things in a couple years that you might take decades to learn otherwise.