Posted by kiyanwang 4/11/2025
I've found this a lot in data systems where folks glue stuff together as fast as possible to "ship", while missing the huge glaring issues with the foundation that they've built on top of wet, sliding mud.
to shift the culture from “fast” to “safe” is mostly a team-based effort because not all teams need to shift. and even within a team you may have experimental and mature products.
i’ve seen this shift happen successfully multiple times. it must come from leadership. C-level and down. even if it’s just for one team. or one product. you need the buy in all the way up. and then your people in the chain will adapt to changing expectations
Every increase in your knowledge is a simultaneous decrease. You learn and you unlearn at the same time. A new certainty is a new doubt as well.
I pondered it a bit and arrived at "learning is losing innocence", from the point of view of somebody who mulls over Enos process. I think that sort of ties-in with this article.
You can code faster, but then you might overlook things. You can work a lot and earn a lot of money, but you might struggle with nurturing your friendships. You can have a partner but then you'll have arguments with them. You can remain single but then you'll have to deal with loneliness.
There are plenty of slow coders who overlook more things than some fast coders. Plenty of people not working a lot who still struggle to nurture friendships, and so on.
It helps me to know that the richest, most attractive or smartest person alive has the same amount of problems. It's just part of life and I am happy
My high-level view of backend development is to make functions that transform one persisted consistent state to another. Define the start/end states and all the code that's used to do that is implementation detail. The other part is fast reads of same.
It may cause you to favor complex solutions that are obvious to you, but inscrutable to people without your deep knowledge.
This is very common with people who are very skilled at a complex tool (such as C++ or Kubernetes).
This is a valid concern that I'm aware of and I try to make things as clear to others as possible. Often my PR descriptions are much longer than my code changes with tests that illustrate exactly what's being done and including links to reference documentation that spells out what's being used. Most often others immediately understand it and were merely only unaware of its existence.
It's not exactly that I lack experience elsewhere, only that I find understanding the base to be the biggest force multiplier when things get tough.
Weakness in the inverse: not being ready to change to new code, because you have a clear and distinct understanding of the old, and an uncertain take on the new. In that case, even if the new were better objectively, it would be discounted for you by uncertainty.
Conversely, if you understand something complex deeply and newbies don't, to them something that's easy to understand (but defers problems your stack solves) is preferable, and you end up with culture and governance issues. Managers who are relatively ignorant then set up competitions to surface issues, validate claims, and develop alternatives to mitigate their reliance risks on employees.
So: move fast and forget things, and expect a fight :)
I don't understand your 2nd point. I also spend a fair amount of time educating others on the importance of knowing what's underneath.
What are other dimensions along which there's this duality of strength/weakness in engineers (or even in the general workplace) that you've seen either in yourself or other coworkers?
and so on.
Try this https://www.gyfted.me/personality-quiz/strengthsfinder-test-... or this https://www.gyfted.me/quiz-landing/bfas-personality-test to learn more about your strengths/traits