good Monday morning today I would like
to talk a little bit and muse a little
bit on something that I think is one of
the absolutely hardest things as a
software developer at least for me
personally and that is asking for help
so uh still here in Stockholm and I’m
gonna be for a while moving here we I
talked a little bit about how we are
going to do more of these live more
programming shows but that’s not gonna
start in awhile because we are still
looking for a studio space and in the
meantime there’s gonna be a lot of these
walking talks which I know a lot of you
like and I like doing them and I feel
like this month is a bit of a musing one
there’s like a start of the new year I’m
approaches to how asking for help and
giving help as handled in in software
teams and my experience like three
different ways we’re in three different
ways that I’ve acted and how the teams
are been in have acted and the first one
is basically as having no technique at
all in it like it’s basically when
you’re doing code archaeology and then
the new person he’s just thrown into the
code base we’re very little assistance
second I’m gonna talk about something
that I’ve come to refer to as a buddy
system where you’re assigned a person or
a mentor if you will that has some time
allocated to help you to figure out the
project and finally I’m gonna talk about
my personal favorite which is pair
programming and mob programming where
you actually sit with a person a more
senior person more familiar with the
code base all the time and that person
constantly assists
that’s what are we going to talk about
okay so first approach first approach to
help in a software team and it’s
basically no help or very little help
help when you’re desperate it’s it’s
when you’re doing what I refer to as
code archaeology this is this might
happen if you’re in a team that isn’t
very evolved in their software
development practices or if it’s a team
where like the person before you has
just quits or died or something and
you’re all alone in a new code base and
you have no idea what is happening
you open the the code base and you have
perhaps a task that you’re gonna do
perhaps it’s vague and you just try to
figure out wildly in the in the code
where is this thing and what is this
thing and you poke around a little bit
and you figure out like why is this
variable named it this way I have no
idea
can I change this without breaking
things and yeah it’s it’s no fun at all
there’s no and there’s no like overview
document or like unit test or anything
and you basically define things out you
if you’re a little lucky you can walk
around in their organization and try to
like kindly ask people that maybe could
you perhaps explain this piece of code
and they are like oh yeah yeah sure but
you’re sensing that oh god they’re
stressed with their own and now I’m
demanding their time and it’s just like
it’s an excruciating ly screwed
excruciatingly ly slow way of working
you’re basically doing archaeology it’s
it’s your work is not really productive
team work it’s more like you’re trying
digging out like an ancient civilization
with a little brush you have to do
everything so carefully all the time you
know like not in order to not break
these little pristine age and things
that you find inside of this
these ruins in ancient Egypt it’s it’s
not a fun way of working but we’ve all
been there it’s it’s something that you
sometimes have to do because well it’s
what the workplace is or that’s where
you are in your career or it’s sometimes
you just have to do this but this is not
good this is not how how a
well-functioning software team works the
more well-functioning teams that I
worked in have sometimes work with
something like a body system and
couldn’t move to another location talk
the buddy system is what it sounds like
you’re it happened to me the first time
I I don’t Spotify where I was assigned a
body which was named Martin that he he
turned out to be a good friend like
eventually over it Spotify as well it
was like such a super nice guy but the
the body is basically this person that
they have been allocate a located time
from their normal work duties to to help
you like they’re like yeah we know
you’re gonna help this new developer on
the project and we we are expecting you
to not move as fast as a result because
you’re gonna make yourself available to
them you’re gonna be interrupted all the
time and that’s the way it’s gonna be
and you are also and this is important
you are also expected to encourage your
new developer to interrupt you and to
ask you questions because I think it’s
very important here to address that it’s
not natural to want to ask questions
when you’re in a in a new position like
you you very much feel the need to prove
yourself that you can take care of these
things and that you won’t like I’m a
good developer I must like you might
even be a senior developer actually like
just because you’re new in a code base
or or a project or or perhaps a library
that you’re working on but you’re
unfamiliar with that you might be very
senior and in those cases it’s even
harder to ask for help sometimes because
you have worked for the in in this field
for so long or perhaps in this company
for so long and it just feels like you
should you should magically know it
which is absurd of course but that’s
what it feels like so you don’t ask for
help for you wait wave too long to ask
for help you just waste half a day to
figure something out that when you ask
the person they like they say like no no
you
couldn’t possibly have figured that out
it’s because this thing that happened
two years ago before you joined where
this customer asked for this and this
and this and you like okay now this
makes sense why you did it this way and
it’s it’s easy to fall into the trap
like of banging your head against things
for too long I mean I often talk about
how software development is about that
about solving that that software
development is about banging your head
against the problem till it breaks and
it’s a lot about tenacity but it’s it’s
also about also about asking for help
because there there is you cannot just
into it yourself into knowledge that
only exists in the heads of your
colleagues you don’t know the history of
the organization you don’t know the
general patterns used in this project
you don’t know that yet but your
colleagues might so make sure that you
use them even though it might be feel
unintuitive because you want to prove
you think it’s safe like they like he’s
walking with this kid over there all
right all right in case you didn’t catch
it yet we’re walking on the ice in the
middle Stockholm all right oh yeah the
buddy system so the body system is it’s
great it’s easy to implement and there’s
nothing wrong with it but I think that
the best best thing that I’ve always
experienced in all software projects
where that has always been absolutely
marvelous when I’ve done it is pair
programming and pair program for the
ones that you’re not from aren’t
familiar with it is when one person acts
as a navigator and one person acts as a
driver and the responsibility of the
driver is the one that is actually
holding the keyboard like has the hands
on the keyboard and type the code while
the Navigator is the person that is
keeping tabs a little bit more on the
direction and where you are in the
project and what you’re supposed to do
like that you’re not getting distracted
and like that person a little it’s a
little less focused on syntax and and
typing and more focused on architecture
and getting the task done and in the I
think it’s very very useful to have a
navigator that is familiar with the
project and the driver being the one
unfamiliar with the project and that’s a
very good way of being introduced to the
project like the Navigator can
constantly assist you in saying like
yeah now we’re gonna change like this
little part in the system and this
little part in the system do you think
that you can type it like figure out how
to do this here and like gradually
assist you through things and I find
that even even if you put a pair
programming inside and just talk about
the concept of code review code review
is one of the best best ways to
introduce people to a new code base like
I think that code many miss that
knowledge sharing is one of the greatest
benefits of code review like you’re
pushing like you’re a fix and then
people can say like yeah this is great I
understand where you thought this way
but we already have this library that
you can use to do this or this way of
doing it is great but it’s not idiomatic
to what we do in the project so if you
do it look at this part of the code you
can see how we did about how we do it in
the project and that makes it more
consistent and easier to deal with it’s
not that your height your way is bad but
it’s just nice to have things consistent
and have that kind of no one sharing if
you don’t do code review and your team
that doesn’t happen and one of the
nicest things about but pair programming
pair pair programming pair program is
that you’re doing code review all the
time all the time it’s happening all the
time every second and in the same way
pair programming also means that you’re
helping all the time in the in the
archaeology pattern you’re you’re
basically just asking for help at a
point where it’s like so obvious that
you have been stuck maybe maybe you’ve
been stuck for days and tell you you
actually go and get make time with it
where perhaps a lead architect or
something
it can waste a lot of time and the body
system is also I mean it can still take
a lot of time I mean I try to say that
when I have access to a body I still try
to
not interrupt them constantly I try to
like still have a little time limit on
myself like just arbitrary like 50
minutes or 30 minutes or 45 minutes just
like some kind of time box where I’m not
allowed I’m not allowing myself to get
stuck more than that and then I ask
because even though the person is is
allocated to me and have time allocated
to me I guess I can’t it’s it’s not
designed to allow me to interrupt them
at every single single point however
when it comes to pair programming you
have like this massive constant access
to a person where the person can help
you at any time I mean it’s still good
for the navigator to allow the driver if
the driver is new in the project to to
figure things out on their own for a
little bit like it it’s not a lot like
it’s not good to like basically type for
the person verbally like typebar like
that’s not good navigating but it’s
really good that to have a navigator
that it’s like okay you’re getting stuck
can I give you a hint and that is
marvelously productive when I’m doing
pair programming it is so extremely rare
to get properly stuck but properly stuck
I mean when you are just you have no
idea how Pro to progress you just you
have been staring at the code for
perhaps hours and you don’t know what’s
wrong you move things around and you
just don’t see the issue and then you
perhaps you just give up go home and
then you come back the next day and look
at it with fresh eyes or perhaps you
just have a co-worker over and have them
look at it and you figure out the
problem immediately because it was just
some little thing missing it just was
invisible to you it was obvious in
hindsight but yeah and with pair
programming I almost never find myself
in those situations it’s so
because the likelihood that two people
two different brains looking at the same
code that they would miss the same
problem is so incredibly unlikely and
it’s even more unlikely if you’re doing
mob programming where you have an entire
team being like The Navigators I haven’t
done that too much but it’s super cool
and yeah I like pair programming a lot
so those are the three things like the
three ways I think about when I think
about asking for help and giving help in
a software team like the the archaeology
pattern or technique where you you don’t
don’t really you don’t have access to
much help maybe like you just have to
like Oh as the senior architecture pay
me you can help me and but you feel bad
about it and then you have the buddy
system where you are allocated a person
and then you have the pair programming
system where like you’re actually always
sitting down with somebody more familiar
with the code that’s in you and you you
figure things out together in unison
finally I I would like to make a little
plea to software
it’s senior software developers or
rather people that are in in senior
positions that you’ve been in a company
for a while but when a new person joins
your team or your company or where some
Orban it might be a new develop new
developer a junior developer it might be
a senior developer helping out with the
project or something make sure that that
heard like that you make yourself
available to that person or assign
somebody to help that person and think
about how to get that person up to speed
as much as possible and don’t let them
don’t drop them like some archeology
person in
in the project and let them swim for
themselves that’s not a productive way
and don’t express any enjoyment when
they ask you about things encourage them
to ask things and when they do like say
like so good that you went to me and
asked about this that’s really good
don’t be that person who is annoyed even
if you feel like feel it you should
never express that because that will
discourage them and that will cause your
software team to be extremely
inefficient there will be a lot of waste
and if you disagree with this and if
you’re like if you feel feel that
annoyed when you’re if you’re being feel
like oh I don’t want to help this person
because it distracts me from my work and
my IR want to solve issues like I I have
some news for you like you’re not a you
aren’t a senior developer yet because
the role of a senior developer like one
of the most important roles and tasks
that you have is to make sure like to
lift the developers around you to make
sure that the the junior developer is
around you or getting productive and
getting up to speed and getting them
started because the the only way to
really be a 10x developer or a 100x
developer is to improve developers
around you you’re eventually going to be
limited in your abilities but when you
build a software an organization if you
are a person strengthening others then
then you are truly a person that can be
explosive in your productivity and the
value you add to an organization so make
sure that you help the people around you
that’s that’s the the true value of a in
this episode is sponsored by Kaka it’s a
little inline evaluation thing that you
often see me use in the episodes we are
very proud to be pushing them because I
yes love it as a product it’s great when
you just try not in prototyping things
or when you are running a YouTube
channel and you want to just show
quickly show like things how JavaScript
evaluates it’s really great if you want
to check it out you can check it out at
quad fun fun function calm so that they
you know that you came from here you can
also see me using it and this video here
to check it out and have a feel for for
how it works it’s really right quad fun
for function calm and that’s it for
today I hope that was useful to you like
that
did you disagree did you agree how do
you have other approaches to helping
people what’s your experience and your
career with help please type it in the
comments I read all of them you have
watched an episode of fun fun function I
release these every Monday morning Oh
800 GMT but you will forget that so make
sure that you subscribe or watch another
episode right now by clicking here if
you’re unsure bye mmm PJ until next Monday morning thank you
to talk a little bit and muse a little
bit on something that I think is one of
the absolutely hardest things as a
software developer at least for me
personally and that is asking for help
so uh still here in Stockholm and I’m
gonna be for a while moving here we I
talked a little bit about how we are
going to do more of these live more
programming shows but that’s not gonna
start in awhile because we are still
looking for a studio space and in the
meantime there’s gonna be a lot of these
walking talks which I know a lot of you
like and I like doing them and I feel
like this month is a bit of a musing one
there’s like a start of the new year I’m
approaches to how asking for help and
giving help as handled in in software
teams and my experience like three
different ways we’re in three different
ways that I’ve acted and how the teams
are been in have acted and the first one
is basically as having no technique at
all in it like it’s basically when
you’re doing code archaeology and then
the new person he’s just thrown into the
code base we’re very little assistance
second I’m gonna talk about something
that I’ve come to refer to as a buddy
system where you’re assigned a person or
a mentor if you will that has some time
allocated to help you to figure out the
project and finally I’m gonna talk about
my personal favorite which is pair
programming and mob programming where
you actually sit with a person a more
senior person more familiar with the
code base all the time and that person
constantly assists
that’s what are we going to talk about
okay so first approach first approach to
help in a software team and it’s
basically no help or very little help
help when you’re desperate it’s it’s
when you’re doing what I refer to as
code archaeology this is this might
happen if you’re in a team that isn’t
very evolved in their software
development practices or if it’s a team
where like the person before you has
just quits or died or something and
you’re all alone in a new code base and
you have no idea what is happening
you open the the code base and you have
perhaps a task that you’re gonna do
perhaps it’s vague and you just try to
figure out wildly in the in the code
where is this thing and what is this
thing and you poke around a little bit
and you figure out like why is this
variable named it this way I have no
idea
can I change this without breaking
things and yeah it’s it’s no fun at all
there’s no and there’s no like overview
document or like unit test or anything
and you basically define things out you
if you’re a little lucky you can walk
around in their organization and try to
like kindly ask people that maybe could
you perhaps explain this piece of code
and they are like oh yeah yeah sure but
you’re sensing that oh god they’re
stressed with their own and now I’m
demanding their time and it’s just like
it’s an excruciating ly screwed
excruciatingly ly slow way of working
you’re basically doing archaeology it’s
it’s your work is not really productive
team work it’s more like you’re trying
digging out like an ancient civilization
with a little brush you have to do
everything so carefully all the time you
know like not in order to not break
these little pristine age and things
that you find inside of this
these ruins in ancient Egypt it’s it’s
not a fun way of working but we’ve all
been there it’s it’s something that you
sometimes have to do because well it’s
what the workplace is or that’s where
you are in your career or it’s sometimes
you just have to do this but this is not
good this is not how how a
well-functioning software team works the
more well-functioning teams that I
worked in have sometimes work with
something like a body system and
couldn’t move to another location talk
the buddy system is what it sounds like
you’re it happened to me the first time
I I don’t Spotify where I was assigned a
body which was named Martin that he he
turned out to be a good friend like
eventually over it Spotify as well it
was like such a super nice guy but the
the body is basically this person that
they have been allocate a located time
from their normal work duties to to help
you like they’re like yeah we know
you’re gonna help this new developer on
the project and we we are expecting you
to not move as fast as a result because
you’re gonna make yourself available to
them you’re gonna be interrupted all the
time and that’s the way it’s gonna be
and you are also and this is important
you are also expected to encourage your
new developer to interrupt you and to
ask you questions because I think it’s
very important here to address that it’s
not natural to want to ask questions
when you’re in a in a new position like
you you very much feel the need to prove
yourself that you can take care of these
things and that you won’t like I’m a
good developer I must like you might
even be a senior developer actually like
just because you’re new in a code base
or or a project or or perhaps a library
that you’re working on but you’re
unfamiliar with that you might be very
senior and in those cases it’s even
harder to ask for help sometimes because
you have worked for the in in this field
for so long or perhaps in this company
for so long and it just feels like you
should you should magically know it
which is absurd of course but that’s
what it feels like so you don’t ask for
help for you wait wave too long to ask
for help you just waste half a day to
figure something out that when you ask
the person they like they say like no no
you
couldn’t possibly have figured that out
it’s because this thing that happened
two years ago before you joined where
this customer asked for this and this
and this and you like okay now this
makes sense why you did it this way and
it’s it’s easy to fall into the trap
like of banging your head against things
for too long I mean I often talk about
how software development is about that
about solving that that software
development is about banging your head
against the problem till it breaks and
it’s a lot about tenacity but it’s it’s
also about also about asking for help
because there there is you cannot just
into it yourself into knowledge that
only exists in the heads of your
colleagues you don’t know the history of
the organization you don’t know the
general patterns used in this project
you don’t know that yet but your
colleagues might so make sure that you
use them even though it might be feel
unintuitive because you want to prove
you think it’s safe like they like he’s
walking with this kid over there all
right all right in case you didn’t catch
it yet we’re walking on the ice in the
middle Stockholm all right oh yeah the
buddy system so the body system is it’s
great it’s easy to implement and there’s
nothing wrong with it but I think that
the best best thing that I’ve always
experienced in all software projects
where that has always been absolutely
marvelous when I’ve done it is pair
programming and pair program for the
ones that you’re not from aren’t
familiar with it is when one person acts
as a navigator and one person acts as a
driver and the responsibility of the
driver is the one that is actually
holding the keyboard like has the hands
on the keyboard and type the code while
the Navigator is the person that is
keeping tabs a little bit more on the
direction and where you are in the
project and what you’re supposed to do
like that you’re not getting distracted
and like that person a little it’s a
little less focused on syntax and and
typing and more focused on architecture
and getting the task done and in the I
think it’s very very useful to have a
navigator that is familiar with the
project and the driver being the one
unfamiliar with the project and that’s a
very good way of being introduced to the
project like the Navigator can
constantly assist you in saying like
yeah now we’re gonna change like this
little part in the system and this
little part in the system do you think
that you can type it like figure out how
to do this here and like gradually
assist you through things and I find
that even even if you put a pair
programming inside and just talk about
the concept of code review code review
is one of the best best ways to
introduce people to a new code base like
I think that code many miss that
knowledge sharing is one of the greatest
benefits of code review like you’re
pushing like you’re a fix and then
people can say like yeah this is great I
understand where you thought this way
but we already have this library that
you can use to do this or this way of
doing it is great but it’s not idiomatic
to what we do in the project so if you
do it look at this part of the code you
can see how we did about how we do it in
the project and that makes it more
consistent and easier to deal with it’s
not that your height your way is bad but
it’s just nice to have things consistent
and have that kind of no one sharing if
you don’t do code review and your team
that doesn’t happen and one of the
nicest things about but pair programming
pair pair programming pair program is
that you’re doing code review all the
time all the time it’s happening all the
time every second and in the same way
pair programming also means that you’re
helping all the time in the in the
archaeology pattern you’re you’re
basically just asking for help at a
point where it’s like so obvious that
you have been stuck maybe maybe you’ve
been stuck for days and tell you you
actually go and get make time with it
where perhaps a lead architect or
something
it can waste a lot of time and the body
system is also I mean it can still take
a lot of time I mean I try to say that
when I have access to a body I still try
to
not interrupt them constantly I try to
like still have a little time limit on
myself like just arbitrary like 50
minutes or 30 minutes or 45 minutes just
like some kind of time box where I’m not
allowed I’m not allowing myself to get
stuck more than that and then I ask
because even though the person is is
allocated to me and have time allocated
to me I guess I can’t it’s it’s not
designed to allow me to interrupt them
at every single single point however
when it comes to pair programming you
have like this massive constant access
to a person where the person can help
you at any time I mean it’s still good
for the navigator to allow the driver if
the driver is new in the project to to
figure things out on their own for a
little bit like it it’s not a lot like
it’s not good to like basically type for
the person verbally like typebar like
that’s not good navigating but it’s
really good that to have a navigator
that it’s like okay you’re getting stuck
can I give you a hint and that is
marvelously productive when I’m doing
pair programming it is so extremely rare
to get properly stuck but properly stuck
I mean when you are just you have no
idea how Pro to progress you just you
have been staring at the code for
perhaps hours and you don’t know what’s
wrong you move things around and you
just don’t see the issue and then you
perhaps you just give up go home and
then you come back the next day and look
at it with fresh eyes or perhaps you
just have a co-worker over and have them
look at it and you figure out the
problem immediately because it was just
some little thing missing it just was
invisible to you it was obvious in
hindsight but yeah and with pair
programming I almost never find myself
in those situations it’s so
because the likelihood that two people
two different brains looking at the same
code that they would miss the same
problem is so incredibly unlikely and
it’s even more unlikely if you’re doing
mob programming where you have an entire
team being like The Navigators I haven’t
done that too much but it’s super cool
and yeah I like pair programming a lot
so those are the three things like the
three ways I think about when I think
about asking for help and giving help in
a software team like the the archaeology
pattern or technique where you you don’t
don’t really you don’t have access to
much help maybe like you just have to
like Oh as the senior architecture pay
me you can help me and but you feel bad
about it and then you have the buddy
system where you are allocated a person
and then you have the pair programming
system where like you’re actually always
sitting down with somebody more familiar
with the code that’s in you and you you
figure things out together in unison
finally I I would like to make a little
plea to software
it’s senior software developers or
rather people that are in in senior
positions that you’ve been in a company
for a while but when a new person joins
your team or your company or where some
Orban it might be a new develop new
developer a junior developer it might be
a senior developer helping out with the
project or something make sure that that
heard like that you make yourself
available to that person or assign
somebody to help that person and think
about how to get that person up to speed
as much as possible and don’t let them
don’t drop them like some archeology
person in
in the project and let them swim for
themselves that’s not a productive way
and don’t express any enjoyment when
they ask you about things encourage them
to ask things and when they do like say
like so good that you went to me and
asked about this that’s really good
don’t be that person who is annoyed even
if you feel like feel it you should
never express that because that will
discourage them and that will cause your
software team to be extremely
inefficient there will be a lot of waste
and if you disagree with this and if
you’re like if you feel feel that
annoyed when you’re if you’re being feel
like oh I don’t want to help this person
because it distracts me from my work and
my IR want to solve issues like I I have
some news for you like you’re not a you
aren’t a senior developer yet because
the role of a senior developer like one
of the most important roles and tasks
that you have is to make sure like to
lift the developers around you to make
sure that the the junior developer is
around you or getting productive and
getting up to speed and getting them
started because the the only way to
really be a 10x developer or a 100x
developer is to improve developers
around you you’re eventually going to be
limited in your abilities but when you
build a software an organization if you
are a person strengthening others then
then you are truly a person that can be
explosive in your productivity and the
value you add to an organization so make
sure that you help the people around you
that’s that’s the the true value of a in
this episode is sponsored by Kaka it’s a
little inline evaluation thing that you
often see me use in the episodes we are
very proud to be pushing them because I
yes love it as a product it’s great when
you just try not in prototyping things
or when you are running a YouTube
channel and you want to just show
quickly show like things how JavaScript
evaluates it’s really great if you want
to check it out you can check it out at
quad fun fun function calm so that they
you know that you came from here you can
also see me using it and this video here
to check it out and have a feel for for
how it works it’s really right quad fun
for function calm and that’s it for
today I hope that was useful to you like
that
did you disagree did you agree how do
you have other approaches to helping
people what’s your experience and your
career with help please type it in the
comments I read all of them you have
watched an episode of fun fun function I
release these every Monday morning Oh
800 GMT but you will forget that so make
sure that you subscribe or watch another
episode right now by clicking here if
you’re unsure bye mmm PJ until next Monday morning thank you
Please follow and like us: