this post was submitted on 14 Mar 2025
593 points (99.3% liked)

Programmer Humor

21487 readers
1667 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 2 years ago
MODERATORS
 
all 44 comments
sorted by: hot top controversial new old
[–] Mniot@programming.dev 2 points 42 minutes ago

As an undergraduate, I wondered how it was possible to write code professionally, because I could only barely fit the semester-long programming assignment in my head. When I asked my professor about it, I got an independent study credit to learn about UML.

UML (as a representative example of thoughtful documentation) is a partial answer. But actually a much larger part is that with practice I can hold a lot more code in my head. Today, that semester project seems trivial and if I see a stack trace I can tell you how to fix the bug that caused that exception to get thrown.

As a senior dev, I'd answer "how do you remember what your code does?" with

  1. As you work, you get better at just remembering
  2. As you find patterns and follow them, you'll have less to remember (I bet I know what the downloadUnpackUpdate() method does!)
  3. As you do the first two, you'll learn to recognize when comments are helpful
[–] Aceticon@lemmy.dbzer0.com 1 points 2 hours ago

The entire purpose of writing good readable code which is mostly self-explanatory and were it isn't it's properly commented to explain what's going on, is so that it it's not a necessary for the person who picks it up later to be somebody who does remember what that code does and how it does it.

Whilst this is mainly important to allow other people to work in that code, as a side effect the actual person who wrote the code if they follow those coding principles needs not remember what it does and how it does it.

One of the upsides of being a senior dev is having figured this kind of thing out from experience, which offsets the downside that since you're older and have done a ton of things, it's less likely that you will properly remember the details of a specific code base after some months of not looking at it.

[–] skrlet13 17 points 13 hours ago (2 children)

In a more serious note, that's why you document your software!

  • encapsulation and meaningful function names.
[–] Goldholz@lemmy.blahaj.zone 25 points 15 hours ago (2 children)

You dont. Thats why you write comments!

[–] CodeBlooded@programming.dev 1 points 4 hours ago* (last edited 4 hours ago)

Code never lies; comments sometimes do.

[–] cbazero@programming.dev 15 points 13 hours ago (1 children)

You dont. Thats why you write code that explains itself. For higher level info you write documentation.

[–] Gumbyyy@lemmy.world 6 points 5 hours ago (1 children)

Yes. And also comments :-)

[–] Maalus@lemmy.world 2 points 5 hours ago (1 children)

The only moment you write comments is when you are doing something extremely weird for a specific reason that will not be immediately obvious and you want to warn the person doing a refactor in the future. In any other case, writing self documenting code is the way. If you are unable to do that, then your code needs to be rewrtitten.

[–] ruekk@lemm.ee 6 points 4 hours ago (1 children)

Self documenting code is a myth as what's self documenting to one person is not to the next. Code comments and process/workflow documentation is needed for a healthy codebase.

[–] fubarx@lemmy.world 96 points 22 hours ago* (last edited 14 hours ago) (3 children)

My first tech job out of college, I was told to go talk to "Dave," the guru old-timey programmer and learn the lay of the land. He turned out to be this crotchety old guy, with low tolerance for idiots, but a soft spot for someone who actually paid attention.

A few months in, I was told to go fix a feature in the company's main product which was sold to power utilities. This was a MASSIVE code base, with a mix of C, C++, assembler, and a bit of Fortran thrown in. I spent a week poring through all the code trying to figure things out. Then I hit a mystery workflow that didn't make sense.

I walk over to Dave's office and ask a specific question. Now, mind you, he had worked on this years ago, and had long moved on to new products. He leans back in his chair, stares at the ceiling, then without looking at the screen once tells me to go look at such and such file for such and such variable, and a list of functions that were related. I go back to my desk and damn if it wasn't EXACTLY as he described.

Now, I'm probably as old as he was then. I don't remember what I wrote an hour ago. No matter what I build, I'll always be in awe of Dave and what he could keep in his head.

[–] Gumbyyy@lemmy.world 4 points 5 hours ago

I wish my brain worked half as well as guys like that.

[–] eager_eagle@lemmy.world 76 points 20 hours ago* (last edited 20 hours ago)

Plot twist: Dave had cheat sheets for previous projects glued to the ceiling

[–] Lemminary@lemmy.world 21 points 19 hours ago

Alt theory: The guy you replaced failed miserably. Dave poked around but decided it wasn't worth his time fixing. Instead, decided to look badass for the cameras and died a legend.

[–] Ephera@lemmy.ml 54 points 22 hours ago (2 children)

Which is why making code readable is so very important. Our juniors and students will think we're ridiculous, when we spend a long time cleaning up some code or choosing the least misunderstandable name for a type. But you fuck that up and then others, as well as your future self, will be wasting many more minutes misunderstanding what your code does.

[–] Sauerkraut@discuss.tchncs.de 7 points 11 hours ago

Readable code is especially important when companies lay people off every six months so you constantly lose expertise

[–] rockerface@lemm.ee 29 points 20 hours ago (1 children)

I treat my future self a few months from now as a separate person who does not remember anything about why or what the specific code fragments do. And I'm grateful to my past self for doing the same.

Plus, you never know when you need to actually delegate supporting a particular piece of a solution to another person.

[–] homoludens@feddit.org 8 points 17 hours ago

Write your code as if the next person that works with it is a violent psychopath who knows where you live.

[–] bitwolf@sh.itjust.works 31 points 20 hours ago (1 children)

Partially yes. But if I create something myself I can "revisit" the headspace of that portion very easily, like I walked into a room.

Doesn't work as well on codebases I don't own fully though.

[–] Ephera@lemmy.ml 11 points 19 hours ago (1 children)

Yeah, which is why pairing works so well. Suddenly, you've got two people who were there when it was created and might know why certain design decisions were made.

[–] OmgItBurns@discuss.online 1 points 4 hours ago

Which means twice the savings when you unexpectedly lay them both off!

[–] some_guy@lemmy.sdf.org 43 points 22 hours ago (1 children)

This made me chortle. I remember when I first joined a dev team asking someone how many of something their section should be able to store:

I don’t know, I’d have to look at the code.

It was an eye opening moment. Very few people can keep everything in their head. I’ve met a couple. They were rockstars who were truly exceptional.

[–] livingcoder@programming.dev 22 points 22 hours ago

For me it all depends on how often a project changes. If it's constantly in flux, I don't bother remembering any of it because I might not be the last one who touched it. The more you try to remember everything, the more wrong you become due to the successive work of your coworkers.

[–] wise_pancake@lemmy.ca 22 points 22 hours ago

The people who say "the code is the documentation" totally misunderstood what that was supposed to look like

[–] Spacehooks@reddthat.com 5 points 20 hours ago

The code is so convoluted the programmer has no idea how it works. Just tables and arrays references each other.