this post was submitted on 29 Mar 2024
977 points (98.3% liked)

Programmer Humor

19511 readers
1437 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 1 year ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 29 points 7 months ago (6 children)

Some people, like me, are not built to be developers. I can sculpt code in any language I need for whatever problem I need to solve, but maintaining code over a long period of time, with others, is not my thing.

The drive to do additional changes is just too high and the tendency for typos or obvious logic errors is too common. (There is one little improvement. It's right there. One line up. Just change it now while you are in there....)

I am not stupid and regard myself as a decent engineer but my brain is just wired in a more chaotic way. For some things that is ok. For developing code on a team, not so much.

Security is the field I am most comfortable with because it allows for creative chaos. Rule breaking is encouraged. "Scripting" is much more applicable and temporary.

[–] coloredgrayscale 12 points 7 months ago (1 children)

Make those changes in an own commit, or keep it to files you already have to touch.

[–] [email protected] 2 points 7 months ago

Now that's just crazy talk.

[–] [email protected] 9 points 7 months ago (1 children)

When using git and are working on a feature, and suddenly want to work on something else, you can use git stash so git remembers your changes and is able to restore them when you are done. There is also git add -p this allows you to stage only certain lines of a file, this allows you to keep commits to a single feature if you already did another change that you didn't commit (this is kind of error prone, since you have to make sure that the commit includes exactly the things that you want it to include, so this solution should be avoided). But the easiest way is when you get the feeling that you have completed a certain task towards your goal and that you can move on to another task, to commit. But if you fail you can also change the history in git, so if you haven't pushed yet, you can move the commits around or, if you really need to, edit past commits and break them into multiple.

[–] [email protected] 8 points 7 months ago (1 children)

Instructions unclear. Stash is 35 tall and I'm scared to look at what's been fermenting at the bottom.

[–] [email protected] 3 points 7 months ago

Only 35? That’s rookie numbers.

[–] [email protected] 7 points 7 months ago (1 children)
[–] [email protected] 7 points 7 months ago* (last edited 7 months ago) (1 children)

I do. Also, I am old(ish) so I have had many years to come to terms with what I can do well and where I struggle.

In this case, I didn't want to use it as a crutch or an excuse. After reading the number of awesome replies this morning, I realized I should have probably framed my comment differently.

People here put some real time and effort into giving some solid advice and I didn't expect that.

Edit: As a pure example, this is the third or fourth edit of this comment. Words are challenging, and programming is very similar in that regard.

[–] [email protected] 3 points 7 months ago* (last edited 7 months ago) (1 children)

Thank you so much for your reply. Your comment was so recognizable to me, and I'm in the process of being diagnosed with ADHD.

Edit: I want to say that I do feel sorry for asking such a personal thing about you. I'm not young either, but just now coming to terms with it and figuring out that this is the reason why everything I do goes as it does. To recognize it in the wild is absolutely weird.

[–] [email protected] 2 points 7 months ago* (last edited 7 months ago)

No worries! I am generally very open about it. (Your comment was recognizable to me, actually.) There is a very specific non-malicious bluntness that comes with the condition, actually.

But yeah, you have been practicing dealing with it your entire life. Treatment just helps a ton.

[–] [email protected] 6 points 7 months ago* (last edited 7 months ago) (1 children)

I tell my young developers - the primary goal in software engineering is maintainability. Code reuse, encapsulation, abstraction, and myriad other concepts all contribute to ease of maintaining source code over the long term. Maintainability allows for easier, predictable feature addition and removal, with fewer changes, and by different people. You're also a different person than the one you were months or years ago when it comes to software.

[–] [email protected] 3 points 7 months ago

Did I already post in here about how he wrote a custom DSL instead of using the standard widely used ORM we use everywhere? Maintainability nightmare.

He doesn't work here anymore and now I have to either figure it out or rip it out. So far it looks like "rip it out" because it took less than an hour to swap in the orm, and now there's just a lot less code needed.

[–] [email protected] 2 points 7 months ago

I'm the same way. Chasing code changes through the codebase then fighting with an edit rebase stack trying to explode them into less-interlocked changes.

It doesn't always work, sometimes I am just committing a giant blob of changes at work on my project I near-solo maintain 💀

[–] [email protected] 2 points 7 months ago (1 children)

Very relatable. Especially when it's less effort to make the change than it is to try and ignore it. But it's understandably harder for those who are reviewing your work.

[–] [email protected] 1 points 7 months ago* (last edited 7 months ago)

It's even more cyclical. I usually can't remember the reasons why I made the change to begin with.