Ask Lemmy
A Fediverse community for open-ended, thought provoking questions
Rules: (interactive)
1) Be nice and; have fun
Doxxing, trolling, sealioning, racism, and toxicity are not welcomed in AskLemmy. Remember what your mother said: if you can't say something nice, don't say anything at all. In addition, the site-wide Lemmy.world terms of service also apply here. Please familiarize yourself with them
2) All posts must end with a '?'
This is sort of like Jeopardy. Please phrase all post titles in the form of a proper question ending with ?
3) No spam
Please do not flood the community with nonsense. Actual suspected spammers will be banned on site. No astroturfing.
4) NSFW is okay, within reason
Just remember to tag posts with either a content warning or a [NSFW] tag. Overtly sexual posts are not allowed, please direct them to either [email protected] or [email protected].
NSFW comments should be restricted to posts tagged [NSFW].
5) This is not a support community.
It is not a place for 'how do I?', type questions.
If you have any questions regarding the site itself or would like to report a community, please direct them to Lemmy.world Support or email [email protected]. For other questions check our partnered communities list, or use the search function.
6) No US Politics.
Please don't post about current US Politics. If you need to do this, try [email protected] or [email protected]
Reminder: The terms of service apply here too.
Partnered Communities:
Logo design credit goes to: tubbadu
view the rest of the comments
I've worked in programming for the last ten years and the most important skill you might not have guessed: Bravery. People are going to say "if it works, don't fix it", but a lot of real-world code barely works, and you need to be willing to break it to make it better.
If you're good at your job, you will spend a lot of time reading other people's code and testing small changes to see what happens. Write "new" code for yourself, because it's fun and its good practice, but also learn to read and repair "old" code.
I mostly agree with your post. I take exception to the barely works part. Either the code works or it doesn't. If it doesn't work, fix it. If it works, don't fix it.
If you "fix" working code, you are spending time adding no value to the project. You could even argue you're adding negative value because the people who are used to the code working the way it was now have a surprise.
Good callout! I agree, don't rewrite just for the sake of rewriting. By "barely works" I am referring to code that functions but where a small change to the requirements would make it incorrect. In that situation you should "break it" in order to add changes, rather than calcifying the legacy code by building around it.