4 ms·

I'd add one thing to that list: be wary of genius developers. I currently work on a project where one of the most senior guys was an incredibly smart person. H

I'd add one thing to that list: be wary of genius developers. I currently work on a project where one of the most senior guys was an incredibly smart person. He wrote extremely complex parts of the code that "just work". The trouble is he's now gone from the team, and no one understands why certain things are written the way they are, and people are afraid to touch them. Despite being really smart, this person was not very good at communicating. Your typical shy and introverted little genius who does it all on his own. When asked to explain things, he would just say "trust me, it has to be this way", but wouldn't really explain why he made certain decisions or wrote the code in certain ways. So now we're in a situation where there are parts of the code we can't touch because "he said it had to be this way". Great. I call it personality-oriented engineering. A total failure. This person got to a higher position because management only looked at how smart he was and how he was able to deliver complex solutions that would impress everyone. They failed to realize how bad he was at leaving a legacy of maintainable code that can be moved forward.

Smudge 10y ago
Seconded. The most important thing for me, when writing code, is whether or not I (or someone else) will be able to read it in 6 months. The second most important thing is whether I'll be able to throw this away and replace it with something else, which perhaps counterintuitively means I need to spend more time ensuring the code I'm writing doesn't wrap tendrils of interdependencies into the rest of the codebase. An important part of that is ensuring that any major interfaces/APIs (both internal and external) are simple, predictable, and well-documented. Even following those two rules alone, you can avoid building these complex, black-box solutions that nobody is willing to touch.
cpeterso 10y ago
I think code review can help here. Even genius developers' code should be reviewed and understood by other developers. This can help reduce the bus factor and level up other team members. The genius developer will learn to "dumb down" (hopefully in a good way) their code to reduce overhead to their productivity from long code reviews with many questions.
monk_e_boy 10y ago
> genius developer Who writes unmaintainable, unreadable code? Not my definition of genius at all. I worked with one genius in my 20 year career. He was a marine biologist and knew more about computers than me. He was scary smart and all the advice I had from other people about working with him was - he thinks in steps 1, 6 and 20. You need to get him to explain how he got from 1 to 6, and then how he got from 6 to 20. Often this would take weeks to get out of him, but the though had just popped into his head (often while working on something else.) Very interesting man. One of his quirks was the he had no idea what time of day it was. We had to tell him to go home or eat his lunch, else he'd just think it was perpetually "about half nine"
ArkyBeagle 10y ago
Can't you just pull that part out into a test driver, and "treat it as a hostile object" ( a hostile witness is one who only answers yes or no questions )? If I was his manager, "it just has to be this way" wouldn't work, but obviously different strokes.
iSnow 10y ago
>there are parts of the code we can't touch because "he said it had to be this way". You know what? That just means you haven't shrugged his influence off. He's still casting that long shadow. When our local genius left, I felt lost but eventually stepped up, went through his code line by line documenting it, wrote enough tests so that I could be sure that I wouldn't introduce bugs while rewriting his code to make it readable for me. I learned quite a bit from that.
- jdbernard 10y ago
  Seconded. If this guy really wrote good stuff then this is a great learning opportunity. If you have some way to contact him even moreso. He may not be the type of person who can easily summarize or teach someone new to the codebase, but I bet if you read through it, got to know the problem and had specific questions about details of his approach, he would be more than able to discuss it with you. Often this kind of personality enjoys sharing their thoughts, they just don't enjoy spending lots of time getting someone up to speed from ground zero. But putting in the hours to grok the code might put you in a good position to have productive conversations.
- somethingsimple 10y ago
  I personally shrug it off, but I'm one of the newest guys in the team so I don't have a lot of clout to push for changes yet. Everyone else though seems to be caught into some sort of mysticism around the genius guy. Even our architect and our manager have this attitude of "we can't change this; it might look strange and we don't know why it's there, but he said that was how it had to be." It's very upsetting.
  - iSnow 10y ago
    Good for you. I didn't want to pick on you or your colleges so much, I just think your local "genius" has weaknesses like everybody, but in reality your company is at fault. They should not mystify him, they should have made sure he shares knowledge with others and brings other up to speed. And as he is gone, they should make sure the code is refactored to suit the documentation level and code style the remaining devs are used to.
sklogic 10y ago
> be wary of genius developers. Is not it a subset of "high performers"? The dirty secret of all such "genius developers" is exactly this - they all simply traded rigour and quality for a speedy spitting out of a "good enough" code. For the outsider this pace may look like magic, for someone who is left to maintain the mess it looks, well, like a mess.
rabidrat 10y ago
Yes, be wary of hiring geniuses if you have poor management. Why do we expect that someone who is fantastic at twiddling bits, to also be good at documentation? It's like saying to a Program Manager "great, you specified how it has to work, so now just take a few hours and code everything up". Or "how come you weren't coding as you went along?" The solution is to pair these 'unbalanced' developers with people who are good in other areas. Where was the technical writer who was talking with him on a near daily basis? Or the SDET who worked with him to make sure the important aspects of his design were codified into tests? You can have 10 reasonable devs spend a year getting something to work and have it be reasonably maintainable/documented/tested/etc. (If you actually even have 10 reasonable devs in the first place). Or you can have 1 'genius' do something fantastic in 6 months with minimal support and hope that your other devs can fill in the gaps. Remember, you don't go to war with the army you want--you can't say "this person would be great if only they __". You can only work with them or not work with them. If they are genuinely doing what they think is best for the company, then I recommend you figure out how to work with them. Their challenge is to figure out how to be effective in an organization that doesn't understand, and your challenge is to figure out how to make an organization that can understand.
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.

