3 ms·

I manage a team of power plant design engineers writing complex scientific HPC software, mostly in Python (which drives Fortran 77 codes behind the scenes, amon

I manage a team of power plant design engineers writing complex scientific HPC software, mostly in Python (which drives Fortran 77 codes behind the scenes, among other things). It's been a long haul but through the years we've learned a lot of good lessons and are pretty productive at what I consider at least moderately good code. Everyone starts off by reading Clean Code and taking basic proficiency training. We know to try to make code speak for itself because, as we've all seen many times, comments lie. We've slowly learned from the software engineering community how to set up things like Jenkins for CI, black for Python code auto-formatting, Phabricator for revision control policy and code review. We're writing docs in rst with sphinx, watching coverage, and getting pylint 10/10. We're waking up to the wonders of static types. Mandatory code review has turned out to be a great way to train newbies, write better code, and make sure code is understandable to at least one other person. It's been an investment (it's slowww) but I still think it pays dividends. That's what I'd add to this advice. And I'd tone down the comments focus. Comment only when you fail to express yourself clearly in the code.

l0b0 8y ago
One thing I've found even better than code review is pair programming. At the recommendation of the tech lead we all did it for the four years at my last job, and it was a fantastic way to spread knowledge around. For thorny prpblems we'd even "mob" on them, four or five of us sitting in front of one big monitor, rotating who used the keyboard and mouse, discussing and giving high-level instructions to the driver. We collectively figured we produced features about as fast as with individuals programming (because of the intensity and avoiding many dead ends) but that the quality was far superior. Reviewing the process honestly (without getting personal) is key, though, to address inefficiencies and interpersonal issues.
- acidburnNSA 8y ago
  I believe that. We pair up on super complex things but have been promising to do more of it having heard of successes like yours.
petschge 8y ago
One things that has worked well for us, is to give a very explicit invitation to every new code user to question every bit of the code. If something is not obvious, ask why it is there and why it is the way it is. Once the new user understand the code he then adds a comment to the code or explanation in the documentation. After four new users very little code is left where the design considerations is undocumented.

l0b0 8y ago

One thing I've found even better than code review is pair programming. At the recommendation of the tech lead we all did it for the four years at my last job, and it was a fantastic way to spread knowledge around. For thorny prpblems we'd even "mob" on them, four or five of us sitting in front of one big monitor, rotating who used the keyboard and mouse, discussing and giving high-level instructions to the driver. We collectively figured we produced features about as fast as with individuals programming (because of the intensity and avoiding many dead ends) but that the quality was far superior. Reviewing the process honestly (without getting personal) is key, though, to address inefficiencies and interpersonal issues.

acidburnNSA 8y ago
I believe that. We pair up on super complex things but have been promising to do more of it having heard of successes like yours.

petschge 8y ago

One things that has worked well for us, is to give a very explicit invitation to every new code user to question every bit of the code. If something is not obvious, ask why it is there and why it is the way it is. Once the new user understand the code he then adds a comment to the code or explanation in the documentation. After four new users very little code is left where the design considerations is undocumented.