this post was submitted on 25 Oct 2025
64 points (100.0% liked)

Programming

23273 readers
291 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] blarghly@lemmy.world 15 points 3 days ago (9 children)

Agreed with pretty much everything here. My notes:

  1. Read about software patterns - the gang of 4 book and Fowlers book are classics. This will help you read and understand legacy code, and write your own code with understandable structures and naming conventions.
  2. All skill learning inevitably comes with making mistakes that you regret later, and which will make you look dumb. Embrace it. If you have to think too hard to come up with a clever name for a variable, give it a stupid long name - the dev 5 years later working on your code would much rather have a variable with a name so long it runs off the page, but actually describes its purpose accurately, than a short named variable that is "clever". If you or someone else thinks of a better name later, renaming variables is trivial. Interpreting variable purpose from an unclear name is not. Similarly, make your methods short - really, really short. If you have 10 lines of code and put them each in their own method, great! Maybe it isnt the fastest code to read - but readable method names will make it obvious what each line does, and combining independent methods together is far easier than breaking one massive method into chunks.
  3. TDD (or BDD) is awesome for turning most of the things listed here into habits. It also, ime, makes boring enterprise software development far more enjoyable, since you start by making a long checklist of itty bitty tasks, and then get to check a new one off every 5 or 10 minutes, knowing that the task is done.
  4. The best way to learn how to write better code is pair programming with a more senior developer. Often employers will refuse to budget time for this since "how can we justify paying two developers to write the code one developer could?" The fact is, developing like this typically decreases development time as juniors' code ends up more readable and with fewer bugs, reducing time spend on fixing bugs later - the most time-intensive part of any software project. If managers still won't budge - fuck 'em. Do it anyway. Getting someone to critique your code in real time - even for just 30 minutes per day - will rapidly improve your skills.
[–] doeknius_gloek@discuss.tchncs.de 8 points 2 days ago (3 children)

Similarly, make your methods short - really, really short. If you have 10 lines of code and put them each in their own method, great! Maybe it isnt the fastest code to read - but readable method names will make it obvious what each line does, and combining independent methods together is far easier than breaking one massive method into chunks.

I agree with a lot you said and this reads like advice straight from Robert Martins "Clean Code", but I've recently read a discussion between him and John Ousterhout, where John makes compelling arguments for longer, "deeper" functions. I found the discussion very interesting and actually started reading "A Philosophy of Software Design" shortly after. Would recommend!

[–] FishFace@piefed.social 7 points 2 days ago

I think Ousterhout's observation that deep interfaces are more useful is a very astute one. There is a kind of programmer who finds it satisfying to write lots of boilerplate but it doesn't make the code maintainable.

Short functions can be good because you then name each short section of code, but a comment can offer that more flexibly.

load more comments (2 replies)
load more comments (7 replies)