5 ms·

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

by itronitron 2y ago

thecleaner 2y ago
> it also builds self-esteem. Well crafted dig.
- yohannesk 2y ago
  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
  - baobabKoodaa 2y ago
    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.
    - lanstin 2y ago
      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.
- ethbr1 2y ago
  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.
  - TheNewsIsHere 2y ago
    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.
  - tpmoney 2y ago
    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.
    - progmetaldev 2y ago
      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).
      - cabidaher 2y ago
        Pitching in to your and parent comment but from the junior side to say that yes, this definitely helps :)
- kerkeslager 2y ago
  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.
  - samus 2y ago
    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.
    - kaffekaka 2y ago
      All of these, I have been guilty of. Fairly recently, too.
    - yxhuvud 2y ago
      And not to forget: business realities change over time, but it is not always the code follow.
  - Capricorn2481 2y ago
    Such a rare opinion on HN unfortunately. But you're correct.
  - Terr_ 2y ago
    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 https://en.wikipedia.org/wiki/Fundamental_attribution_error
- deleted 2y ago
  [deleted]
- underdeserver 2y ago
  Also why I used to like interviewing.
spike021 2y ago
ironically most people can say the same about coming back and reading their own old code
- samus 2y ago
  In important regards, you sometimes become a different person :-)
- klik99 2y ago
  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
- rectang 2y ago
  "No wonder that didn't work."
hollywood_court 2y ago
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.
- CursedSilicon 2y ago
  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"
  - hollywood_court 2y ago
    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.
throwaway5752 2y ago
Self-esteem and empathy.
ljm 2y ago
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.
catlifeonmars 2y ago
Conversely, reading through my own code from ancient history (>3 months ago) is both humbling and terrifying :D
- epolanski 2y ago
  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.
  - readyplayernull 2y ago
    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.
  - 3vidence 2y ago
    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 .
- throwaway422432 2y ago
  It's often "What was I thinking" or "What was I on" as Kernighan's Law bites you again.
lcfcjs6 2y ago
Unless the "other peoples code" actually turns out to be yours that you wrote years ago, and forgot about :D
- kijin 2y ago
  git blame is the best teacher of humility.
aulin 2y ago
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.

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

thecleaner 2y ago

> it also builds self-esteem. Well crafted dig.

yohannesk 2y ago
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
- baobabKoodaa 2y ago
  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.
  - lanstin 2y ago
    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.
ethbr1 2y ago
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.
- TheNewsIsHere 2y ago
  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.
- tpmoney 2y ago
  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.
  - progmetaldev 2y ago
    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).
    - cabidaher 2y ago
      Pitching in to your and parent comment but from the junior side to say that yes, this definitely helps :)
kerkeslager 2y ago
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.
- samus 2y ago
  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.
  - kaffekaka 2y ago
    All of these, I have been guilty of. Fairly recently, too.
  - yxhuvud 2y ago
    And not to forget: business realities change over time, but it is not always the code follow.
- Capricorn2481 2y ago
  Such a rare opinion on HN unfortunately. But you're correct.
- Terr_ 2y ago
  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 https://en.wikipedia.org/wiki/Fundamental_attribution_error
deleted 2y ago
[deleted]
underdeserver 2y ago
Also why I used to like interviewing.

spike021 2y ago

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

samus 2y ago
In important regards, you sometimes become a different person :-)
klik99 2y ago
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
rectang 2y ago
"No wonder that didn't work."

hollywood_court 2y ago

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.

CursedSilicon 2y ago
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"
- hollywood_court 2y ago
  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.

throwaway5752 2y ago

Self-esteem and empathy.

ljm 2y ago

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.

catlifeonmars 2y ago

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

epolanski 2y ago
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.
- readyplayernull 2y ago
  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.
- 3vidence 2y ago
  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 .
throwaway422432 2y ago
It's often "What was I thinking" or "What was I on" as Kernighan's Law bites you again.

lcfcjs6 2y ago

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

kijin 2y ago
git blame is the best teacher of humility.

aulin 2y ago

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.