41–50 of 361 posts
Complexity, if it can be reduced to a single measurable dimension, is only one of several factors in a solution space. There are other properties such as, maintainability, scalability, reliability, resilience, anti-fragility, extensibility, versatility, durability, composability. Not all apply. Being able to talk about tradeoffs in terms of solution spaces, not just along a single dimension, is one of what I consider…
Complexity, if it can be reduced to a single measurable dimension, is only one of several factors in a solution space. There are other properties such as, maintainability, scalability, reliability, resilience, anti-fragility, extensibility, versatility, durability, composability. Not all apply. Being able to talk about tradeoffs in terms of solution spaces, not just along a single dimension, is one of what I consider…
“Complexity” understood as what’s gonna make development on this system fly easy and fast for the next 10 man-years de facto means side steps when naive approaches would charge straight ahead.
Tortoise and the Hare… the urge to hurry up and burn hard the first two weeks (low hanging fruit, visible wins, MVP!), resulting in ever decreasing momentum due to immature design and in-dev maintenance needs is befuddling to me. So much “faster” for weeks, and it just meant the schedule slipped 6 months.
One could say in order to be a senior developer in any area, more-than-good- communication skills are required.
Unfortunately that's not the case. There are many senior and above level engineers out there who are unskilled communicators but very technically skilled.
Complexity, if it can be reduced to a single measurable dimension, is only one of several factors in a solution space. There are other properties such as, maintainability, scalability, reliability, resilience, anti-fragility, extensibility, versatility, durability, composability. Not all apply. Being able to talk about tradeoffs in terms of solution spaces, not just along a single dimension, is one of what I consider…
That includes gate-keeping behaviour such as not handing off knowledge, sham performance reviews to prevent ambitious juniors from over-taking them (even with AI) and being over-critical to others but absent and contrarian when the same is done to them.
That leverage does not work anymore in the age of AI as having "expensive" seniors begging for a pay-rise can cost the company an extra amount of $$$. So it is temping to lay them off for another one that is a yes person that will accept less.
In the age of AI, I would now expect such experience to include both building and working at a startup instead of being difficult to work with for the sake of a performance review.
Earlier quoted context omitted.
I came to say somethign simular actually. > Ah, baby, this is my senior developer. The avoider, the reducer, the recycler. They want to avoid development as much as they can. There are times when this is good, there are times when actively trying introduce an improvement is the best way forward. A good senior is able to recognise when those times are.
That doesn't sound as good in meetings. The person who can cut scope and get everyone to the "we did it" back patting phase makes everyone feel warm and cozy. Now combing through analytics to determine whether or not what we did was actually good? Less warm and cozy.
Remember that the first half of this statement, the part listed here, is great. I love playing with new tools.
The only bad part is the implicit bit after the dots: "we should use this in our product." You don't want cool things anywhere near your product, unless the cool thing is that they remove complexity.
As a /senior/ developer I really dislike blanket statements. I've seen the same amount of failures caused by > “Do we really need that?” > “What happens if we don’t do this?” > “Can we make do for now? Maybe come back to this later when it becomes more important?” as with experimenters. Every system is different, every product is different. If I were building firmware for a CT scanner, my approach towards trying out…
As a /senior/ developer I really dislike blanket statements. I've seen the same amount of failures caused by > “Do we really need that?” > “What happens if we don’t do this?” > “Can we make do for now? Maybe come back to this later when it becomes more important?” as with experimenters. Every system is different, every product is different. If I were building firmware for a CT scanner, my approach towards trying out…
I think you may be missing the message the OP is trying to communicate. The qualities were highlighted because they can all lead to better stability.