good Monday morning today I would like
to talk a little bit about how to tackle
a programming problem before we start
working on it I am your host mpj and you
are watching fun fun function so last
week I asked you to tweet me any
question that we were likely to talk
about and Colin Bellino asked how are
you feeling today and that’s so nice of
you to ask Colin I’m feeling a lot
better the last few months has been a
bit rough because I’ve been moving
cities moving to Stockholm and while
that is great in general it’s been a
little stress especially the fact that
I’ve been moving my studio so I am
basically been lacking a place to work
which like just torpedoes every routine
you have but this this this week I’ve
been signing the contract for a new
studio space we’re moving into that
space next week but for you that’s this
week and we’re going to hopefully start
our first stream this this this week
stay tuned for that make sure that you
subscribe on twitch.tv slash fun fun
function to get notified when that
happens I feel really great about what
spring will offer for the channel and we
have some great things coming up and
it’s gotta be awesome in case you’re
wondering by the way my what my shirt
says it’s like if brittany maybe through
2007 you can make it through today
Jojo from South Africa asks how do you
deal with procrastination Hey Oh
procrastination it’s am I an expert on
this too person observing my life from a
little distance like people watching the
YouTube channel like that Oh yikes
peripherally aware of my career I might
seem like a pretty productive person I
get to light out new episodes every week
for like several years it’s been a long
spotty now
the winter but we’ll pick up again and I
I don’t know I seem like a relatively
functioning person but what is not
obvious and visible is that I tend to
not get anything done I with the
episodes for instance it’s extremely
common for me to just do almost nothing
during the week like not for lack of
trying I try to sit down and make an
episode but I just don’t do it and I
either get distracted or do just stare
at the problem the blank page that is
the possible episode oh yeah I don’t
know I just don’t get it up for various
reason I end up doing it like with
blazing speed on the on Sunday afternoon
and this is pretty much the only way I
get things done I construct these boxes
with wolves in them for instance I have
this YouTube channel as a box with wolf
in it like every Monday I have this huge
expectation on me to release an episode
and it becomes almost unthinkable not to
release an episode it’s it’s it makes it
very easy to adhere to that contract
when you know that a lot of people are
expecting you to make an episode you
really want to fulfill that it’s like a
box with a wolf-like and another example
is like I’m going to have a CrossFit
session tomorrow where a book like time
with a personal trainer and that person
might expect me to show up there and
that will make me show up and then I
exercise it’s another box with a wolf I
have very little self-discipline and
very delicate you make myself do
something but I’m pretty good at
constructing these boxes that exploit my
sense of duty or obligation to get
things done I tend to function best when
I can do
hyper-focus ition like rather long
blocks of time we’re just like churn
into a problem I’m very very very bad at
multitasking like if I have a workday
where I can like risk use slack or or
Anakin messenger in in any way that
tends to just completely interrupt my my
workflow and I get nothing done whenever
I try to have a day where I try to get
many things done I get absolutely
nothing done I just get this distracted
distracted attracted and none of the
things that I intended to do gets done
so I have like I tend to be like the
only reason why my life functions at all
is because I’m reasonably good at
finding like a single thing for every
day that that kind of is useful or or at
least one every week so for instance
like making an episode every week I get
almost nothing done but I get that thing
done and that has a high impact on that
functions as a core of my over my life
and to get myself to focus then I I tend
to want to like block off this this time
boxes I’m a big believer in time boxing
and I recently bought this thing it’s a
time timer you see it will it if I put
it there bullet focus yeah it’s this
awesome little thing that it’s a visual
time timer stop focusing on my face and
as you see like it shows you visually
how much time is left which is really
great so and it’s pretty big as you see
and it you can put it like in your field
of view you I put it like right next to
my computer screen so I clearly see like
how much time I have left focus weeks it
provides like this visual cue and on the
back I can also turn on and off there
Audio alarm that leaps at the end of
this session which is really great
because I often want a audio alarm but
it’s if I’m sitting in library or coffee
shop I wanna I want to turn that off
so this is a great little great little
device and it’s also good too
I can’t give up trying using my phone as
a timer because that seems like the
obvious thing to use but it just really
doesn’t work because the phone has so
many other things in it that I tend to
get caught up in like I just remove it’s
the fact that I view the phone makes me
wanna check Instagram and the moment I
pick up the phone to turn off
the alarm once it rings and then
immediately there’s some notification
that sucks me in and the the nice thing
with this is that it crais’s
have low vien response like when I turn
this thing that is connected to
hyper-focus and only hyper focus and I
try to do this in one-hour sessions the
this is kind of inspired by the Pomodoro
Technique but the Pomodoro Technique is
25 minute sessions which is a good I
think it’s good for many people but I
have a hard time getting back into the
thing so for me it’s better to just like
focus for an hour it’s all look like
it’s a nice unit this also happens to be
an hourly unit and it also happens to be
the quick access thing on iPhone that
you if you force touch the Do Not
Disturb icon on iOS you can quickly do a
Do Not Disturb for one hour so it’s like
one hour kind of like it’s a it’s a nice
unit to keep in mind and you probably
shouldn’t work for sitting still for
more than an hour anyway so it can like
also nice upper limit good point to take
a break a precondition of hyper focus
yes two for me please
to know why I am doing something it’s I
think it’s a subtle thing with
procrastination yes that I think that a
lot of people don’t understand that it’s
there to protect you it’s it’s the body
tries to conserve energy and it
constantly challenges you to like is
this really like a good way to spend
your time because there’s all kinds of
pressure to on us to do different things
like there’s like the world wants us to
do more things and we have time and
energy to do so that’s what the feeling
of boredom or being obstinate or you
just don’t want to do something that’s
that’s what that’s what that’s there to
protect us from so that is why it’s
important to you like if something is
you need to do something I I find that
it helps a lot to sit down and define a
clear why behind what I’m doing that
that tends to like I think that it’s the
it’s called the locus of control in your
your brain that is activated not that’s
a real thing or behavioral psychology
mental model of thinking about it but I
definitely feel a sense of control and
agency you once I actually understand
why I’m doing something some of you
might be thinking wow he’s really
procrastinating on talking about today’s
actual subject that act like this video
to learn about and and you’re right but
it does tie into this question a little
bit either way let’s have a look at the
the Twitter question Mattias aimer asks
what’s your favorite ways to tackle a
problem tasks problem / tasks before you
start working on it the first thing that
I like to do is to understand the
problem and what I mean by that is that
I want to understand that the background
and the intent behind the the task that
we’re supposed to do so by background I
mean why
understanding the the whole war i the
this thing has ended up in your team’s
backlog and whites ended up on your
table and this is important to ask both
for yourself we own motivation as we
talked about earlier but it’s also
important for your organization because
if you don’t understand that the
background you might end up implementing
the wrong things it’s important years to
not just accept the task immediately
it’s important for you to understand the
holistic solve it so it’s great if you
start out with a like kind of curious
skepticism and asking yourself is this
really necessary is this necessary and
the not as a rhetorical questions you
like lately get it get this thing off
your table or dismiss it but it’s you
know like with a sense of curiosity
because if you don’t you might either
end up in the situation where you feel
we you’re kind of like end up in this
kind of passive-aggressive where it
stands where you’re grudgingly
implementing something and you don’t
really know why even though it might be
a really good business requirement and
might have like some really solid
background of why this is if you
understand what that is and why that is
you can confidently say to yourself like
no this this is actually very a very
sensible thing for us to do but if you
don’t understand it and you just start
implementing it anyway you might end up
feeling really bad about what you’re
doing because you don’t understand how
how you connecting things and it’s very
important for you must understand how
their actions connect to the greater
whole it’s it’s been proven in studies
in there in this branch of psychology
who googling self-determination theory
it’s also very important to ask yourself
the question why because sometimes
things end up on the backlog for really
bad reasons one example that ever
encountered many times is because some
senior management sneezed basically they
just or finitely said in some meeting
that oh this would be cool and then that
just starts snowballing through the
organization into like a feature or
sometimes in large organization even a
team and the senior manager lai
was not that that was not really their
intent so if you’d like go back they
were like what no no no that was just an
idea I had like I didn’t actually mean
order you to implement it and I that’s
probably something that you become more
aware of as you get those positions in
large organizations as you have to be
very careful about what you say because
it has huge ripple effects in the
organization but I think it’s very
important to not be a complete yes
person you should be enthusiastic and
curious but you should also make sure
that you always understand why a why a
task is being built once we know the
background we can move back and think
about what’s the intent behind this task
what is it that actually needs doing
because the task might be worded in a
certain way for instance like in
implement this this menu bad example was
something like imagine like something
rather elaborate but you might discover
that the intent of this added extra menu
at 7 penny or something that might be to
offer the user to turn off I don’t know
also playing videos in their feed of
things and then it might be better to
just add a little like extra context
action on the videos to allow the
to do that instead of implementing this
rather elaborate thing in the in the
interface and this is important because
that will make you so much more of an
efficient software engineer if you can
go go back to the stakeholders and like
the designer or the product owner and
say that yeah you asked me to implement
this this thing and the way it’s worded
it’s going to take about like 50 hours
but looking back to your intent if I
understand it correctly and reiterate it
then I think that I can implement like
this thing in two hours which achieves
your intent but at a much much cheaper
cost to the team and us as a development
organization and what do you think if
you are an engineer that can do that and
argue for that and have a discussion
around that that makes you into an
engineer that is effectively an order of
magnitude more efficient than an
engineer that just simply does what
they’re told all the time I don’t want
to present like some kind of utopian
dream here like sometimes you won’t be
able to convince your stakeholders about
like the much simpler solutions but a
lot of times you are and that will make
a huge impact on the organization and
will make you much better all right so
now we’ve understood the task we have
the background of the task and we have
the intent of the task and we have
formulated something that what actually
needs doing the next step here is
talking to people talking to lots and
lots and lots of people but might not
necessarily be lost but that’s it’s
often a lot this is something that a lot
of people that get into software
software development gets a little bit
surprised about when they start actually
working in the field that how much
talking it is if you don’t like talking
you
not gonna like software development I’m
sorry the first people that you’re going
to talk to our probably stakeholders the
product owner will probably have a no
cabe you of the stakeholders but as you
start getting into the nitty-gritty of
what needs to be done you probably will
need to have a direct dialogue with the
people that are actually going to use
the feature so and also like other teams
that might be affected and yeah this
varies like violently from from teacher
to teacher and test the test but you
tend to it’s you you get a lot more done
if you understand right
the the ramification of your task on
other parts of the organization after
you talk to some stakeholders and gotten
a bit more meet and you’re in your mind
about like what it is that needs to be
doing you talk to other depths and the
might there might be dev said are
knowledgeable and the code base that you
are you will be working they gonna be
like you average colleague or if you
knew like your new team members to get a
sense of the implications of what is
being implemented and discussing a
little bit on like the best approach of
implementing in the system because
people that have a lot of knowledge
about the codebase are going to give you
good insights about it and probably
gonna give you a little bit of pushback
because of the way that you’re thinking
like your initial thought about it
implemented is probably gonna be like
not quite in sync with the system it
might be like okay yeah if we do this
you have to really factor this entire
module blah or something like that it’s
expensive and they can probably in turn
provide you with some better way of
doing it
they might be pushing
bad way of doing it that is comfortable
for the system so to speak like because
change in a software system is risky so
software developments software
developers naturally tend to like push
back on change as much much as possible
– in order to reduce defects but I mean
if we completely stop change then we’re
not introducing any changes or
improvements at all so it’s like it’s a
trade-off you will also have to talk to
other devs in order to just know how the
hell to do things like finding out what
endpoints to use how if you’re working
in like a new module of the system you
might have to figure out how to build
that thing and deploy that thing in
lalalala and you will find that you are
frustrated as why is this not covered in
Docs and why is this thing not automated
completely why do I have to talk to a
human hearing to some extent that is
that frustration is correct I mean you
can always improve deployment things
with by decreasing things and you can
write better documentation for endpoints
and stuff like that but I find that the
whole like the well-documented system
that where every endpoint always works
and stuff like it’s that’s that’s just a
dream I’ve never seen it it’s a it’s a
Loch Ness saying I’m not saying it
doesn’t exist I just have not ever seen
it in reality things are flexible things
move around and the only people that
have a a fresh notion of what is going
on is the people that have done it and
sometimes they have synced that that
that state in their head out into a
document or like some kind of the
test-driven suite or whatever but quite
often a lot of the null
Shyvana software project is going to be
in the people and that’s the way systems
were with humans I mean if that goes for
any kind of system even an even a
building if you have a building and no
person works on it no person repairs it
no person like fixes the pipes or unclog
the electricity I don’t know I don’t
know it’s involved in my house but my
point is that if you leave the house
untouched by humans for a rather short
period of time years a few years it will
completely break down and software
development projects and especially
things that are deployed on servants
which is like where a lot of things go
wrong all the time it’s almost like it’s
more like gardening than anything and
it’s important to recognize that the
human element always like it’s it’s a
living pulsating being and you you have
to like to talk to people in order to
like figure out where where I would
change things so you probably have
noticed here that we have only talked
about defining the problem here we have
not written any code yet we we have
talked about how we understand I could
drop the background of the problem
understand the intent of the solution
and then like researching like the
nitty-gritty of how something that
should be made and also discussing with
other parties of like modifying this
solution and defining the problem I
would say as like one of the absolutely
top skills of software developer that is
that the so core and it’s only the
software developer that can do it like
product owner cannot do it the agile
coach cannot do it the customer cannot
do it because if it requires like this
this interaction and knowing systems
well and and researching like a lot of
things
both on the product side and on the and
on the the technical side and the most
important aspect of all of this the most
important function that a software
developer has yes – argument the problem
into a worse problem what I mean by that
is that a software developer is the the
person that thinks of the happy path so
every solution has a habitat right it’s
when everything goes right the user
has a great internet connection and the
the credit card payment goes through
correctly and now we can sj-o order has
been charged and sent great but reality
doesn’t work like that reality always
tries to like destroy everything and
fail the the universe is not there to to
make us happy it’s there to make us sad
and we try to design systems which makes
humans not sad by working doing things
that’s that’s what we do at software
developers and therefore as software
developers we have to think about the
sad path the edge cases and all that we
have to dream up all the ways that the
universe can mess this this this up so
we have to think about yeah what if the
network goes down what if this is the
version is an error what if this system
returns an error what if the user has
has a playlist of 10,000 songs
what if there is an artist on the
service that adds an album with 2,000
songs and the worst thing with this is
that you can invent an infinite list of
those things so you also have to know
like when to stop and how to how to
prioritize and get a sense of like which
ones are are actually likely to happen
or not and this can sometimes require a
bit of a data mining as a music company
I worked
I was involved in optimizing scroll
performance for lists of herbs on items
and the question arose like during the
work like how many like how many songs
should we like optimized for like
because we discovered that our efforts
but if we optimized the scrolling for a
playlist that was 10,000 songs long that
meant like the way we like unloading
strategies effectively made the case for
the short playlists worse and was very
hard to device an algorithm that worked
for both cases you know like was almost
like a whack-a-mole but the more we made
it better from the long case of the word
versus it became for the short case so
the need arose to know like what does
their user actually look like what what
what is that the archetype so that’s
required like actually going into the
data set and monitoring usage to see
like how many songs where people
actually added to the playlist and then
we optimized for like this the 98% of
users that I don’t remember how many
songs it was and I probably can tell
because it’s secret company data but the
point was that we figured out what the
almost all users look like and optimized
for that instead of spending Haga thomas
of time on optimizing for a niche case
that was super rare and that also made
the experience worse for the users that
that were actually in the normal range
when you get a task it often it’s often
described in very simple terms it’s yes
like the user is supposed to at this
thing to this thing and it’s fine but
there’s almost always a lot of
intricacies to a problem like the user
might want to add it in this way and
what happens if the user does this or
this this like it’s not necessarily
things that go wrong it’s not sad path
things it’s just like all the difference
nuances of the problem like like
implementing this feature now what
happens when it interacts with this
feature that kind of stuff and all those
things are like a case like it’s a it’s
a test case basically and this is why a
lot of developers when they start
writing unit tests are doing TDD is that
they are just overwhelmed with oh my god
there’s so much test code for I wrote
like these three lines of code and I’m
up to fifteen unit tests and this is
because like not not all but entirely
but your large degree I find that when I
write test code I just think about more
things that can go wrong and more more
intricacies of the code and I just test
for them when you just write code like
often it’s like yeah yeah I just write
the code you tend to only think about
happy path you tend to not think about
sad path and you don’t tend to not think
about the edge path or like you do but
not not at all to the extent when you do
when you’re sitting there dreaming up
test cases for your code and the thing
is like it’s very important to be aware
that programming languages are designed
to be extremely expressive if you even
if you have like this tiny piece of code
like just and are 10 lines long and you
try to describe what that code does in
in English and also try to describe each
each case from the start then you end up
where I probably several pages worth of
English its programming languages are so
terse and so expressive and that’s the
way they’re designed and it’s important
to be aware of that power you can
contain so much logic in in in a little
ball and that’s why unit testing is so
important to you to be aware of that
you’re adding a lot of complexity to the
system because if you’re not aware of
this you might be adding like just a few
lines of code somewhere and if you don’t
have automated tests or at least think
about what the test cases are that
you’re introducing there might be manual
to you might be introducing like for
every case you’re introducing this one
thing that can go wrong and so whenever
somebody is changing something in this
thing let’s say that it’s like 20 things
they have to check that cannot go wrong
if you don’t have an automated test
suite for that you’re introducing like
so much brittleness into your system
that it’s it just makes the system bad
change batteries there did you know but
anyway at some point we are going to
start coding and and as much as I’ve
talked about like this rich research
planning phase and it’s it’s also
important to get going prior to
recording this episode of brains from
this a little bit with ISA her Twitter
is in the absurd description and she
said like this this wonderful little
soundbite refinement is better than a
overthinking which makes sense but it
like I would like to extend it to that
refinement is better than upfront
thinking what what we’re trying to get
out there is that it’s it’s important to
not try to write the best code now
when there’s an API involved I always
try to just create a throwaway prototype
in order to learn yes the API endpoints
and let’s get a sense of what the API
looks like and then I just dump that
code out just copy it to like some
notepad or something where I can come
keep it as a reference ish but I don’t
use that code instead I start like start
T dding I start like writing out the
simplest edges simplest case simplest
happy part and then I start building out
from like error cases and edge cases and
getting in to it that way and start like
with a super nice solution which then
becomes gradually less naive and
refactoring is something that I push to
as late as possible because that the
writing nice code that is readable I
wore like fast code that takes a long
time and it’s very bad to do it upfront
because you’re probably gonna end up
improving readability and and speed of
code that you’re just going to be
throwing away because it works wrong so
it’s very key aspect iterate iterate
iterate and refine refine refine and
until you have like code that works on
all accounts has all the test cases
running and green then you start
thinking about performance then you
start thinking about readability what’s
important before you do the pull request
but don’t do it up from that’s just a
distraction I really want to make a push
for TDD tested written test-driven
development here because it has made me
such a better developer when it comes to
these things it works really well for me
because for me it’s a distraction buster
it keeps me focused on functionality and
making sure that the code works because
each test case means that something
works is like a green green green
red green red green red green then we’ll
just break them then you implement them
and then they go green that you may know
that you’re making progress on on actual
functionality and otherwise they tend to
get caught up in refactoring and code
styling and API design and stuff like
that which isn’t really adding and user
value don’t get me wrong it’s it’s
important but unless you have working
foundation it’s just speed and
readability is it’s just a waste of time
readability and speed are important but
they must rest on a solid foundation of
function and that’s what we verify with
unit tests TDD is TDD is also nice
because it gives me a tangible feeling
of progress like as tests grow I know
that I am making progress towards
functionality just feels great gifts
like this constant motivation and keeps
me from gives you leave these little
heads of dopamine each time it’s very
very nice
finally unit tests give like removes the
illusion of the happy path because
there’s so many times where I have in a
more junior version of me just
implemented the happy path and yes yes
deployed it and send it away to like the
product owner or whatever a customer was
and they immediately found problems with
it
and I was just so frustrated with myself
for like why didn’t I think of that yeah
because you didn’t think you didn’t
think of anything but the happy path you
just wanted to complete the task and the
problem is that you if you just think
about the happy path and don’t think
about the sad path or the edge path you
have not really completed the task
that’s my thoughts on that I think this
what felt like a very long episode I
hope that you found it useful and you
courage how I carried carried you to the
end if you have questions about my
problem-solving process please person as
a comment down below or also feel
welcome to share how you solve problems
yourself that it’s like super
interesting to me and that is it you
have just watched an episode of fun fun
function I released this every Monday
morning oh wait hundred GMT but you will
forget that so you can click here to
subscribe or if you’re not quite ready
to do that you can check out another
episode right now by clicking there
I am mpj until next Monday morning stay curious
to talk a little bit about how to tackle
a programming problem before we start
working on it I am your host mpj and you
are watching fun fun function so last
week I asked you to tweet me any
question that we were likely to talk
about and Colin Bellino asked how are
you feeling today and that’s so nice of
you to ask Colin I’m feeling a lot
better the last few months has been a
bit rough because I’ve been moving
cities moving to Stockholm and while
that is great in general it’s been a
little stress especially the fact that
I’ve been moving my studio so I am
basically been lacking a place to work
which like just torpedoes every routine
you have but this this this week I’ve
been signing the contract for a new
studio space we’re moving into that
space next week but for you that’s this
week and we’re going to hopefully start
our first stream this this this week
stay tuned for that make sure that you
subscribe on twitch.tv slash fun fun
function to get notified when that
happens I feel really great about what
spring will offer for the channel and we
have some great things coming up and
it’s gotta be awesome in case you’re
wondering by the way my what my shirt
says it’s like if brittany maybe through
2007 you can make it through today
Jojo from South Africa asks how do you
deal with procrastination Hey Oh
procrastination it’s am I an expert on
this too person observing my life from a
little distance like people watching the
YouTube channel like that Oh yikes
peripherally aware of my career I might
seem like a pretty productive person I
get to light out new episodes every week
for like several years it’s been a long
spotty now
the winter but we’ll pick up again and I
I don’t know I seem like a relatively
functioning person but what is not
obvious and visible is that I tend to
not get anything done I with the
episodes for instance it’s extremely
common for me to just do almost nothing
during the week like not for lack of
trying I try to sit down and make an
episode but I just don’t do it and I
either get distracted or do just stare
at the problem the blank page that is
the possible episode oh yeah I don’t
know I just don’t get it up for various
reason I end up doing it like with
blazing speed on the on Sunday afternoon
and this is pretty much the only way I
get things done I construct these boxes
with wolves in them for instance I have
this YouTube channel as a box with wolf
in it like every Monday I have this huge
expectation on me to release an episode
and it becomes almost unthinkable not to
release an episode it’s it’s it makes it
very easy to adhere to that contract
when you know that a lot of people are
expecting you to make an episode you
really want to fulfill that it’s like a
box with a wolf-like and another example
is like I’m going to have a CrossFit
session tomorrow where a book like time
with a personal trainer and that person
might expect me to show up there and
that will make me show up and then I
exercise it’s another box with a wolf I
have very little self-discipline and
very delicate you make myself do
something but I’m pretty good at
constructing these boxes that exploit my
sense of duty or obligation to get
things done I tend to function best when
I can do
hyper-focus ition like rather long
blocks of time we’re just like churn
into a problem I’m very very very bad at
multitasking like if I have a workday
where I can like risk use slack or or
Anakin messenger in in any way that
tends to just completely interrupt my my
workflow and I get nothing done whenever
I try to have a day where I try to get
many things done I get absolutely
nothing done I just get this distracted
distracted attracted and none of the
things that I intended to do gets done
so I have like I tend to be like the
only reason why my life functions at all
is because I’m reasonably good at
finding like a single thing for every
day that that kind of is useful or or at
least one every week so for instance
like making an episode every week I get
almost nothing done but I get that thing
done and that has a high impact on that
functions as a core of my over my life
and to get myself to focus then I I tend
to want to like block off this this time
boxes I’m a big believer in time boxing
and I recently bought this thing it’s a
time timer you see it will it if I put
it there bullet focus yeah it’s this
awesome little thing that it’s a visual
time timer stop focusing on my face and
as you see like it shows you visually
how much time is left which is really
great so and it’s pretty big as you see
and it you can put it like in your field
of view you I put it like right next to
my computer screen so I clearly see like
how much time I have left focus weeks it
provides like this visual cue and on the
back I can also turn on and off there
Audio alarm that leaps at the end of
this session which is really great
because I often want a audio alarm but
it’s if I’m sitting in library or coffee
shop I wanna I want to turn that off
so this is a great little great little
device and it’s also good too
I can’t give up trying using my phone as
a timer because that seems like the
obvious thing to use but it just really
doesn’t work because the phone has so
many other things in it that I tend to
get caught up in like I just remove it’s
the fact that I view the phone makes me
wanna check Instagram and the moment I
pick up the phone to turn off
the alarm once it rings and then
immediately there’s some notification
that sucks me in and the the nice thing
with this is that it crais’s
have low vien response like when I turn
this thing that is connected to
hyper-focus and only hyper focus and I
try to do this in one-hour sessions the
this is kind of inspired by the Pomodoro
Technique but the Pomodoro Technique is
25 minute sessions which is a good I
think it’s good for many people but I
have a hard time getting back into the
thing so for me it’s better to just like
focus for an hour it’s all look like
it’s a nice unit this also happens to be
an hourly unit and it also happens to be
the quick access thing on iPhone that
you if you force touch the Do Not
Disturb icon on iOS you can quickly do a
Do Not Disturb for one hour so it’s like
one hour kind of like it’s a it’s a nice
unit to keep in mind and you probably
shouldn’t work for sitting still for
more than an hour anyway so it can like
also nice upper limit good point to take
a break a precondition of hyper focus
yes two for me please
to know why I am doing something it’s I
think it’s a subtle thing with
procrastination yes that I think that a
lot of people don’t understand that it’s
there to protect you it’s it’s the body
tries to conserve energy and it
constantly challenges you to like is
this really like a good way to spend
your time because there’s all kinds of
pressure to on us to do different things
like there’s like the world wants us to
do more things and we have time and
energy to do so that’s what the feeling
of boredom or being obstinate or you
just don’t want to do something that’s
that’s what that’s what that’s there to
protect us from so that is why it’s
important to you like if something is
you need to do something I I find that
it helps a lot to sit down and define a
clear why behind what I’m doing that
that tends to like I think that it’s the
it’s called the locus of control in your
your brain that is activated not that’s
a real thing or behavioral psychology
mental model of thinking about it but I
definitely feel a sense of control and
agency you once I actually understand
why I’m doing something some of you
might be thinking wow he’s really
procrastinating on talking about today’s
actual subject that act like this video
to learn about and and you’re right but
it does tie into this question a little
bit either way let’s have a look at the
the Twitter question Mattias aimer asks
what’s your favorite ways to tackle a
problem tasks problem / tasks before you
start working on it the first thing that
I like to do is to understand the
problem and what I mean by that is that
I want to understand that the background
and the intent behind the the task that
we’re supposed to do so by background I
mean why
understanding the the whole war i the
this thing has ended up in your team’s
backlog and whites ended up on your
table and this is important to ask both
for yourself we own motivation as we
talked about earlier but it’s also
important for your organization because
if you don’t understand that the
background you might end up implementing
the wrong things it’s important years to
not just accept the task immediately
it’s important for you to understand the
holistic solve it so it’s great if you
start out with a like kind of curious
skepticism and asking yourself is this
really necessary is this necessary and
the not as a rhetorical questions you
like lately get it get this thing off
your table or dismiss it but it’s you
know like with a sense of curiosity
because if you don’t you might either
end up in the situation where you feel
we you’re kind of like end up in this
kind of passive-aggressive where it
stands where you’re grudgingly
implementing something and you don’t
really know why even though it might be
a really good business requirement and
might have like some really solid
background of why this is if you
understand what that is and why that is
you can confidently say to yourself like
no this this is actually very a very
sensible thing for us to do but if you
don’t understand it and you just start
implementing it anyway you might end up
feeling really bad about what you’re
doing because you don’t understand how
how you connecting things and it’s very
important for you must understand how
their actions connect to the greater
whole it’s it’s been proven in studies
in there in this branch of psychology
who googling self-determination theory
it’s also very important to ask yourself
the question why because sometimes
things end up on the backlog for really
bad reasons one example that ever
encountered many times is because some
senior management sneezed basically they
just or finitely said in some meeting
that oh this would be cool and then that
just starts snowballing through the
organization into like a feature or
sometimes in large organization even a
team and the senior manager lai
was not that that was not really their
intent so if you’d like go back they
were like what no no no that was just an
idea I had like I didn’t actually mean
order you to implement it and I that’s
probably something that you become more
aware of as you get those positions in
large organizations as you have to be
very careful about what you say because
it has huge ripple effects in the
organization but I think it’s very
important to not be a complete yes
person you should be enthusiastic and
curious but you should also make sure
that you always understand why a why a
task is being built once we know the
background we can move back and think
about what’s the intent behind this task
what is it that actually needs doing
because the task might be worded in a
certain way for instance like in
implement this this menu bad example was
something like imagine like something
rather elaborate but you might discover
that the intent of this added extra menu
at 7 penny or something that might be to
offer the user to turn off I don’t know
also playing videos in their feed of
things and then it might be better to
just add a little like extra context
action on the videos to allow the
to do that instead of implementing this
rather elaborate thing in the in the
interface and this is important because
that will make you so much more of an
efficient software engineer if you can
go go back to the stakeholders and like
the designer or the product owner and
say that yeah you asked me to implement
this this thing and the way it’s worded
it’s going to take about like 50 hours
but looking back to your intent if I
understand it correctly and reiterate it
then I think that I can implement like
this thing in two hours which achieves
your intent but at a much much cheaper
cost to the team and us as a development
organization and what do you think if
you are an engineer that can do that and
argue for that and have a discussion
around that that makes you into an
engineer that is effectively an order of
magnitude more efficient than an
engineer that just simply does what
they’re told all the time I don’t want
to present like some kind of utopian
dream here like sometimes you won’t be
able to convince your stakeholders about
like the much simpler solutions but a
lot of times you are and that will make
a huge impact on the organization and
will make you much better all right so
now we’ve understood the task we have
the background of the task and we have
the intent of the task and we have
formulated something that what actually
needs doing the next step here is
talking to people talking to lots and
lots and lots of people but might not
necessarily be lost but that’s it’s
often a lot this is something that a lot
of people that get into software
software development gets a little bit
surprised about when they start actually
working in the field that how much
talking it is if you don’t like talking
you
not gonna like software development I’m
sorry the first people that you’re going
to talk to our probably stakeholders the
product owner will probably have a no
cabe you of the stakeholders but as you
start getting into the nitty-gritty of
what needs to be done you probably will
need to have a direct dialogue with the
people that are actually going to use
the feature so and also like other teams
that might be affected and yeah this
varies like violently from from teacher
to teacher and test the test but you
tend to it’s you you get a lot more done
if you understand right
the the ramification of your task on
other parts of the organization after
you talk to some stakeholders and gotten
a bit more meet and you’re in your mind
about like what it is that needs to be
doing you talk to other depths and the
might there might be dev said are
knowledgeable and the code base that you
are you will be working they gonna be
like you average colleague or if you
knew like your new team members to get a
sense of the implications of what is
being implemented and discussing a
little bit on like the best approach of
implementing in the system because
people that have a lot of knowledge
about the codebase are going to give you
good insights about it and probably
gonna give you a little bit of pushback
because of the way that you’re thinking
like your initial thought about it
implemented is probably gonna be like
not quite in sync with the system it
might be like okay yeah if we do this
you have to really factor this entire
module blah or something like that it’s
expensive and they can probably in turn
provide you with some better way of
doing it
they might be pushing
bad way of doing it that is comfortable
for the system so to speak like because
change in a software system is risky so
software developments software
developers naturally tend to like push
back on change as much much as possible
– in order to reduce defects but I mean
if we completely stop change then we’re
not introducing any changes or
improvements at all so it’s like it’s a
trade-off you will also have to talk to
other devs in order to just know how the
hell to do things like finding out what
endpoints to use how if you’re working
in like a new module of the system you
might have to figure out how to build
that thing and deploy that thing in
lalalala and you will find that you are
frustrated as why is this not covered in
Docs and why is this thing not automated
completely why do I have to talk to a
human hearing to some extent that is
that frustration is correct I mean you
can always improve deployment things
with by decreasing things and you can
write better documentation for endpoints
and stuff like that but I find that the
whole like the well-documented system
that where every endpoint always works
and stuff like it’s that’s that’s just a
dream I’ve never seen it it’s a it’s a
Loch Ness saying I’m not saying it
doesn’t exist I just have not ever seen
it in reality things are flexible things
move around and the only people that
have a a fresh notion of what is going
on is the people that have done it and
sometimes they have synced that that
that state in their head out into a
document or like some kind of the
test-driven suite or whatever but quite
often a lot of the null
Shyvana software project is going to be
in the people and that’s the way systems
were with humans I mean if that goes for
any kind of system even an even a
building if you have a building and no
person works on it no person repairs it
no person like fixes the pipes or unclog
the electricity I don’t know I don’t
know it’s involved in my house but my
point is that if you leave the house
untouched by humans for a rather short
period of time years a few years it will
completely break down and software
development projects and especially
things that are deployed on servants
which is like where a lot of things go
wrong all the time it’s almost like it’s
more like gardening than anything and
it’s important to recognize that the
human element always like it’s it’s a
living pulsating being and you you have
to like to talk to people in order to
like figure out where where I would
change things so you probably have
noticed here that we have only talked
about defining the problem here we have
not written any code yet we we have
talked about how we understand I could
drop the background of the problem
understand the intent of the solution
and then like researching like the
nitty-gritty of how something that
should be made and also discussing with
other parties of like modifying this
solution and defining the problem I
would say as like one of the absolutely
top skills of software developer that is
that the so core and it’s only the
software developer that can do it like
product owner cannot do it the agile
coach cannot do it the customer cannot
do it because if it requires like this
this interaction and knowing systems
well and and researching like a lot of
things
both on the product side and on the and
on the the technical side and the most
important aspect of all of this the most
important function that a software
developer has yes – argument the problem
into a worse problem what I mean by that
is that a software developer is the the
person that thinks of the happy path so
every solution has a habitat right it’s
when everything goes right the user
has a great internet connection and the
the credit card payment goes through
correctly and now we can sj-o order has
been charged and sent great but reality
doesn’t work like that reality always
tries to like destroy everything and
fail the the universe is not there to to
make us happy it’s there to make us sad
and we try to design systems which makes
humans not sad by working doing things
that’s that’s what we do at software
developers and therefore as software
developers we have to think about the
sad path the edge cases and all that we
have to dream up all the ways that the
universe can mess this this this up so
we have to think about yeah what if the
network goes down what if this is the
version is an error what if this system
returns an error what if the user has
has a playlist of 10,000 songs
what if there is an artist on the
service that adds an album with 2,000
songs and the worst thing with this is
that you can invent an infinite list of
those things so you also have to know
like when to stop and how to how to
prioritize and get a sense of like which
ones are are actually likely to happen
or not and this can sometimes require a
bit of a data mining as a music company
I worked
I was involved in optimizing scroll
performance for lists of herbs on items
and the question arose like during the
work like how many like how many songs
should we like optimized for like
because we discovered that our efforts
but if we optimized the scrolling for a
playlist that was 10,000 songs long that
meant like the way we like unloading
strategies effectively made the case for
the short playlists worse and was very
hard to device an algorithm that worked
for both cases you know like was almost
like a whack-a-mole but the more we made
it better from the long case of the word
versus it became for the short case so
the need arose to know like what does
their user actually look like what what
what is that the archetype so that’s
required like actually going into the
data set and monitoring usage to see
like how many songs where people
actually added to the playlist and then
we optimized for like this the 98% of
users that I don’t remember how many
songs it was and I probably can tell
because it’s secret company data but the
point was that we figured out what the
almost all users look like and optimized
for that instead of spending Haga thomas
of time on optimizing for a niche case
that was super rare and that also made
the experience worse for the users that
that were actually in the normal range
when you get a task it often it’s often
described in very simple terms it’s yes
like the user is supposed to at this
thing to this thing and it’s fine but
there’s almost always a lot of
intricacies to a problem like the user
might want to add it in this way and
what happens if the user does this or
this this like it’s not necessarily
things that go wrong it’s not sad path
things it’s just like all the difference
nuances of the problem like like
implementing this feature now what
happens when it interacts with this
feature that kind of stuff and all those
things are like a case like it’s a it’s
a test case basically and this is why a
lot of developers when they start
writing unit tests are doing TDD is that
they are just overwhelmed with oh my god
there’s so much test code for I wrote
like these three lines of code and I’m
up to fifteen unit tests and this is
because like not not all but entirely
but your large degree I find that when I
write test code I just think about more
things that can go wrong and more more
intricacies of the code and I just test
for them when you just write code like
often it’s like yeah yeah I just write
the code you tend to only think about
happy path you tend to not think about
sad path and you don’t tend to not think
about the edge path or like you do but
not not at all to the extent when you do
when you’re sitting there dreaming up
test cases for your code and the thing
is like it’s very important to be aware
that programming languages are designed
to be extremely expressive if you even
if you have like this tiny piece of code
like just and are 10 lines long and you
try to describe what that code does in
in English and also try to describe each
each case from the start then you end up
where I probably several pages worth of
English its programming languages are so
terse and so expressive and that’s the
way they’re designed and it’s important
to be aware of that power you can
contain so much logic in in in a little
ball and that’s why unit testing is so
important to you to be aware of that
you’re adding a lot of complexity to the
system because if you’re not aware of
this you might be adding like just a few
lines of code somewhere and if you don’t
have automated tests or at least think
about what the test cases are that
you’re introducing there might be manual
to you might be introducing like for
every case you’re introducing this one
thing that can go wrong and so whenever
somebody is changing something in this
thing let’s say that it’s like 20 things
they have to check that cannot go wrong
if you don’t have an automated test
suite for that you’re introducing like
so much brittleness into your system
that it’s it just makes the system bad
change batteries there did you know but
anyway at some point we are going to
start coding and and as much as I’ve
talked about like this rich research
planning phase and it’s it’s also
important to get going prior to
recording this episode of brains from
this a little bit with ISA her Twitter
is in the absurd description and she
said like this this wonderful little
soundbite refinement is better than a
overthinking which makes sense but it
like I would like to extend it to that
refinement is better than upfront
thinking what what we’re trying to get
out there is that it’s it’s important to
not try to write the best code now
when there’s an API involved I always
try to just create a throwaway prototype
in order to learn yes the API endpoints
and let’s get a sense of what the API
looks like and then I just dump that
code out just copy it to like some
notepad or something where I can come
keep it as a reference ish but I don’t
use that code instead I start like start
T dding I start like writing out the
simplest edges simplest case simplest
happy part and then I start building out
from like error cases and edge cases and
getting in to it that way and start like
with a super nice solution which then
becomes gradually less naive and
refactoring is something that I push to
as late as possible because that the
writing nice code that is readable I
wore like fast code that takes a long
time and it’s very bad to do it upfront
because you’re probably gonna end up
improving readability and and speed of
code that you’re just going to be
throwing away because it works wrong so
it’s very key aspect iterate iterate
iterate and refine refine refine and
until you have like code that works on
all accounts has all the test cases
running and green then you start
thinking about performance then you
start thinking about readability what’s
important before you do the pull request
but don’t do it up from that’s just a
distraction I really want to make a push
for TDD tested written test-driven
development here because it has made me
such a better developer when it comes to
these things it works really well for me
because for me it’s a distraction buster
it keeps me focused on functionality and
making sure that the code works because
each test case means that something
works is like a green green green
red green red green red green then we’ll
just break them then you implement them
and then they go green that you may know
that you’re making progress on on actual
functionality and otherwise they tend to
get caught up in refactoring and code
styling and API design and stuff like
that which isn’t really adding and user
value don’t get me wrong it’s it’s
important but unless you have working
foundation it’s just speed and
readability is it’s just a waste of time
readability and speed are important but
they must rest on a solid foundation of
function and that’s what we verify with
unit tests TDD is TDD is also nice
because it gives me a tangible feeling
of progress like as tests grow I know
that I am making progress towards
functionality just feels great gifts
like this constant motivation and keeps
me from gives you leave these little
heads of dopamine each time it’s very
very nice
finally unit tests give like removes the
illusion of the happy path because
there’s so many times where I have in a
more junior version of me just
implemented the happy path and yes yes
deployed it and send it away to like the
product owner or whatever a customer was
and they immediately found problems with
it
and I was just so frustrated with myself
for like why didn’t I think of that yeah
because you didn’t think you didn’t
think of anything but the happy path you
just wanted to complete the task and the
problem is that you if you just think
about the happy path and don’t think
about the sad path or the edge path you
have not really completed the task
that’s my thoughts on that I think this
what felt like a very long episode I
hope that you found it useful and you
courage how I carried carried you to the
end if you have questions about my
problem-solving process please person as
a comment down below or also feel
welcome to share how you solve problems
yourself that it’s like super
interesting to me and that is it you
have just watched an episode of fun fun
function I released this every Monday
morning oh wait hundred GMT but you will
forget that so you can click here to
subscribe or if you’re not quite ready
to do that you can check out another
episode right now by clicking there
I am mpj until next Monday morning stay curious
Please follow and like us: