767
Senior Wisdom (lemmy.ml)
top 50 comments
sorted by: hot top controversial new old
[-] Goretantath@lemm.ee 2 points 3 hours ago

You don't remember, thats what comments are for!

[-] Zink@programming.dev 7 points 6 hours ago

This one always spoke to me. But I work on embedded systems so I get to fiddle with physical equipment to really make sure the code works.

[-] ZILtoid1991@lemmy.world 13 points 11 hours ago

Comment your code. Problem solved.

[-] ipkpjersi@lemmy.ml 4 points 6 hours ago

Make sure to remember to update your comments too, otherwise it causes even more confusion when something works differently than it says it does.

[-] ZILtoid1991@lemmy.world 2 points 3 hours ago

That happened to me multiple times...

[-] sunbytes@lemmy.world 9 points 10 hours ago

And decent variable names if you can, as well.

No magic numbers!

[-] ZILtoid1991@lemmy.world 2 points 10 hours ago

WYM, I can't just name my functions foo() and my variables single letters? /s

[-] sunbytes@lemmy.world 2 points 6 hours ago

$retVal and $item are my personal favourite.

[-] aeharding@vger.social 1 points 6 hours ago

Yep, having a shitty memory makes me write better code lol

[-] Acters@lemmy.world 7 points 15 hours ago

I usually ask AI to summarize it and then I get a pretty good idea of what it was meant to do. It's just another tool to me. AI generated code sucks but it's nice when it's a quick summary.

[-] zenpocalypse@lemm.ee 2 points 5 hours ago

It's a great tool. Summaries are fantastic and "what would be a good way to code this snippet" often teaches me something new.

I also find it's helpful to ask about best practices when I'm not sure.

Anything beyond short scripts, though, and you're going to spend more time than you saved fixing it.

[-] JustAnotherKay@lemmy.world 3 points 14 hours ago

This is a solid use of AI.

Basically the equivalent of saying "Take a look at these characters and run it against a huge database to see if you find anything similar with documentation of its purpose"

[-] kamen@lemmy.world 5 points 14 hours ago

For anything that doesn't seem entirely obvious I try to leave a comment. It could end up being helpful to me some time later, because let's face it: your code is indistinguishable from someone else's code 2 weeks after you commit it.

[-] JustAnotherKay@lemmy.world 2 points 14 hours ago

For anything ~~that doesn't seem entirely obvious~~ I try...

I've come to teach myself that I have no idea what "entirely obvious" is.

This function is 3 lines long why am I boggled by it right now? I should have written a comment

[-] kamen@lemmy.world 3 points 13 hours ago

Well, over time, you accumulate some judgment about things like that. But you have some point too.

[-] JustAnotherKay@lemmy.world 2 points 12 hours ago

Yeah, it's honestly mostly an issue of me dipping into programming and not properly sticking to it for long enough to wrap my mind around some concepts. I heard all the warnings that "learning to program is usually one of the hardest things someone has accomplished" because of how late we learn it and all the other complications. I also, however, have heard my whole life that I learned fast and picked things up easily. Boy oh boy was one of those messages more useful than the other lol

[-] boringbisexual@lemmy.blahaj.zone 5 points 17 hours ago

Oh I remember what it does...I do not remember how it does.

[-] Mniot@programming.dev 8 points 21 hours 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
[-] jimmux@programming.dev 5 points 18 hours ago

I'm still waiting for the day I see UML in a professional context. My undergrad teachers were all about it.

Similarly, I don't design software using design patterns, and I've had to discourage juniors from forcing them into projects where they don't add any value. But that's not to say design patterns aren't useful. They do exactly what you say, allowing your brain to recognise a pattern so you can remember or communicate it without having to go into details. Most of the time it won't be an exact fit for the ideal pattern implementation, but it's still easier to remember the variation.

I wish they were taught more as communication and cognitive tools than silver bullets for good software design.

In the real world there aren't even that many patterns. On a very large project you're likely to see the same patterns repeated throughout the system, because a good architecture doesn't add variation and complexity unless there's a lot of value to gain. You learn the default way, and then the diffs.

[-] Mniot@programming.dev 2 points 6 hours ago

