It's a refreshing take on the standard developer white-dress-shirt-no-tie-and-slacks resume, but I abhor the phrase "clean code". It's self-important and utterly meaningless given that code you write will be picked over by multiple people throughout the lifetime of the software. Instead, I personally value developers who understand effective abstraction.
Mentioning 'clean code' is surely a message that the OP understands that his code will 'be picked over by multiple people throughout the lifetime of the software'?
I'll take clean domain level clear and concise coding even if it under-delivers on the abstractions occasionally. Code will always be read and maintained more often than it is aggressively extended.
Well, the purpose of constructing an abstraction is at least as much about DRY and SRP as about providing extensible base classes in an object-oriented language.
I think we tend to agree given that you prefer 'concise coding' which I'll take to mean DRY and 'straightforward' rather than 'clever'.
But by 'picked over', I literally meant 'changed to meet changing requirements' rather than 'read for comprehension'. In that sense, the fact that one guy on the team considers the code he writes to be 'clean' is rather meaningless when many hands might work in that pathway. Composable approaches tend to be more resilient to regressions, well, in my experience anyway, YMMV.
I guess my problem with 'clean code' is that it's too open to interpretation. What do you specifically do that makes your code better than the other guys?
> What do you specifically do that makes your code better than the other guys?
Nothing specific, I'm just saying I value my code well-structured and readable, as well as DRY and straightforward. The proof is in the pudding (my open-source software), of course.
