4 ms·

That's awesome but what I don't understand is how she would be able to produce clean and readable code? To her it would seem that tabs/spacing/line lengths woul

by dvcc 11y ago

That's awesome but what I don't understand is how she would be able to produce clean and readable code? To her it would seem that tabs/spacing/line lengths wouldn't matter to her unless mentioned during code review. Interested to hear how she handled it.

wbl 11y ago
indent(1) or equivalent would solve that problem.
davismwfl 11y ago
We had to make some accommodations on how we reviewed and enforced the coding standards. In the end though they actually made it better for all of us (especially considering we had some offshore development going too). In specific, we implemented a code formatting tool (and kept updating the rules), we also had a number of check-in rules but did the rest through peer assistance and standard code reviews. In fairness, she would get most things in pretty good shape formatting wise. I think it was the reverse of reading for her. She could read documents using this machine that would blow them up massively to a few characters at a time, and she'd read across each line having to keep it all in her head. So I think since she was having to assemble the letters a few at a time and read across a page, she had the same ability to apply it to writing and formatting her code. Looking back at it now, her cognitive skills and memory had to be excellent. As a matter or practicality, we did have her team lead sit with her before she was ready for code review (at least at first), just to help make basic formatting corrections etc. This just reduced us discussing minor formatting issues that the tools missed during a code review. As time went on the amount of effort others put in to help her on formatting was pretty minor, but at the beginning it did take some extra effort. Another thing I learned working with her, she took great care in thinking through a problem before writing a single character of code. To the point that I feel she would work through things mentally way more than her peers that would do many more compile/test/code cycles. So I think that helped her too. She also had everything in black and white, no color formatting in her code windows etc. It was neat to work with her, no one questioned her ability after a little while, but there were people asking us wtf we were thinking hiring her at first. To those of us that interviewed her though, she was qualified and did better in the interview than a lot of the peers, so it was worth a shot.
not_kurt_godel 11y ago
You sound like one of those people who format code by hand instead of an in-IDE autoformatter.
- davismwfl 11y ago
  Kinda to that point. For that specific project we were mostly all in Emacs. So we had basic code formatting in Emacs and then the formatting tool took over to help make sure it was all standardized. It cut down the amount of annoying code format chatter in code reviews so we focused on the domain/code issues. Made us all more productive.
- dvcc 11y ago
  Let the IDE/editor handle most of it. But some things just end up being handled on their own despite any suggestions by the IDE.

by dvcc 11y ago

wbl 11y ago

indent(1) or equivalent would solve that problem.

davismwfl 11y ago

We had to make some accommodations on how we reviewed and enforced the coding standards. In the end though they actually made it better for all of us (especially considering we had some offshore development going too). In specific, we implemented a code formatting tool (and kept updating the rules), we also had a number of check-in rules but did the rest through peer assistance and standard code reviews. In fairness, she would get most things in pretty good shape formatting wise. I think it was the reverse of reading for her. She could read documents using this machine that would blow them up massively to a few characters at a time, and she'd read across each line having to keep it all in her head. So I think since she was having to assemble the letters a few at a time and read across a page, she had the same ability to apply it to writing and formatting her code. Looking back at it now, her cognitive skills and memory had to be excellent. As a matter or practicality, we did have her team lead sit with her before she was ready for code review (at least at first), just to help make basic formatting corrections etc. This just reduced us discussing minor formatting issues that the tools missed during a code review. As time went on the amount of effort others put in to help her on formatting was pretty minor, but at the beginning it did take some extra effort. Another thing I learned working with her, she took great care in thinking through a problem before writing a single character of code. To the point that I feel she would work through things mentally way more than her peers that would do many more compile/test/code cycles. So I think that helped her too. She also had everything in black and white, no color formatting in her code windows etc. It was neat to work with her, no one questioned her ability after a little while, but there were people asking us wtf we were thinking hiring her at first. To those of us that interviewed her though, she was qualified and did better in the interview than a lot of the peers, so it was worth a shot.

not_kurt_godel 11y ago

You sound like one of those people who format code by hand instead of an in-IDE autoformatter.

davismwfl 11y ago
Kinda to that point. For that specific project we were mostly all in Emacs. So we had basic code formatting in Emacs and then the formatting tool took over to help make sure it was all standardized. It cut down the amount of annoying code format chatter in code reviews so we focused on the domain/code issues. Made us all more productive.
dvcc 11y ago
Let the IDE/editor handle most of it. But some things just end up being handled on their own despite any suggestions by the IDE.