Getting stuck and checking assumptions

This week’s briefer:

• Software Eats Culture for Breakfast

• Top 10 rebuttals to: “Agile is great. But it won’t work here.”

• Design Leadership

Hey,

It’s been a busy week. More interviews and a challenging tech task that took most of the week.

You know when you have a feeling that the task is beyond your expertise or that you’re hitting a wall constantly? That was me. I had to use a language that, while I would love to work with it, my familiarity with it is not at the level of JavaScript or TypeScript. At the same time, a few silly mistakes (in hindsight) took hours to solve. Interestingly, in the moments I was about to give up because it took too much time and probably wasn’t going to make it, I managed to have a “breakthrough” that allowed me to move forward. In the end, regardless of passing this hiring stage, it was interesting.

Part of the existence of a developer is to deal with these kinds of situations. There were many situations where I got stuck and spent hours, or even days, on a problem or bug, just to discover that there was a silly mistake or oversight, or that trying something that might appear ridiculous actually works.

Some of these situations start from wrong assumptions about our code or what things should be or do, and we stick with them for a long time while trying to understand why everything else is wrong. What I’ve found helpful is that, when I get stuck, and I get the feeling that there’s something missing, it’s time to look at my own ideas and conceptions: how do I think the system works step by step, what if my understanding is flawed or incorrect?

Other times things automagically fix themselves, specially bugs or a bad setup. You can’t explain what fixed it and the many experiments you’ve done changing the code don’t help in getting to a specific answer, but it’s fixed and you’re happy.