Hi everyone, my name is Jeremy Friesen, pronouns are he/him,
and today I'll be talking about
mentoring VS Coders as an Emacs-ian.
A little bit of background, since 2015, I've mentored
about 40 software developers,
many of them in career-transitioning roles,
oftentimes from boot camps.
I've also managed a couple of small software development teams.
So I want to think about mentoring and the framing approaches.
We all don't know what we don't know.
So while mentoring, I like to be curious---asking questions,
I like to be visible,
and I also like to pair so that we can share.
When I start, I like to ask the following type of question:
"What have you been wanting to learn more of,
get better at, and improve on?"
Then I like to ask further questions to get an understanding
of where they've been, where they're going,
and what they'd like to achieve.
Later I'll ask coaching questions, "what's going well,"
"where are you getting stuck,"
and "if you change one thing, what would it be?"
So like many people, I shifted to remote work in 2020,
and I've noticed a higher collaboration in remote work,
when folks make their work visible.
So to do that I host office hours,
I try to attend other people's office hours,
and I'll open up a Slack huddle and just code by myself,
but let folks know, please hop in.
I like to pay attention to other huddles that start.
If they're going still for, like, 45 minutes or so,
I'll hop in and say hello.
It's even odds that they're moving along just fine
or that they're stuck.
So by hopping into the Slack huddle,
I'm helping with a common problem.
How do you know when you're stuck?
This is something that---as a manager---folks want to know,
how can I get unstuck faster?
As a human, it can be frustrating to be stuck for a long time,
but you also learn stuff
when you're dealing with the hard things.
So you really need to balance that time,
and I find hopping in, just being a gentle presence,
with yes... an agenda, but just to say hi,
is crucial to help the team members move along.
Pairing is for sharing.
When I pair, I like to let others drive.
They're typing and working to resolve the problem.
I'm giving guidance, asking questions,
maybe thinking through a refactor.
I'm also spending time observing how they interact with their editor.
In the moment, I try to limit advice to, like, one concept.
A lot of folks don't know that `Control-a`
will take you to the beginning of line.
Just sharing that is huge sometimes.
Just gently do it and let it float there.
And assuming we have a regular mentoring session,
I'll make sure to ask how they're feeling
about using their tools afterwards.
I would love to get to the point where they ask,
"You saw me using my editor, what is something
I could learn?"
I'm working on getting to that point.
While pairing, I like to pay attention
to how folks handle the following.
Where do they want to go?
How do they get there?
Here they are, now what?
How do they summarize?
I know what I can do in Emacs,
and I assume that VS Code can do something similar.
It's a matter of helping the mentees find those packages and plugins.
Where to go?
Search within a project.
Everybody knows about this, but one thing
that has been really critical for me
has been the arrival of `Orderless`.
A little quick demonstration.
If I look, and I have this "chicken" and I do "spell",
I have found one, and they don't have
to be in the right order.
In fact, I can go back, and "spell" is there.
Super easy, helpful, so I don't have to think about it, the order.
Search across projects.
Cross-repository searching is super-simple in Emacs,
and I've never seen anyone do it in VS Code.
I'm also trying to introduce folks to command-line tools
such as RipGrep and SilverSearcher,
not just to look in the project, but to go one directory up
and look across projects
because sometimes when you're working on lots of different projects,
there might be solutions or ideas that come from there.
Also notice that a lot of people use directory trees to navigate,
but I favor the fuzzy text.
So I can do something like `Command-t`
and start looking for things in there.
I just type the name of the file.
I use `consult-projectile`,
which has a lot of really cool functionality.
The big one being I can type `r`, recent file.
I can type `p` and jump to a different project,
so it's a quick navigation tool that I've not seen in VS Code.
Next up is how do they get there?
I like to use LSP for the languages,
and I bound `M-.` to this
and jump back and forth to definitions.
I just showed `projectile` or `consult-projectile`
and its super-amazing multifunction finder.
Also another one that I am very avid about
is the jump between definition and test.
I bind that to `Super-.`
and it helps me jump back and forth
between my production code and my test code---
especially in Ruby, there's an idiom for that.
There is plugins in VS Code that does this correctly.
Next up, now I'm here, what do I do?
Word completion, Emacs just knocks everything out of the park:
`dabbrev`, `templates`, `hippie-expand`, `completion-at-point`.
Sometimes it just hurts to watch people type stuff
that they could quickly expand
because there are words within the code.
Another one is auto-formatting.
Tree sitter...its arrival is great.
I assume this is going to get better.
I love highlighting a region, hitting `TAB`, and it's just formatted.
I've seen a lot of VS Coders... that doesn't work for them.
Don't know why, trying to get them to see it.
Multi-cursor [`multiple-cursors`] and `iedit`...
took me a long time to explore `iedit`,
but the practice... but practicing was huge,
and it has transformed my approach to coding and typing.
Folks know about multi-cursor editing and editing-in-region
but make sure that they are aware of it.
It's important.
Next up is inline searching.
My beloved Textmate... it was the first thing.
In fact, it was why I chose not to use Emacs in 2005
and went with Textmate.
This is something quite simple.
I can do `search` within here, and I can see "introduced",
and it will show me the line.
What I like about that is when I'm in code,
I can see the neighborhood of other things
and get a good idea of what's around.
Yes, there is `occur-mode` that can be super useful,
but I'm used to the Textmate in it.
I just love it.
Next up is how they summarize.
I've seen a lot of bootcamp graduates write commit messages
by going to the command line.
In my experience, commit messages written in the command line
tend to be terse.
They miss something.
So I try to really quickly shift folks to use their text editor,
encourage them and
teach them about `$GIT_EDITOR` and `$EDITOR` for the environment variables
so they can make their commits from the command line.
And if not there, help them improve how they do VS Code.
My little screed at the top:
the interface for VS Code's commit is trash.
It is why I stepped away from VS Code when I was exploring editors.
Next up, my goal is to encourage folks to use editors for writing,
to think about owning that tool.
I have them try to learn one thing a week.
Maybe they aren't going to learn it,
but just not to overwhelm them
and find those high-value things.
Jump to spec, jump to code... super-valuable
because I see folks doing it a lot during the day,
and it can really speed up the transition time
and keep the focus between the test...
what you're trying to test and what you're trying to define,
which can get lost if you do the tree navigation.
Also I encourage people to practice their domain knowledge.
I learned a lot about programming by doing a bunch of things
related to RPGs---role-playing games.
I did this previously in Ruby---dice rollers, note takers,
random table lookups---and now I'm doing it in Emacs.
Knowing the domain helps me set aside the problem space
and then explore how I code
and how I can implement things differently.
Note-taking: pay attention to how folks create a fleeting note.
It can be excruciating as they try to figure out
"where am I going to put this?"
"What file?"
"Where does it go?"
Emacs, we have the *scratch* buffer or anything else,
but ask them about their note-taking habits
and help them navigate the proprietary software tar pits.
We know that anything that is venture-capital funded
will eventually collapse.
We know that things that don't have a sustainable business model
without surveillance capitalism
is going to also have problems.
Encourage folks to think about how they're owning their notes.
Do they place true value on those,
or are they things that are kind of ephemeral?
And then help them find the thing that makes sense for them.
Put another way, I want people to think holistically
about their generalized "computering" environment.
And I also think about the reason why
I've stayed a software developer for 25-years plus
is because I approach all of this as play and storytelling.
Sometimes happy byproduct is that I ship features and documentation
and help people get stuff done.
Yet I don't tell folks to use Emacs.
Instead, I'm doing my best to show a myriad of reasons
for why folks should consider Emacs.
In conclusion, ask questions.
Find a person who is a VS Coder and just say,
"hey, I learned something new."
We play this game all the time, me and my coworker Kirk.
I love it.
Another goal is showing the malleability of Emacs,
how easy it is to extend.
And obviously there's so much more than what I've highlighted,
but then again, that's Emacs.
Thank you, and I look forward to your questions.