3 ms·

It's better to know that you're not a good developer than to think you are, blissfully unaware of the problems in your code. I've worked with plenty of people w

by EnderMB 10y ago

It's better to know that you're not a good developer than to think you are, blissfully unaware of the problems in your code. I've worked with plenty of people with "good reputations" that have failed to deliver a clean product, or have criticised code that works well for not being optimal in their eyes. It's important to know why the code you've written is not considered good, so ask your co-worker about the problems he/she has noticed. If they are legitimate problems then highlight them with your line manager, and offer a solution/fix that will improve your code. No one is perfect, and more often than not good programmers are those who iterate and adapt to changing requirements. If they notice problems with their solution, they'll happily point them out, and will offer a solution. Ask what you can do to fix the problems, and once you have your solution it's unlikely that you'll make that problem again.

sadjuniordev 10y ago
Some people are never happy and always judge others. How do I know if my coworker will ever be happy with my code? What if he just hates me? I can't tell the difference :(
- EnderMB 10y ago
  It's a tricky one. I can tell a chef when their food tastes like shit, but I can't cook like a chef can, and I probably couldn't tell him/her what he needs to do to make their food taste better. It might not even be a bad meal! It might just be different to what I'm used to. It's entirely possible that your co-worker doesn't know what would improve your code, but simply knowing that it can be improved can be a useful thing, as it urges you to explore other options. Since your co-worker has said that your code is "WET" (I assume the opposite of DRY?) this should lead you to look into what makes code DRY in your language, and through this, learning if your code is repeated for a reason or not. As a personal anecdote, on a recent project a junior developer slated some of my Razor code because I wasn't using EditorTemplates for the forms on the site. After a month or two on the project, that developer quickly learned why I didn't bother with EditorTemplates. Fields that seemed similar weren't similar at all at times. The project requirements were changing weekly, and ultimately I was able to make changes quickly while he was fiddling with his DisplayTemplates/EditorTemplates, trying to make them work reliably across multiple different scenarios.

by EnderMB 10y ago

sadjuniordev 10y ago

Some people are never happy and always judge others. How do I know if my coworker will ever be happy with my code? What if he just hates me? I can't tell the difference :(

EnderMB 10y ago
It's a tricky one. I can tell a chef when their food tastes like shit, but I can't cook like a chef can, and I probably couldn't tell him/her what he needs to do to make their food taste better. It might not even be a bad meal! It might just be different to what I'm used to. It's entirely possible that your co-worker doesn't know what would improve your code, but simply knowing that it can be improved can be a useful thing, as it urges you to explore other options. Since your co-worker has said that your code is "WET" (I assume the opposite of DRY?) this should lead you to look into what makes code DRY in your language, and through this, learning if your code is repeated for a reason or not. As a personal anecdote, on a recent project a junior developer slated some of my Razor code because I wasn't using EditorTemplates for the forms on the site. After a month or two on the project, that developer quickly learned why I didn't bother with EditorTemplates. Fields that seemed similar weren't similar at all at times. The project requirements were changing weekly, and ultimately I was able to make changes quickly while he was fiddling with his DisplayTemplates/EditorTemplates, trying to make them work reliably across multiple different scenarios.