291–300 of 361 posts
Because the most important parts of the expertise are coming from their internal "world model" and are inseparable from it. An average unaware person believes that anything can be put in words and once the words are said, they mean to reader what the sayer meant, and the only difficulty could come from not knowing the words or mistaking ambiguities. The request to take a dev and "communicate" their expertise to anoth…
A non-trivial part of the big difference between the juniors that seem talented and "get it", and those that don't is precisely their ability to form accurate enough world models quickly. You can tell who is going at the "physics" of software and applying them, and who is just writing down recipes, and doesn't try to understand the nature of any of the steps. It's especially noticeable when teaching functional progra…
Besides OO -> Functional this applies everywhere else in Computer Science. If you understood the fundamentals no new framework, language or paradigm can shock you. The similarities are clear once you have a fitting world model.
Because the most important parts of the expertise are coming from their internal "world model" and are inseparable from it. An average unaware person believes that anything can be put in words and once the words are said, they mean to reader what the sayer meant, and the only difficulty could come from not knowing the words or mistaking ambiguities. The request to take a dev and "communicate" their expertise to anoth…
A non-trivial part of the big difference between the juniors that seem talented and "get it", and those that don't is precisely their ability to form accurate enough world models quickly. You can tell who is going at the "physics" of software and applying them, and who is just writing down recipes, and doesn't try to understand the nature of any of the steps. It's especially noticeable when teaching functional progra…
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 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.
I read the above as "avoid development that increases complexity needlessly" — and often, there is a desire to overcomplicate something that can be much simpler because the understanding is lacking.
"As much as they can" does not mean trying not to do any work, but trying to simplify the work where it achieves desired outcomes, and just about! This frequently means doing the improvement today.
I was given a chance to redesign and it and when I failed to add the added complexity I was let go.
To this day I reckon the higher ups are still having the same age old problems and excuses from their underlings regarding a system that has an utterly useless design. The guy in charge, rarely in the office, calmly explaining its a fantastic implementation, the new coders we are getting just cant work with it / operate it well because they suck.
I am not bitter, if anything it just made me terrified of being C-suite of any large company, knowing it would be almost impossible to understand why your company is failing.
This is just an assumption and the whole article falls flat if this turns out to be wrong. In my limited (as everyone else's) experience, working with agentic AI needs good documentation, good specification (spec driven, you know it's all the hype nowadays). Those alone lead to much improvement. Now take into account that probably your senior dev also has more time to think about the big picture, to improve all those little things that were a nuisance in the past but now are a mere "Claude, fix that" in a worktree away.. I would not bet on the assumption of this article.
Earlier quoted context omitted.
I've always had excellent model building functionality for abstractions and got the "physics" of a subject rather quickly, be it economics, biology, certain mathematical subjects and more. Then, I met software and computer science abstractions, they all seemed so arbitrary to me, I often didn't even understand what the recipe was supposed to cook. And though I have gotten better over time (and can now write good solu…
your "physics" grounding is exactly why it feels so odd - software is by its nature anti-physicalist math and logic are closer to a basis for software abstraction - but they were scary to business people so a "fake language" was invented atop them - you have "objects" that don't actually exist as objects, they are just "type based dispatch/selection mechanism for functions", "classes" that are firstly "producers of t…
I do not think OOP ever really worked out well as can be evidenced by it no longer being as popular and people having almost entirely abandoned "Cat > Animal > Object" inheritance hierarchies.