Day 40 - April 17: What Impostor Syndrome can teach Developers

Some tips and tricks on dealing with imposter syndrome as a developer, why context matters and you should always be learning regardless of your seniority.

Mentioned in this episode

Transcript

Alex: Good morning future, Alex. It's day 40 and April 17th today.

[00:00:06] So I'm coming up to about 20 years of writing
code professionally as in getting paid. Before that I was doing a bit of web
development or web design and did sometimes get paid or bartered, but my first
internship writing production code was about two decades ago now.

[00:00:28] And I've obviously come a long way and definitely
see myself as an experienced developer now, but the one thing that I haven't
gotten over ever and probably never will, is: impostor syndrome. That deep down
feeling that you're batting way above your average and everyone else around you
is just so much better.

[00:00:51] It doesn't matter how many systems you've built
successfully, how much experience you've gained. It's still there, at least for
me. I'm envious of those people that seemingly don't have it. Although I do
wonder if they may be just better at not showing it and privately they have the
same feelings.

[00:01:12]I was reminded of this recently when I handed off
a project to another developer, and I was looking through the commits that he
made, to see what, what he was changing.

[00:01:25] And while most of the changes were relevant to
the task that he was doing, there was some bug fixes he included that changed
part of my code. And so in that process, he cleaned up some of my code. Now I
think the, the state and the quality of code is so dependent on the context,
the situation, the project delivery dates.

[00:01:48]An important skill for a developer, especially a
senior developer is finding that trade off. You don't want to succumb to
deadlines and pressure and create bad quality code. But at the same time,
you're there to deliver functionality, the best quality code in the world
doesn't help if the project goes over time over budget and then ultimately
maybe gets canceled.

[00:02:13]No. I've been on the other side of this as well
taking over projects that somebody else developed and yes, when I need to fix
something in the code, I will often go and clean up that part of the code,  usually in an effort to better understand it for
myself, but I try to keep in mind that the context that i'm working in right
now is not the same context that the original developer was working in .

[00:02:37] Because I'm only focusing on a class or, or a
small module, I have much  easier time
fixing or cleaning up that part. So there's nothing inherently wrong with
someone cleaning up code. The problem is the, or let's just say my first gut
reaction was something along the lines of, "Whoa, why is he changing my
code." As if the code belonged to me.

[00:03:03]Now, thankfully I've been around for a while now
and I've had that feeling so many times but I've learned to react more
appropriately now. In the past that feeling did take over and so i thought i'd
give some tips or at least some thoughts about those feelings or those kinds of
feelings for anyone who's coming across them for the first time or is
struggling with them now

[00:03:28]First off, realize it's not about right or wrong.
Creating software is an art form to a degree. There's a lot of creativity
involved and a lot of how you write code is dependent on your experience. Now
again, your experience may be different to someone else's, but you may also be
working towards a different goal.

[00:03:51] Now, this is my second point. You probably have a
different short term goal to the person who either originally wrote the code or
to the one who's changing your code. As a principal developer on a project, you
have to take all of the things into consideration about the project. As I was
saying, deadlines and all of the interactions of the modules, and you have to
make tradeoffs some tasks are not as high priority as others.

[00:04:19]But when you're fixing a bug and that's your short
term goal you have much less variables to think about the project may already
be running it maybe in maintenance mode and you might not have the pressure of
delivering to a specific deadline.

[00:04:34]Thirdly, remember your both working towards the
same longterm goal, so you want working software and maintainable code. Now don't
use the excuse that the deadline was looming to create bad quality code.

[00:04:50]That's not what a senior developer does, but at
the same time, realize that you're under a different pressure or less pressure
when you're doing this outside of a project deadline. So it is actually your
responsibility to clean up some of the code if you have the time to do so
because again you're working towards the same longterm goal of making the
software is maintainable as possible.

[00:05:17]

[00:05:17]And of course, don't fall into the trap that a lot
of developers fall into and that is to see a bit of the code that you need to
fix and instead of just fixing or cleaning up the local code, right? That
class, or maybe that module, you go in and look at all of the code and say, Oh
my God, this is really bad quality code and then you know, change everything.
That's the opposite effect, right? 

[00:05:42]Fourth keep in mind, you're always learning. You,
can call yourself a senior or an experienced developer, but you still will not
know everything.  You will learn from
others all the time. And if you don't that, that's a big red flag for a
developer who doesn't want to learn. You should learn from others and yes, sure
apply some interpretation to what they're telling you and what you're seeing.
But every time I've worked with other developers on a project, I've gained so
much more insights into how they think and tools and ways of approaching things
that I, that I didn't think of at the time. Because especially if you're working
solo for a long time, you're entrenched in only your experience and you're not
getting any outside feedback.

[00:06:29] And fifth, keep all of those feelings you're
having when someone else is looking at your code at the back of your head when
you go through someone else's code. Now absolutely fix things along the way,
that's a good thing to do, but don't be snarky about it in the git comments,
right?You have to keep in mind their context was different to what you're
working on at the moment.

[00:06:52] If you get to have a face to face with the
original developer or the original development team. I'd recommend just going
through some of the top changes you made and why you thought they were
important. Now, sure they may challenge you then that's okay and that's how you
both learn from, from what is right and wrong. You may be wrong. It's an
opinion after all.

[00:07:13] So for example, I had a comment once in a
reviewed pull request that just said, "I prefer no comments in my
code".. Now, that statement, if left as it is, and if that's read by a
junior developer, you're teaching a really bad lesson.

[00:07:32]No, the senior will identify what the comment
actually means, which is make your code. Self-explanatory the so that it
doesn't rely on comments, but at the same time, don't avoid every comment
because sometimes you need to add them to clarify something that the code can
not tell you.

[00:07:52]  Anyway,
regardless of the hierarchy involved, even senior developers teach other senior
developers things. There's no way you can know everything and really try and
let go of ego both on the sending and the receiving end. I guess letting go of
ego is probably just good advice in any situation.

[00:08:13] Anyway that's all for today. Please share the
episode if you have a developer that you think might benefit from him,
subscribe for further stories like this, and of course there's a full
transcript at futurealex.com.

[00:08:27] I will talk to you tomorrow.