I agree with this. However memorizing the borrow checker rules has led me to architect code “more correctly” upfront and consider things like ownership that I was otherwise pretty lax about ahead of time before. I think this has made me more thoughtful even in other languages which I think has been a win for me.
That said, the tedious refactors are a real pain. I think we all hoped that rustc would be smarter by now. It has gotten better but it isn’t there yet.
This is ludicrous. The point of Z2 is a specific physiologic adaptation. There isn’t really any mental pain. Anything you can do to make your training more consistent is positive for your long term performance. Save the mental gymnastics for the actual hard days.
Staying in a hard VO2 interval or pushing through on those long threshold efforts is an actual mental exercise. Don’t push the belief onto people that staring at a wall in Z2 is giving you some gains. If it works for you then go for it, but it’s a wild mentally that thinks a physically easy ride needs to be hardened up.
This seems to resonate with my experience, although I feel myself bristling due to the baggage of the word memorization.
Although sometimes “memorization” doesn’t happen because you sit down to do it but rather that you keep using the same things over and over when solving problems that they become internalized. I find that to be a more fruitful path towards understanding that I don’t want to call memorization but it is.
Maybe you should first try to separate the negative feelings you have towards the word "memorization" and the word itself "memorization". There's nothing bad about memorization. This sort of negative bias about inconsequential things is something that can easily hold us back from things that could help us further ourselves.
And agreed -- it's this exact realization that led me to both this method and title
Imo this negative connotation has made many people refrain from calling internalization what it is
But acknowledging that it's memorization has actually made me more efficient at learning, since I can now consciously look for the heuristic, codify it, and try to commit it to memory
I think this from your second link is closest to what I'm getting at:
> Somewhat confusingly, some companies use Tech Lead as a title, and others use it as a role. In this list of archetypes, the Tech Lead is one approach to operating as a Staff engineer, but it's quite common to perform the Tech Lead role without having the impact expected of a Staff-level engineer.
My point is a bit 'bigger' than how do you operate in your position as staff engineer and what does the org need from you, what I'm getting at is about the structure of roles themselves - like it can be that your technical track/ladder (junior/mid/senior/staff/distinguished/principal/fellow/whatever) is IC that managers are completely separate, not the same people (junior/mid/senior/whatever managers). It can also be that people managers are separate, but technical management of projects is intertwined with the more senior roles.
What I was thinking about specifically, not knowing really whether anyone does this or not, was the possibility of people being on at least one of those tracks, i.e. maybe both, but that they're distinct roles. So you might be a staff engineer but a more junior manager. (And you might manage a different team than you work in, I suppose, but that would probably be inconvenient and anyway isn't really important one way or the other here.) But I suppose it also depends how or if you divide technical and people management anyway. I just don't really have the keywords to find much discussing it; your links are good though, thanks, I'll read some more on the site.
Google has a title called TLM which is tech lead + manager which is meant to straddle the divide. In practice you have twice the expectations which are themselves conflicting with only the one salary. It is often used for ICs to try out management before making the decision which ladder to stay on. Most TLMs are at the staff level so kind of fits that staff engineer who is a junior manager that you describe.
Yeah I see that now on the site you linked, as well as in his book I think & Tanya Reilly's 'The SE Path' linked from its intro (that's all I can read before it arrives). Both seem helpful texts (I've ordered & have access to ebook resp.) so really appreciate the link, thanks.
> The distinction between the three types of errors can lead to the phenomenon ... of a mathematical argument by a post-rigorous mathematician which locally contains a number of typos and other formal errors, but is globally quite sound, with the local errors propagating for a while before being cancelled out by other local errors
I was initially amazed at this when I was in graduate school, but with enough experience I started to do it myself. Handwaving can be a signal that someone doesn't know what they are doing or that they really know what they are doing and until you are far enough along it is hard to tell the difference.
>Handwaving can be a signal that someone doesn't know what they are doing or that they really know what they are doing and until you are far enough along it is hard to tell the difference.
I found it's very easy to distinguish these two when you have another expert ask questions. But if you don't have someone like that in the audience it might take forever. Or at least until you become an expert yourself.
Good point. Here are some notes on it based on what I've observed happens in Academia and in other environments:
I think handwaving comes in different flavors:
- Handwaving and not knowing what they are doing, when they know they don't know:
This is arrogance and/or fear of people thinking you are a fool. Bad practice. Professionals who do this are status chasers and not fun to be around. Students who do this are mostly insecure, and they might just need some help with their self-esteem. Help them by letting them feel comfortable with being wrong. Foster a good environment so that the arrogance and fear fade away.
- Handwaving and not knowing what they are doing, when they don't know they don't know:
I believe this is a good thing, in particular for Students, if they are within a nurturing environment. It can lead to interesting ideas and to discussions of innovative ways to move forward. I believe this to be a way of actually "training your intuition muscle" both for Students and Professionals. It lets them know not to fear moving on, tackling the thing that captures their attention the most at first, and later on filling some of the gaps, which I feel is common practice for people who have been working on the field for a while. However, if the gaps are left unattended it can lead to bad things... Environment matters.
- Handwaving and knowing what they are doing, when they know they don't know:
For trained Professionals only... :)
This modality kinda kicks in when deep in mathematical work.
It's the path that leads to the Eureka moments...
Pure trained intuition acting almost as a separate entity to oneself. We are facing the unknown and something tells us that certain aspect can be handwaived, we don't fully know why but we feel it is. Later on it becomes clear why we could do the handwave. It works itself out.
- Handwaving and knowing what they are doing, when they don't know they don't know:
For trained Professionals only...
Kind of a stretch, but might be where our intuition either fails us completely, or completely takes us by the hand to turn the unknown unknowns into known unknowns, then it goes back to the previous category.
This isn't set in stone by the way, just some thoughts I had while reading the article...
Any ideas or suggestions for modifications more than welcomed.
I think it is primarily your last bullet point, it is less exciting to write about unless you really are looking for specifically that content. They are widely used but they are normal parts of a lot of architectures now.
That said, the tedious refactors are a real pain. I think we all hoped that rustc would be smarter by now. It has gotten better but it isn’t there yet.
reply