Timeline for If my team has low skill, should I lower the skill of my code?
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 16, 2020 at 10:01 | history | edited | CommunityBot |
Commonmark migration
|
|
| Oct 25, 2015 at 22:58 | comment | added | Nick Alexeev | I'm glad you've netioned clever code. Here's a somewhat related thread involving clever code issues: programmers.stackexchange.com/q/289518/134647 | |
| Sep 9, 2013 at 15:08 | comment | added | Corion | @Pappa It's important to stress that it's just a chance, not guaranteed. But yes - certainly we shouldn't attempt to fix bad code by adding comments. "If the comments aren't updated to match" is perhaps one more argument in favor of hiring better programmers. | |
| Sep 8, 2013 at 18:09 | comment | added | Pappa | Comments aren't always good. I read "Clean Code" a while back and some points he makes about comments are excellent. If you feel the need to write comments to explain your code, there's a good chance that the code is badly written. If the code was more expressive, a comment is superfluous. Every time you're about to write a comment, stop for a moment to consider if refactoring might be a better option. If code is expressive, explaining its purpose becomes unnecessary. Also, comments can become misleading or simply wrong if code is changed but comments aren't updated to match. | |
| Jul 3, 2013 at 20:31 | history | edited | Corion | CC BY-SA 3.0 |
added 11 characters in body
|
| Jul 3, 2013 at 20:24 | history | edited | Corion | CC BY-SA 3.0 |
added 101 characters in body
|
| Jul 3, 2013 at 14:48 | comment | added | Corion | @FlorianMargaine I work primarily in JavaScript as well, I know the pain you're feeling. I've approached this by trying to educate teammates. The Crockford JavaScript videos (1, 2) help. I don't think those things you listed fall under "clever" tricks- your teammates should learn them- but some of the things you do with those language features could be the bad kind of "clever". How to convince your company to hire experienced Devs is probably another question entirely... | |
| Jul 3, 2013 at 13:16 | comment | added | Katana314 | If it eases any of your headache, part of the frustration may be that Javascript as a language...doesn't make sense. It makes sense to US, the people posting here, because we've done it a long time. But no matter how we've made the language to work "well", to the neutral eye it just doesn't make sense. On another note; you may, sadly, be demonstrating the value of hiring experienced devs, or preferably, 'any-language' developers with a high willingness to learn new paradigms. | |
| Jul 3, 2013 at 11:19 | comment | added | Andrew Bickerton | @FlorianMargaine sounds to me like you need to work on changing the terminology, ie: these aren't "clever tricks", these are more advanced features of the language... 1 implies your code is not readily understood/a bad thing, 2 implies an opportunity to learn and improve 'my' coding skills (how to get others to change their terminology? Comments, encourage questions, share code articles explaining how these features are useful, etc...) | |
| Jul 3, 2013 at 8:21 | comment | added | Florian Margaine | The issue is that language features are seen as "clever tricks", even when I think they clearly aren't. Ever seen a closure? Ever seen an IIFE? Ever seen a function reference passed as a callback? Those are language features that every experienced JS dev knows. Yet they're "clever tricks" to less-experienced JS devs. | |
| Jul 2, 2013 at 23:42 | history | answered | Corion | CC BY-SA 3.0 |