4 ms·

I highly disagree with this. There is such a thing as domain expertise. For example, machine learning, compiler design, graphics programming, etc. If you are s

by tensor 10y ago

I highly disagree with this. There is such a thing as domain expertise. For example, machine learning, compiler design, graphics programming, etc. If you are say, a web developer these people might seem like geniuses to you, and no, you wont' be able to pick up and understand their code. This isn't because it's not documented well enough, or that it's not written well, it's because you lack the domain knowledge to understand it. For example, I've written code that you absolutely will not understand without weeks or more of study in the domain. The code is documented, and has links to science papers that you need to read to understand it. But know that you may need to spend months to learn enough to really know it. It's not the responsibility of the domain expert to teach you an entire domain. So yes, they may just tell you to trust them instead of telling you to go study some volume of domain work. It would be better if they did the latter, but I suspect that many here would still complain with that answer.

Roboprog 10y ago
Agreed. Background / culture makes a big difference on how well devs can understand each other's code. I still wish more of my teammates (past & present) wrote more comments (as in "statement of purpose", at the top of a chunk, not just "this part is complicated", in the middle here and there) in their code, though. :-) Anecdata: As somebody who did actual paid work in an interpreted / dynamic language in the late 80s during and just after college, I seem to see people who have only been through the C ... Java regime struggling with more "modern" (? alternate, anyway) dynamic / functional scripting type languages. It's just not something they are familiar with (intuitive = familiar). Not that CSU did a great job teaching FP in the 80s, but we at least got to play with original flavor Lisp a few times...
somethingsimple 10y ago
I understand what you're saying but it's not the case in my specific situation. We're all developers within the same field of expertise and know what we're working with. Some of the code does require clever solutions, but we try to make it as understandable as possible and document the obscure things. This guy however would just disregard all that, implement clever but convoluted solutions to problems and all he would offer as an explanation was "trust me guys, this is how it's done." And that would be all.

by tensor 10y ago

Roboprog 10y ago

Agreed. Background / culture makes a big difference on how well devs can understand each other's code. I still wish more of my teammates (past & present) wrote more comments (as in "statement of purpose", at the top of a chunk, not just "this part is complicated", in the middle here and there) in their code, though. :-) Anecdata: As somebody who did actual paid work in an interpreted / dynamic language in the late 80s during and just after college, I seem to see people who have only been through the C ... Java regime struggling with more "modern" (? alternate, anyway) dynamic / functional scripting type languages. It's just not something they are familiar with (intuitive = familiar). Not that CSU did a great job teaching FP in the 80s, but we at least got to play with original flavor Lisp a few times...

somethingsimple 10y ago

I understand what you're saying but it's not the case in my specific situation. We're all developers within the same field of expertise and know what we're working with. Some of the code does require clever solutions, but we try to make it as understandable as possible and document the obscure things. This guy however would just disregard all that, implement clever but convoluted solutions to problems and all he would offer as an explanation was "trust me guys, this is how it's done." And that would be all.