I think this depends greatly on the product area and ease of updating. Removing problems categorically from designs early has been valuable to me in the past to reduce surface area, avoid impossible refactoring, and eliminate systemic bug classes.
> Exactly, that's what leads to partner hopping until these multiple digits are reached most likely.
I oversaw the last two words, apologies. Without them the sentence would be logically wrong, the worst kind of wrong ;) They signal that it's up for debate, sorry. Logic pedant out.
I'm unconvinced that "talking through your emotions" makes sense or is wise.
Both "talking" and "emotions" developed in central nervous systems at times far removed from each other, and there's little reason to believe that those software systems are connected... or even compatible.
People without internal dialogues (I'm one myself), don't require "thinking out loud" at all.
Internal dialogues aren't even thinking... it's when this particular faculty of your mind, the "rehearsal simulator" is overactive. Functioning correctly, you can bounce questions off of a fictionalized version of someone and get back replies that can be a useful prediction of what they might say when confronted in reality.
Those whose rehearsal simulators malfunction end up simulating themselves, who then goes on to start jabbering constantly, like some documentary narrator on crack, until they can no longer think at all.
We (those of us who can actually think) have a pretty good idea how this faculty even works. The principle seems rather similar to the LLMs we've all been talking about... it just predicts the most likely word that comes next, with some pseudo-random seed to start it all off. People with the "internal dialogue" only seem able to "think" of things, once everyone has talked about it enough that it amounts to training their LLM with it. When people without internal dialogues try to explain a new idea to them, they tend to respond in ways that indicate their thinking is much like how the LLMs function. Irrational, confused, denialism.
I don't particularly trust self-reporting, but maybe MRIs can empirically measure whether someone has an internal dialogue or not? I would be curious to see the IQ differences between the two groups. It's probably a massive gap. The rehearsal simulator starves the rest of your brain of resources while active. If you ever learned to turn yours off, you'd probably never want it turned back on again.
For instance, someone who does the internal dialogue thing may not even be able to correctly report their emotions. They may not recognize them at all. Instead, that little LLM in their skull is just "hallucinating" for them, coming up with plausible sentences for how someone might feel, based on training data they've accumulated over the years, but having absolutely nothing to do with their emotional state. Anyone who accepts their self-reported emotional state as correct can be very confused by it... visibly, they're in one emotional state, but verbally they're reporting something completely different. There's no reason to suspect dishonest reporting, but also no real way to reconcile the contradictions.
I have been working the past 3 years to turn off my internal dialog because I was only using it to stroke my own ego in a way - imaginary conversations with my boss where I can always respond/counter/defend whatever he MIGHT have to say to me about something. These conversations never occurred in real life, so I realized how senseless it was to devote my attention and energy to something so detached from reality.
I am no worse off for not "thinking things through" in my mind, because I tend to get sudden imprints of what I need to do or say next which are not a serial monologue of thoughts that guide me to understanding. On the other hand, I have been working on categorizing and actually processing my emotions as they are occurring, rather than ignoring them entirely, and many times I do need to have an external, verbal monologue for my subconscious to piece together all of the things it knows implicitly in bulk, but not explicitly as a single coherent concept.
One thing that does come and go is some sort of background music in my head, which also doesn't limit my ability to think. Finally, cannabis CAN give me that "serial monologue in my head" kind of thinking, which I have come to consider a mild "brain vacation" - especially if I am overwhelmed with stress or anxiety.
Another thing is tune whistling/singing, when you think about it it is even more basic then language, just "predicting" the next note in a sequence of notes one already has stored in memory, so pointless, yet objectively satisfying for some reason. I often sing/whistle in the background, I've found it only reduces my ability to think when it gets in the way of what I perceive to be low value work, I think this is due to it being a very low energy, low value activity, whereas similarly low value work may be higher energy, and so it becomes unbearable to stay focused on the work without reverting to a lower energy activity, rather then the internal music overcoming the work. As I acquire further high value work, and surround myself with people who would rather not hear whistling/singing, this habit has decreased considerably. It may be the case that such internal monologues or LLM like activities are not as low energy straight thinking, but maybe they serve some kind of "idling" purpose, reinforcing pattern/logic/computation/memory pathways in the brain, for cheap.
Out of curiosity, have you ever been kept up awake at night by your thoughts, either before an important event or after some problem? If yes, and you have no internal monologue, how does this manifest? Do you simply not feel tired? Or do you feel tired but unable to sleep? Or otherwise?
It’s not life or death, but time spent dealing with errors - debugging, the direct effects, understanding full impact - isn’t a resource we can get back.
It's funny you say that, because designing systems that work extremely well, have contingencies upon contingencies, and can be relied upon (e.g. as a life-critical system) is so time consuming and (I imagine) mind numbingly boring (e.g. reviews upon reviews of white papers to ensure that the system spec is scientifically sound) that I'd guess time is the last thing you'd get back from writing NASA-style applications.
I find myself thinking about that a lot - mainly "how many more hours would have needed to be spent at stage A to avoid the hours being spent now to recover from problems our software is currently causing". And often if I'm honest with myself it's hard to see that the extra investment of time earlier on would have necessarily resulted in a net productivity gain. It would however likely be a less stressful way to work (building fire-proof code rather than putting fires out all the time), and rather more satisfying. As an engineer of any sort I think it's perfectly reasonable and justifiable to want to produce something of quality even if it takes longer and the consequences probably won't be that terrible if you just release the first thing you can slap together. Unfortunately others are almost entirely motivated by the (not entirely irrational) fear of what happens if you don't release something quickly enough.
Thank you for asking this, it helped tease out and crystalize some thoughts I’ve had about the difference in tenor between computer programming and software engineering. I hope these off-the-cuff answers help explain why this doesn’t feel quippy to me; they are specific in scope but those scopes are common.
—
Write clear error messages that provide a way forward. Accept your system will have bugs, and ensure the system state is communicated to the user so they know if their TODO/Test/Reminder/Wish was stored/updated/deleted. Do your utmost to prevent data loss - even when that data hasn’t been formally introduced to your data storage of choice.
Developers should not worry about their sprints being blown because they have to use your APIs. Teams trying to pass off tasks or getting special commendations for dealing with your software should be embarrassing. If developers are wrapping your API in their API, are they doing it because they need the abstraction or because abstracting it once and tracking changes is easier than using it?
Ensure there are logs in place to assist debugging and documentation catered towards end-users, operations, support, and developers. Track relevant metrics to allow for automated fixes and manual intervention so users aren’t the ones having to remind you your software is broken.
Every piece of software has a user - a person, an organization, other code - and software that doesn’t make the user’s life easier increases the chance they’ll stop using it.
(c) could be re-written as “If you’re going to give gifts, make them personally meaningful and not generic.” I think this advice is most relevant when you’re doing personal, one-on-one concierge or consulting. When you have lower contact rates with people, small things such as this reassure that they are not “out of sight, out of mind”. Your mileage may vary based on your role, employer, and field :)
The forum (as well as ‘stage’ and ‘announcement’) feature requires changing to a “community” instance which has some other strings attached. AFAICT long-running servers would never know the new setting is available.
It's not what Facebook does that the others don't, in my opinion, it's that Facebook does not have services for businesses. They have scant little utility to businesses outside of advertising services to temper their outrages with, so they're given even less of a benefit of the doubt than other tech companies.
