I tend to visualize call trees. Much of my refactoring is manipulating the call tree--flattening it, re-extracting subroutines, moving expressions up & down.
Another non-symbolic style of thinking I use is kinesthetic synesthesia. I "feel" the design "lean" in one direction or another, then refactor in that direction.
Seriously, thank you for that feedback. While the current generation of developers has heard of my work, they don't necessarily associate it with me. Establishing credibility would amplify what I say.
I agree about the importance of alignment. The recent evolution in my thinking is to take into account the power differentials between the folks who need to be aligned. As The Boss it's easy to say, "Everyone should be aligned," without seeing the incentives you are creating for folks not to align. And then fuss about their lack of alignment.
This is a 40-year-old mystery for me--why is it so very hard to get agreement about when & how much to design. Moving too much of the design too soon doesn't work. Moving it too late doesn't work, not in the long run. But why is everyone so completely dissatisfied with every possible option?
Fear vs greed seems like a pretty good model. Gives me somewhere to go next, anyway.
They're convex--small investment, small chance of a large return. Also, I've been curious what mechanism will fund creators creating & NFTs seem like a contender.
BadCookie, you and I have different constraints. The way you're thinking about accumulating assets makes sense given a child who will need assets and can't accumulate them themselves. The way I'm thinking makes sense given that my 5 kids are all launched and responsible for their own finances. (I invested in all of them--it's not like I just kicked them out at 18.)
My first reaction to your comment was defensiveness. When you explained how your situation differs from mine I realized you had just over-stated. Happens.
I wish you and your child well. A permanently dependent child is a tough position to be in.
That would be the "belligerent asshole" interpretation, one that I applied for the first 10 years of my career.
As an engineer, I often have intuitions about what I should work on. I'm saying those intuitions are valuable. Exercising my intuition improves my ability to choose priorities. I am still responsible for results, which is why I am not saying, "Do whatever you want. Nobody can tell you what to do." Someone is paying your salary for reason and at the end of the day you'd better be able to justify your salary or it will stop (again, voice of experience here).
As a manager, I need to accept that I will have intuitions about what to do next but that people who report to me will also have intuitions and theirs may not match mine. I need to choose carefully when to insist on my priorities because a) I can easily be wrong and b) specifying too much evaporates motivation. I generally get the best results by communicating what clearly, but leaving wiggle room.
If you think that engineers, given their druthers, pick the easiest things to do, then you talk to different engineers than I do.
Don't. Most side projects aren't worth investing heavily in, but you can't tell which is which without trying them. I had started hundreds of programs before Erich Gamma and I programmed together. If I had forced myself to "stick with" one of those early projects, we wouldn't have written JUnit.
Hang on a minute. I'm both Superprogrammer and a washed up old has-been? This is getting confusing.
There's no shame for me in using integration tests. They just hint at an alternate universe where the design is different and they either disappear entirely or become unit tests. So today isn't the day that happens. Okay. "Perfect" is a verb.
There's a challenge finding the right headline when posting to HN. My last few posts had very literal headlines and went nowhere. I amped this headline up a bit while making sure it was still honest and, looky here, it got more attention. Now I have to decide how I feel about the difference.
Thank you for letting me know how I appear to you. I don't agree that my point of view is obsolete or that I am not entitled to an opinion about design. Judging what I write based on my age led to you, as other commenters have pointed out, missing the point of my post.
Your point about up-to-date examples is well taken. Finding good examples is the hardest part of technical writing for me. As I work on Facebook and Instagram I will keep my eyes open for clear examples of the same principles, because the principles really are the same regardless of shifts in technical fashion. You'll have the opportunity to learn that in the years to come.
My skill/specialization visualization is the paint drip model (generalization of T). You're adding a little of this skill, a little of that, one catches your eye and you dive deep for a while, then a little of this, a little of that.
I assumed that readers had one strong skill already, hence the emphasis on broadening.
tl;dr You can make content so bad that it won't spread, but you can't make it so good that it is certain to spread. Virality grows at the confluence of skill, timing, and luck. Be aware when you've hit the point of diminishing returns on quality and publish.