Actual UML-according-to-some-books is old and unpopular now. I think C4 is taking its place, in that I've seen architect-types ask for it. More generally, I really like PlantUML and the prettier-looking Mermaid which both allow me to code diagrams using a text document.

Yeah, I agree: academia gets people expecting to go, "give me 2x Visitor Pattern, then 1 Builder Pattern, then as many Divide and Conquers as you need to reach the end". It can be nice to have a name for things, but most of the time I'm asking for, "see how the setup, actual work, and cleanup are nicely divided up? Do like that." Or, "let's put all the related endpoints in the same file."

[-] fubarx@lemmy.world 111 points 1 day ago* (last edited 1 day ago)

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.

[-] Nithanim@programming.dev 2 points 11 hours ago

Most code I forget too. For a lot of stuff I might vaguely remember when looking at it but some I would deny ever even having seen even when I wrote it (that happened). However, there are some rare parts I could probably still navigate from my previous company and there are some in my current. Really depends on the connection you have to the code.

[-] eager_eagle@lemmy.world 89 points 1 day ago* (last edited 1 day ago)

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

[-] Gumbyyy@lemmy.world 4 points 1 day ago

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

[-] Lemminary@lemmy.world 27 points 1 day 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.

[-] Aceticon@lemmy.dbzer0.com 3 points 23 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.

[-] Goldholz@lemmy.blahaj.zone 27 points 1 day ago

You dont. Thats why you write comments!

[-] CodeBlooded@programming.dev 8 points 1 day ago* (last edited 1 day ago)

Code never lies; comments sometimes do.

[-] cbazero@programming.dev 19 points 1 day ago

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

[-] Gumbyyy@lemmy.world 9 points 1 day ago

Yes. And also comments :-)

[-] Maalus@lemmy.world 7 points 1 day ago

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.

[-] bpev@lemmy.world 4 points 18 hours ago* (last edited 17 hours ago)

Mmmm kind of? I wouldn't categorize most comments as describing "extremely weird" reasons, though. Code will generally explain the "how", while comments can describe the "why". For example, think of an enum with ViewSize "mini" and "full". It might be nice to have a comment to briefly summarize what ViewSize is meant to represent, and maybe link to a spec. Basically, a comment here will connect the intention with the implementation.

A more inline-comment example of this might be if there's a slightly nuanced case that you want to be very clear about, ala maybe a Javascript true/false/null case, where you might be checking === false, and specifically don't want someone to refactor it into a falsy check. Kind of contrived example , but that sort of thing. This is probably more the "extremely weird" comment you're talking about; almost just a warning that this might not be what you think it is.

The other common use-case I find good for comments is for summarizing the goals/purpose of a complex function. This is mostly for future people who might utilize this function, and don't want to read through a bunch of code, just to remember the nuances of what it's supposed to do. For example, a "sortEvents" function, you may want to summarize the business requirements of the sort at the top. Although, this kind of thing may be different depending on how documentation is stored.

[-] ruekk@lemm.ee 8 points 1 day ago

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.

[-] jimmux@programming.dev 1 points 18 hours ago

I thought the same, until I spent a few years on a codebase where self-documenting code was enforced with detailed code reviews. That does a very good job of clearing up the ambiguity.

If you can't get that kind of review, then by all means use comments.

load more comments (6 replies)
[-] Ephera@lemmy.ml 61 points 1 day ago

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.

[-] rockerface@lemm.ee 32 points 1 day ago

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.

load more comments (1 replies)
[-] Sauerkraut@discuss.tchncs.de 8 points 1 day ago

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

[-] skrlet13@feddit.cl 16 points 1 day ago

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

  • encapsulation and meaningful function names.
load more comments (1 replies)
[-] some_guy@lemmy.sdf.org 44 points 1 day ago

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 1 day 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.

[-] bitwolf@sh.itjust.works 32 points 1 day ago

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.

load more comments (2 replies)
[-] wise_pancake@lemmy.ca 22 points 1 day ago

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

load more comments
view more: next ›
this post was submitted on 14 Mar 2025
767 points (98.9% liked)

Programmer Humor

21534 readers
1740 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