this post was submitted on 20 Nov 2024
237 points (98.4% liked)
Programmer Humor
32558 readers
525 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
i think i struggle with this part the most since i'm entirely self taught and relied on very old methods for writing my source since the educational material i used was the most common and freely available at the time i starting doing development work. i've learned that it was acceptably sufficient for the IT-based problems that i was trying to solve at the time i learned it and that legacy style has been keeping me at a disadvantage.
if seen some of the newer style of debugging like the one you're shared from the young fresh graduate developers who are lucky enough to be spared the slog of a over decade within "customer service" oriented side of the tech industry umbrella and it's painfully evident to me how vastly superior it is compared to the old methods that i taught myself and it's encouraged me to seek a degree to help me master them and my new job will make that degree free for me; which matters A LOT as an american considering the price tag it entails.
I find a good approach to getting better at programming is to reflect on the projects you've done and try to identify patterns that got you into trouble. Then you can try doing things differently next time, and eventually you end up settling on a style that works for you. At the end of the day it's really just practice. The one key thing I've learned to focus on is reducing the operating context I need to have when reading the code. Once the context becomes too big to keep in your head, then trouble starts. So breaking things up aggressively into small components you can reason about in isolation tends to be the best way to write reliable code you can maintain over time.