Nov 26, 2023·edited Dec 15, 2023Liked by Fran Soto
I can relate to that quote. In my first internship, I was reading a file and there was a piece of code that spanned a few lines. It was essentially assigning a value to a variable based on some connditions. It had a functional method, .some() in js, and a ternary inside the .some(). It was hard to read. I looked at who wrote it and judged them to be bad at coding.
Later on in the same file I saw the lines above the code I had looked at earlier and saw that all the lines had similar code in assigning a value to a variable. I realized the original person I was thinking about had not written their code from scratch; they copied the lines above and modified it for their usage. I would have done the same. Why spend time making code nice and tidy when there is a working implementation right above? That taught me not to easily judge someone by their code. There may be other reasons.
Exactly. It's the easiest things to jump into conclusions and assumptions. Taking a step back and trying to understand people and the process in general makes a huge difference!
I love those stories Bob, Basma. Thanks both for sharing.
If we imagine our brains as computers, we are wasting a considerable percentage of CPU power in judging people. When we skip that first judgement part, we free the capacity to see more details.
I also have plenty of these stories.
I remember in a technical design I moved configurations that were duplicated in multiple services to a single source of truth. At first, this seemed like a bad design decision, but I stopped myself from judging because I had in high esteem the Senior Engineer behind the initial design.
After investigating a little I discovered that the second service that held those configs was not in his design. It was a quick follow-up for legal requirements that came later on. To avoid any impact on the timelines of the project, he took the fastest approach, duplicating the configurations.
It made perfect sense. The project as he designed it was an MVP. Until proven successful, the time to market was more important than the long-term maintainability.
Wow! Thank you for mentioning my story, Fran!
This story of yours relates to me so much as well.
"Jumping too fast into a conclusion is the mindset of a fool. Observing with the mindset of a student is the approach of a wise person"
This part for instance, I used to do all the time back when I first started as a junior, and it caused me a lot of hassle.
I totally agree with validating assumptions and doing your best to make sure not to jump to conclusions.
Also, I like the part where you mentioned about acknowledging others work and welcoming people to the team.
I can relate to that quote. In my first internship, I was reading a file and there was a piece of code that spanned a few lines. It was essentially assigning a value to a variable based on some connditions. It had a functional method, .some() in js, and a ternary inside the .some(). It was hard to read. I looked at who wrote it and judged them to be bad at coding.
Later on in the same file I saw the lines above the code I had looked at earlier and saw that all the lines had similar code in assigning a value to a variable. I realized the original person I was thinking about had not written their code from scratch; they copied the lines above and modified it for their usage. I would have done the same. Why spend time making code nice and tidy when there is a working implementation right above? That taught me not to easily judge someone by their code. There may be other reasons.
Exactly. It's the easiest things to jump into conclusions and assumptions. Taking a step back and trying to understand people and the process in general makes a huge difference!
I love those stories Bob, Basma. Thanks both for sharing.
If we imagine our brains as computers, we are wasting a considerable percentage of CPU power in judging people. When we skip that first judgement part, we free the capacity to see more details.
I also have plenty of these stories.
I remember in a technical design I moved configurations that were duplicated in multiple services to a single source of truth. At first, this seemed like a bad design decision, but I stopped myself from judging because I had in high esteem the Senior Engineer behind the initial design.
After investigating a little I discovered that the second service that held those configs was not in his design. It was a quick follow-up for legal requirements that came later on. To avoid any impact on the timelines of the project, he took the fastest approach, duplicating the configurations.
It made perfect sense. The project as he designed it was an MVP. Until proven successful, the time to market was more important than the long-term maintainability.