Hacker News Reader

Comment by itronitron | Hacker News Reader

Additionally, reading through other people's code is educational and it also builds self-esteem.

Conversely, reading through my own code from ancient history (>3 months ago) is both humbling and terrifying :D

This happens to me all the time, but mostly with work code.

I'm under pressure, I have to deliver, things get rewritten many times, edge cases are found and fixed in production after they slipped through multiple qas but need to be fixed instantly or we lose money.

It happens.

But personal code? I am almost always proud of my work. It shows in general I was not under pressure and enjoying building it.

Even my code from the first year of programming, it shows it was made to make a point in writing a nice solution.

I may cringe at times, but still proud.

Context does matter, and code quality is more often than not a byproduct of our emotional state rather than skills.

Like a shiny coat of paint that blinds me, I scrape my code and write new in place, maybe this time with comments so I don't forget.

I feel very similarly about the split between my professional and personal code.

Theres always something that needs to be rushed out the door at work and honestly nobody pays me for pretty code.

But my own projects? The code is a large part of why I do it .

It's often "What was I thinking" or "What was I on" as Kernighan's Law bites you again.

I find this to be true in many aspects of life. Just watching how other people do things is often a huge self-esteem boost for myself.

A quip I'm often fond of that I think I stole from an old web comic eons ago

"I can't ever get even with past-me, and I'm already on thin ice with future-me"

I'm doing my best to prevent myself from being on thin ice with my future-me.

I posted recently about how I divorced not too long ago. I'm in an apartment now (for the first time in 16 years) while I stack up cash to build a new house.

I always think I'm not making any progress but then I see my next door neighbors ordering DoorDash 15+ times per week, and I realize that I'm doing pretty damn good for myself.

Or I walk by the mirror and think about how I've neglected my lifting for the past 6 months while I finished up this SWE degree. But I'll see those same neighbors struggle to walk up the stairs and I again realize that I'm making some awesome choices compared to those two folks.

> it also builds self-esteem.

Well crafted dig.

I don’t think there was any dig implied. And I will second that it will add to self esteem. Specially during discussions if you have more understanding about the code you will have both better contribution and take away

Sure, when you succeed in understanding someone else's legacy codebase, it builds self esteem. When you fail attempting to do that, it does the opposite.

I have inherited projects where I just could never understand what they were thinking well enough to make the service good (not running out of memory and crashing). It was very humbling; I still sometimes wake up in the middle of the night with things I wish I'd tried, but the assumptions of how it all worked was just scattered throughout a bunch of files and the assumptions of everything was just not how I'd do it.

Imposter syndrome is fueled by colleague deification.

It's easy to view smart coworkers as superpeople... until you're reminded that they, on occasion, make dumb human mistakes too.

This is a fantastic insight.

I used to suffer from imposter syndrome significantly. It helped to see the mistakes others made which anyone could have made. It also helped to have my own good ideas and talent explicitly acknowledged. Learning to not take criticism personally and own your own mistakes also helps to rob imposter syndrome of its power because it demonstrates to others that you can be forthright and self aware, and that helps build trust.

I’ve found one of the best things I can do to help my jr devs feel more confident (and be willing to ask for help) is highlight my screwups and “basic” things I’ve just learned. It make me seem more approachable and less like everything I say is a pronouncement from on high, it makes them more willing to admit to their own mistakes, it clarifies that we’re all learning stuff all the time and it helps spread knowledge about things that folks might otherwise be too afraid to ask about for fear of looking silly.

A benefit of being a sr dev is getting the benefit of the doubt on mistakes, so I might as well use that to my advantage and let everyone learn from them, not just me.

I 100% agree with you, and have used the same technique. Showing juniors that you are also human and make mistakes allows them to be less anxious about learning and trying new things. It also helps to keep them from trying to hide their mistakes which can quickly lead to larger system issues.

Of course, you have to have a culture where making a mistake doesn't immediately lead to being let go or publicly reprimanded. I have definitely learned quite a few things about people and code by helping juniors work through bugs that may not have been so obvious (including occasionally finding bugs in 3rd party libraries).

Pitching in to your and parent comment but from the junior side to say that yes, this definitely helps :)

I find that I have to argue a lot for making systems where humans are allowed to be human and not burn the house down.

Operationally, people gravitate toward trying to treat the humans as machines.

We have machines for that.

Sure, but if there's anything I've learned from working on legacy software, it's that I don't know why the code was written the way it was. I'm not the only smart person to work on a codebase, and it's more common that another smart person did what they did for a reason, than that I'm a genius who knows better than they did.

Sometimes there were reasons, but they were not necessarily good ones. Like these:

- time pressure, leading to just making it work and not caring about edge cases, which were bolted on later. Or maybe never at all. And naturally, there is no useful testsuite.

- the prototype ended up in production

- a refactoring happened, but there was no follow-up into other areas of the code base

- features changed, but the code is still influenced by the necessities of the old way it worked. Similarly, for changing technical circumstances

- code was copy-pasted or was worked on by too many people

- code was herded too long by the same person and now, to put it nicely, bears traces of their bespoke coding style

Chesterton's Fence is still very relevant, therefore I'd still err on the side of writing a lot of high-level tests before touching anything.

All of these, I have been guilty of. Fairly recently, too.

And not to forget: business realities change over time, but it is not always the code follow.

Such a rare opinion on HN unfortunately. But you're correct.

Kind of light fighting against the human tendency [0] to blame the failings of others on their core character rather than the situations they are in, and vice-versa for oneself.

[0] https://en.wikipedia.org/wiki/Fundamental_attribution_error

Also why I used to like interviewing.

ironically most people can say the same about coming back and reading their own old code

In important regards, you sometimes become a different person :-)

I forget who said it “The worst programmer I’ve ever seen is me a year ago.”

I found it true for the first five years into my career, now it’s still true but with a longer time scale, which I suppose is progress

"No wonder that didn't work."

Self-esteem that easily turns into hubris though. I think the real seniority shows when you are able to work on a legacy codebase full of the shittiest code and not have the slightest desire to rewrite it all.

I think that value comes from code that solves tough or complex problems, which can be humbling while improving your understanding. Feels good when you get a grasp of what’s going on and can understand that there may not be a simpler approach, just a different one.

There’s also legacy code that is not great and is not solving a complex problem but is just a product of the conditions at the time. It’s easy to look at that and assume you can do better given the same constraints, and this is neither educational nor esteem-building. Just an ego massage.

Unless the "other peoples code" actually turns out to be yours that you wrote years ago, and forgot about :D

git blame is the best teacher of humility.

Self-esteem and empathy.

Reply on news.ycombinator.com