An open reflection
Table of Contents
What’s this about
There are moments you’re left alone with a difficult task and everything seems to go wrong. Eventually, you solve the problem, but often with a terrible solution that costs you dearly and it seemed to be the only way to get it going. In the end, it was not as bad as one thought. However, being confronted with that problem and not able to solve it the way you wanted to causes an immense distress.
To cope with such matters, I try to apply an idea I heard once: You express your concerns and record them and after a while you listen to them again. This time you try to advise yourself on how to deal with the problem. I’m not sure where this is coming from, but the idea stayed with me. I call this format an ‘Open Reflection’. To make this a bit more guided I’m developing a bit of a structure: The first block is the background and will provide some context. Afterwards, it describes the problem with different attempts and errors that were made before finding the right solution. Naturally, the solution will be written about. The next step is to reflect about the situation and why it was so dire. In the end it will all be concluded with an advise and what was about to be learned, with some ideas what’s to improve for the next time.
The motivation behind this is also that I quite often do not feel understood by others with my troubles and concerns. This might be caused by a lack of the necessary context and information by the others to provide a useful recommendation. This is why I often feel like that the advise people give to me is just not helpful at all.
It rather seems to me that people fire a swarm of potential ideas at me that might work. While this logically increases the chance of ‘solving’ the problem, it feels just wrong and unheard. This could be, because they try to solve the problem with missing information rather then relate to the context around the problem. In the end they do not pick up where my emotion are in this situation … Disregards, let’s get going with the first reflection.
The background
Sometime ago, I was working on a set of unit-tests. As always, one of my co-workers insisted to compose very strict unit-tests. In this particular example, an image file is loaded in python using the PIL library. The tests should ensure that this process is done with lazy loading.[0]
Lazy loading implies that only a specific part of the image is loaded that is necessary for processing it. For instance: Checking that an image has a reasonable size before it will be loaded is a matter of security. In this example the unit-test validated only the error messages that occur when an image file was oversized.
There were some more tests about security, but we’re going to focus on this one issue. Obviously, lazy loading should be always the default behavior and when a faulty image is uploaded with oversize, it should always break the unit-test, right? This would implicitly validate this assumption.
However, my co-worker insisted to test for this explicitly. Why not check that the given load function isn’t called responsible for lazy loading? Because it could happen that a newer release of the library changes the default behavior and stops lazy loading of images. Suddenly, all our security assumption would become untrue and might cause defects. We agreed on this and I went to develop the corresponding unit-tests.
The problem
At this point things became messy. I’ve started to read the code from PIL to check for functions that were always invoked. After some reading I made some assumptions and started to develop them into my tests. Hours later, my test was ready and it failed.
Why? Did I use the test function incorrectly? Did I miss some option? I started to dig into the code.
My errors
Here is a brief overview of errors I’ve made during my attemps to solve it:
- Re-implementing pytests function to validate the function was invoked in three different ways.
- Try to mock the private methods of the PIL object class.
- Implemented python with stacks to check the invoked functions and validated. But I did not go trough with it, because the solution at this stage seemed too absurd.
The solution
What was the error? I did not check for the correct function in the PIL library that would be invoked to load the files.
The reflection
At first I was excited to work on this task. It was part of a bigger User-Story that addresses various security related issues and it had been on the backlog for a while. Everything within the User-Story seemed obvious and easy. Also, it was the last User-Story before I would have switched to another team. Hence, it was important that the User-Story will be finished on time. Additionally, I was the most experienced person in regards to security within the team, knowing what was to be considered and what was not.
All of this added to the pressure around the task and when it came to a halt I was in pain. But how did I try to resolve this? Why did I not just drop the requirement of my co-worker and moved on with the task? I could have simply declined the requested change and closed the task.
For once, he was quite busy during that period of time. He was stuck on a critical task of his own and was not reachable. Besides, I felt like that he owned me here, because our team had an arrangement that it requires the approval of two developers to merge code into upstream. Rejecting his change requests would lead to discussions why so. Considering the fact that he was a very careful person about code quality and tried to get things right it would have been a difficult discussion. Lastly, I wanted to get it right, too! It reflected my own view on code quality matters and that it shouldn’t suffer because of a lack of time.
The real problem why it felt so dreadful was my impression of being inadequate. I knew that the problem could be solved easily. Yet I failed to figure out the correct solution right away. But this is exactly my expectance. I should be able to solve a problem as simple as the problem seems. Discussing such a simple matter with my co-worker would seem like an annoyance to him and a defiance of my expectance. Even worse it felt like that I tried to gain attention by over-dramatizing the problem. In the end it could imply that I have not the necessary skills to solve it and others would see me as an impostor that should be let go of the project.
I forced myself to focus onto the problem. However, I need to emphasise what I’ve done better in this moment compared to a similar situation over a year ago: I’ve talked to someone about the problem. This was way earlier, instead of spending two weeks until my faulty solution starts to work, it took only two days! After some brain storming session with a friend, who is quite related to the project, the error became obvious.
In the end my co-worker who was quite critical merged the PR without any complain! Which I accounted for his lack of time to do a proper review. However, it coudn’t be that bad, otherwise he would have taken the time to get things right…right?
The advise
First of all, your code was merged without any remark! That’s a huge success and you shouldn’t downplay that result. It might be possible that your co-worker merged it because he did not not have the time, but the code wasn’t that bad, right? Maybe he was just pleased with the result. As you stated before: he was a critical person. Do you really think that he would have allowed bad code to get into the repository when he’s as careful as you though he is? You can’t read his mind and in the end we don’t know what he was thinking. That’s the fact, everything else is just speculation and the only fact we know is that it was accepted.
On top of that: You already improved during this task and that’s great! You’ve recognized that you were stuck and resolve it without the help of the co-worker. Hell you even asked a friend to help you. It is often very useful trying to explain a problem to someone, Rubber duck debugging. It does not get better than this.
Here’s the thing: It’s perfectly normal to struggle with a technology one does not feel comfortable with. You had to read code you never knew before and incorporate it in a similar new way. For me the solution is how to deal with the external dependency. I think it is important to address expectations in the right manner, in an open way to those involved. Try to define them explicitly rather then living them implicitly. The struggle you had, should have been communicated.
Another part of this are your own expections towards yourself. It appears to me that you at first over-estimated your own capabilities to estimate the time necessary to solve the task. Just because you can see the way you need to take does not imply that you have walked it already! There are always complications on the way. That’s the gap between theoretical and practical knowledge.
This brings me to the next topic: overdramatising. I think not that you dramatised here asking your co-workers. It is rather that you’re trying to understand your own hardship and investigating why things are not working. Asking someone more knowledgeable is a legit strategy to solve your problems.
However, your reasoning is much lead by an act of overdramatising of a potential outcome. I think that is rather a symptom of your anger that was inflicting pain to yourself with a version of the future that you want to avoid in any way. Rejection is painful and thinking that it is the only logical result of a failure is flawed. People are rather reluctant about such consequences. It is a type of consequence only put when it is absolutely necessary.
For the next time you’re confronted with such feelings, try to make a step back and think logically about the situation just like a threat model. Sure we humans are bad at assessing risks, but that depends on the situation. We’re bad to judge for instance when it is a situation we are not familiar with. Being already established within a team for a year should give you confidence that the people around you won’t let you go for minor mistakes. Even big ones should be manageable. The main question is more often: How are mistakes handled and communicated in a team. Was someone else let go for mistakes like that? No? So why the trouble?
Emotions becloud our ability to think logically, so here is an option to think that you’re let go! Imagine that it does not matter anymore and try to do the best job you possibly can. Do it for yourself! See it as an exercise for the next project. As long as you’re not getting sloppy it should be helpful to cope with such emotions.
At this point I think it is enough for the moment. Good luck for next time!
Conclusion
I had this post up my sleeve for weeks and it took a lot of time and energy to write this post. I keeped rewriting things and now I just want to get it out. But so far it was worth it and I learned a lot about me. Did you like the reflection? Did you have such a moment you think it’s worth reflecting on? Maybe you can share your open reflection with others, too! Looking forward to it!