unfocused828

This seems like a mixture of

A. Relying on geometry and visual metaphors, which seems fantastic from a history-of-mathematics and a visual-working-memory point of view.

B. Encouraging kids to see themselves as mathematicians, which seems healthy.

C. Randomly thinking "kidz these days like tiktok. Put something about that in there." which seems superficial and imposes a lot more work.

I feel like we let new engineers down by not guiding them toward resources where they can improve their social/writing skills.

Where is the brilliant.org for social/emotional/communication skills?

Social skills are presented as an obvious thing and the lack thereof is grounds for ridicule and derision rather than pointers to resources. (Note: How to win Friends and Influence people is a good base, but the Harvard Negotiation Project has many more good books. Also, Charisma on Command is a great youtube resource)

We have them be taught writing by literature majors who insist there’s some meaning to blue curtains but can’t be bothered to explain why or what the principles behind making that judgement are. (Note: a great explanation of how symbolism works can be found by putting “extra credits symbolism” into google)

I disagree that writing is undervalued. I think that writing is highly valuable and highly rewarded...but that the path to overcome challenges with writing is bafflingly mysterious. Does anyone know of a therapist who has experience helping people overcome writing anxiety?

I genuinely don’t know how to find one. Therapist-shopping is baffling.

I ask this as a software engineer who can produce pretty solid writing if given enough time but for whom doing so prompts thoughts of severe self harm. I was pushed to resign from my last job as a result of handing in a nearly-blank self-evaluation during my company’s performance review process, so I’m willing to spend... I guess up to $8k, (maybe more? Anything’s better than suicide to be honest. I love life in general and suppose it would be rational to spend half my income to eliminate the risk of it) On getting this finally solved after 2 decades of occasional agony.

As someone on a PIP who is quite sure the problem is on my side, not the company's, I wish there were mentors that a software engineer could hire to help you figure out how to debug problems with his/her job performance.

(Using an alt account for obvious reasons)

One thing I wish that I had been prepared for out of university is that there is just a lot less feedback on how good of a job you're doing. Nobody grades your work and there is a skill to getting specific feedback on your performance.

Asking "how am I doing?" at a weekly or fortnightly 1-on-1 isn't going to get you anything useful. You need to ask someone you're working with directly and frame a question in terms of situation-action-?impact?. So "When you submitted that PR and I pointed out two cases that I thought could use additional tests, was that useful?"

I realize that was unclear. No, I'm talking about psychological issues, probably with some social anxiety on the side.

I wish I knew how to find an occupational psychotherapist who specialised in working with programmers/sysadmins/engineers and who practised either in London or over video/email.

> caused by not knowing the technology/tool well enough.

Yes. But given the average quality of documentation and the fact that the most common advice for how to learn a new technology is just to build something with it, how uncommon is this?

> Don't worry about it

As an engineer who has been fired twice for performance problems, I don't have that luxury.

> Break touch tasks down into very, very laughably small tasks.

This works well if you've used the technology/tool before and you feel like you understand what you are doing. It is very difficult if you are in the circumstance of having to learn things as you go and having to prodding at things and trying things to figure out how things work. In cases like these, it is better to just figure out what the smallest first step is and iterate that way.

Unless of course you have the breathing room to spend time working through a tutorial on whatever set of abstractions you are trying to work with.

I'm always on the lookout for good books on effective communication. Ones that I've read and found insightful include:

- How to Win Friends and Influence People

- Difficult Conversations

- 5 Dysfunctions of a Team

I also bought Miscommunication by C. David Mortensen, but I haven't been able to get through more than a few pages because of how dry it is.

I suspect I need something more specifically focused on how to build mentorship relationships. Anything come to mind?

> break the task down into smaller and smaller bits

One problem here is that if I don't really know everything the task entails, then I end up asking myself "am I going to really need to do this?" and can't think of a way to answer that question without writing code. Maybe the right approach here is to accept this and to write a few automated tests for external APIs.

Another is that I just need to be disciplined enough to do this consistently.

I do probably need to spend more time figuring out the root causes, though perhaps that is better done by talking with a friend rather than just thinking things over by myself. My current understanding is this:

* When I'm confused about what a task really entails or what tools I can use and I try to get people to resolve that ambiguity, I sometimes cannot persuade them to do so.

* Sometimes I don't recognize that I lack the knowledge/documentation to do something and instead approach it with an "I'm smart and resourceful; I'll figure it out" attitude. By the time I convince myself that I need to ask for help, I'm embarrassed about not having made progress.

* I've gotten feedback that I "try to understand the universe" when debugging an unfamiliar system. That I should be more focused in my search. The difficulty here is that, when I'm working with an unfamiliar system, I don't know the lay of the land and so I end up spending a long time trying to get a sketch of a mental model of it because, well...how else could I solve problems?

* As my username suggests, I get distracted easily and sometimes find myself losing 5+ hours to distraction. I've been able to fight this to some degree using SelfControl.app and by making sure I get good sleep.

* I don't know how to come up with task estimates that have any relationship with reality. I've said "I don't know how to give software timeline estimates", but often get pushed to give a number anyway. I really really hate lying to a coworker/supervisor's face and wish I could find a way avoid it. I've tried to learn how to do estimation and bought a book on it, but all of the advice seems to focus on projects on a months-long scale rather than things that should take a couple hours.

I do probably need to spend more time figuring out why I was fired. My current understanding is this:

* When I'm confused about what a task really entails or what tools I can use and I try to get people to resolve that ambiguity, I sometimes cannot persuade them to do so.

* Sometimes I don't recognize that I lack the knowledge/documentation to do something and instead approach it with an "I'm smart and resourceful; I'll figure it out" attitude. By the time I convince myself that I need to ask for help, I'm embarrassed about not having made progress.

* I've gotten feedback that I "try to understand the universe" when debugging an unfamiliar system. That I should be more focused in my search. The difficulty here is that, when I'm working with an unfamiliar system, I don't know the lay of the land and so I end up spending a long time trying to get a sketch of a mental model of it because, well...how else could I solve problems?

* As my username suggests, I get distracted easily and sometimes find myself losing 5+ hours to distraction. I've been able to fight this to some degree using SelfControl.app and by making sure I get good sleep.

* I don't know how to come up with task estimates that have any relationship with reality. I've said "I don't know how to give software timeline estimates", but often get pushed to give a number anyway. I really really hate lying to a coworker/supervisor's face and wish I could find a way avoid it. I've tried to learn how to do estimation and bought a book on it, but all of the advice seems to focus on projects on a months-long scale rather than things that should take a couple hours.

> the company will find it very hard to fire you because of the signal it sends.

I'm skeptical of this for a few reasons: I've done this at the previous jobs but to not much avail. Also, it isn't sustainable. Also, that sort of signal doesn't cut costs or add revenue, so why would it convince them to keep me on. It might make it more emotionally difficult to fire me, but firing someone is already emotionally difficult.