Smudge 10y ago

Seconded. The most important thing for me, when writing code, is whether or not I (or someone else) will be able to read it in 6 months. The second most important thing is whether I'll be able to throw this away and replace it with something else, which perhaps counterintuitively means I need to spend more time ensuring the code I'm writing doesn't wrap tendrils of interdependencies into the rest of the codebase. An important part of that is ensuring that any major interfaces/APIs (both internal and external) are simple, predictable, and well-documented. Even following those two rules alone, you can avoid building these complex, black-box solutions that nobody is willing to touch.

cpeterso 10y ago

I think code review can help here. Even genius developers' code should be reviewed and understood by other developers. This can help reduce the bus factor and level up other team members. The genius developer will learn to "dumb down" (hopefully in a good way) their code to reduce overhead to their productivity from long code reviews with many questions.

monk_e_boy 10y ago

> genius developer Who writes unmaintainable, unreadable code? Not my definition of genius at all. I worked with one genius in my 20 year career. He was a marine biologist and knew more about computers than me. He was scary smart and all the advice I had from other people about working with him was - he thinks in steps 1, 6 and 20. You need to get him to explain how he got from 1 to 6, and then how he got from 6 to 20. Often this would take weeks to get out of him, but the though had just popped into his head (often while working on something else.) Very interesting man. One of his quirks was the he had no idea what time of day it was. We had to tell him to go home or eat his lunch, else he'd just think it was perpetually "about half nine"

ArkyBeagle 10y ago

Can't you just pull that part out into a test driver, and "treat it as a hostile object" ( a hostile witness is one who only answers yes or no questions )? If I was his manager, "it just has to be this way" wouldn't work, but obviously different strokes.

iSnow 10y ago

>there are parts of the code we can't touch because "he said it had to be this way". You know what? That just means you haven't shrugged his influence off. He's still casting that long shadow. When our local genius left, I felt lost but eventually stepped up, went through his code line by line documenting it, wrote enough tests so that I could be sure that I wouldn't introduce bugs while rewriting his code to make it readable for me. I learned quite a bit from that.

jdbernard 10y ago
Seconded. If this guy really wrote good stuff then this is a great learning opportunity. If you have some way to contact him even moreso. He may not be the type of person who can easily summarize or teach someone new to the codebase, but I bet if you read through it, got to know the problem and had specific questions about details of his approach, he would be more than able to discuss it with you. Often this kind of personality enjoys sharing their thoughts, they just don't enjoy spending lots of time getting someone up to speed from ground zero. But putting in the hours to grok the code might put you in a good position to have productive conversations.
somethingsimple 10y ago
I personally shrug it off, but I'm one of the newest guys in the team so I don't have a lot of clout to push for changes yet. Everyone else though seems to be caught into some sort of mysticism around the genius guy. Even our architect and our manager have this attitude of "we can't change this; it might look strange and we don't know why it's there, but he said that was how it had to be." It's very upsetting.
- iSnow 10y ago
  Good for you. I didn't want to pick on you or your colleges so much, I just think your local "genius" has weaknesses like everybody, but in reality your company is at fault. They should not mystify him, they should have made sure he shares knowledge with others and brings other up to speed. And as he is gone, they should make sure the code is refactored to suit the documentation level and code style the remaining devs are used to.

sklogic 10y ago

> be wary of genius developers. Is not it a subset of "high performers"? The dirty secret of all such "genius developers" is exactly this - they all simply traded rigour and quality for a speedy spitting out of a "good enough" code. For the outsider this pace may look like magic, for someone who is left to maintain the mess it looks, well, like a mess.

rabidrat 10y ago

Yes, be wary of hiring geniuses if you have poor management. Why do we expect that someone who is fantastic at twiddling bits, to also be good at documentation? It's like saying to a Program Manager "great, you specified how it has to work, so now just take a few hours and code everything up". Or "how come you weren't coding as you went along?" The solution is to pair these 'unbalanced' developers with people who are good in other areas. Where was the technical writer who was talking with him on a near daily basis? Or the SDET who worked with him to make sure the important aspects of his design were codified into tests? You can have 10 reasonable devs spend a year getting something to work and have it be reasonably maintainable/documented/tested/etc. (If you actually even have 10 reasonable devs in the first place). Or you can have 1 'genius' do something fantastic in 6 months with minimal support and hope that your other devs can fill in the gaps. Remember, you don't go to war with the army you want--you can't say "this person would be great if only they __". You can only work with them or not work with them. If they are genuinely doing what they think is best for the company, then I recommend you figure out how to work with them. Their challenge is to figure out how to be effective in an organization that doesn't understand, and your challenge is to figure out how to make an organization that can understand.

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.