1. Doing Nothing During Crises
Developing a mental filter to avoid panicking over broken code or failing pipelines improves both productivity and mental health.
Hear it at 0:05 →Engineering video
4:21 · 5 July 2024
Developing a mental filter to avoid panicking over broken code or failing pipelines improves both productivity and mental health.
Hear it at 0:05 →Recognizing that if everything is important, nothing is, and helping product managers and stakeholders focus on only one or two critical goals.
Hear it at 1:14 →Realizing that a software engineer's earnings do not always reflect their skill level, experience, or talent, but rather the financial capacity and context of the company they work for.
Hear it at 3:00 →Three weird things I learned as a senior engineer that made me a better developer. Number one, doing nothing. Yeah, back in my junior times, whenever something happened, like there was a bug in our JavaScript code, or one of our pipelines was failing. I used to panic because I thought it's my job to fix everything. I once woke up at 3:00 a.m. in the morning, thinking that the app was crashing and I had to fix it.
A weird thing that I learned as a senior is that even if something is broken, sometimes it's because it's not important. So I kind of developed a mental filter where I don't know from stimulus to reaction so fast. As a senior developer, when people came telling me, hey, oh, this needs to be done and this is broken. I would always turn on my mental filter and of course I would listen and be like, sure, yeah, let's talk to a product manager and let's add it to the sprint.
But I wouldn't freak out. I wouldn't panic. I wouldn't sweat about it. This doesn't mean I would ignore production bugs or things like that. As long as you have some testing in place and as long as you follow best practices, even if things go wrong, because they always do in software development, it wouldn't be the end of the world. Thinking back, doing nothing actually improved my productivity. Because now I could focus better on the task I was working on, without getting distracted so fast, and it also improve my mental health because hey, I started having fun again, not living in this constant fear of hey, what's going to be broken now?
The second thing I've learned as a senior engineer is that if everything is important, then nothing's important. But so many times I've been in development teams where priorities was changing all the time. So, you know, we would come up with some requirements one week, the development team asked we would start implementing, working on them, and then one week later, the management or the product manager, whatever, would change strategy.
Or maybe the customer would ask for something else and we would change priorities again and throw away all the work we've been doing in the past. And I had this drive to ship things, to complete things, and to see the applications that I was building, getting in the hands of our users. But we would never actually get there and the excuse was always that it's important. We are doing this other thing because it's more important.
We need this feature flag because sales is asking for it. We need to making the app faster now because marketing said it's slow, or we need to have a public API because now it will allow us to integrate and maybe people want to integrate with us. And we need all that right now because they're all important. Well, you know what, if everything is important and everything is critical, then nothing is.
So, as a senior developer, I learned that they can only be one or two things that are important. And the rest are there because companies get confused, they start running in all these different directions. And what I try to do now, instead of getting to work and trying to achieve all that, which is impossible, is to help the product manager and the stakeholders understand that not everything it's important and that we need to prioritize.
And if that doesn't work, I simply say, hey, you know what, this is what I can do and you to take this long. Do you want it or do you want something else? Oh, and by the way, talking about senior developers. If you're a JavaScript developer looking to level up, you might be interested in finding your technical gaps and how to fix them. Well, we put together for you a free technical assessment you can find out in the comments below.
On to the third weird thing I learned as a senior developer and transmit this one, it's not obvious. And that is money doesn't always reflect skill. So, I would talk to other developer friends about how much they earned. I wanted to see where I'm at and are you people that made a lot more than me? But again, for a long time, I thought that they earn more money because they are better developers than I am.
They have more experience or more talent or they have a CS degree. I didn't had one. And it really struck me one day. I was having lunch with one of my cousins, you know, and he just arrived into the city and got a job as a junior dev. And the funny part, he was earning more money than I did. I had five years of production level experience and he had zero and he even worked less hours. What was the difference between the two of us?
Well, I was working for a small startup trying to scale up, that didn't have much cash. He was working for a very established corporate, desperate to digitalize, that was willing to throw as much money as necessary. to the problem. So yeah, you can be more experienced, you can have more talent, and you can even work more hours and still make less. If you work for the wrong company, how much money you earn as a software engineer?
is not always an indicator of how skilled you are, but of who you actually work for. So as a senior dev, I made sure that I always work for the right people and the right companies, and that is companies with a lot of cash. Question for you now, what is one weird thing you learn as you level up as a software developer? Let me know in the comments and I'll see you in the next one. and I'll see you in the next one.