252
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 17 Sep 2023
252 points (97.4% liked)
Programming
17025 readers
111 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 1 year ago
MODERATORS
Because reviewing code is easier than writing it, unfortunately.
I disagree with that as a rule of thumb. I'll take writing 1000 lines of code from scratch every time over deciphering 1000 lines of bad code.
However, I do you think are right if limited to the ~100ish lines that fit into an hour sized block of interview time. I suspect the other half of the answer is (good) job postings have largely gotten away from hard language requirements. It's perfectly reasonable to hire someone that will need to familiarize themselves with Go or Python or Typescript or whatever. It's not fair to expect someone to analyze code in a language they haven't used on the spot.
Even deciphering 1000 good lines of code is hard . I work in abap and 95% of my time is going through old ,or very old code written in diffrent programing styles . The rest is usualy writing a one or two lines of code.
Maintaining a code base is definitely harder than writing new code, in my experience.