That’s a cool team setup! As a fellow computational scientist without much formal CS/SwEng background, do you mind sharing any insights you’ve found valuable so far?
One thing is that the members of the group all have different levels of interest in programming, ranging from None to Expert, even if we're not software developers. Just getting everybody to use Git has been beneficial.
It's OK to start out with dirty code. Within a tight team, it's OK to make breaking changes if you warn people and help them fix their stuff. We have just begun to adopt a discipline where nothing leaves our group if it's not in decent shape, and this is going to include testing. In fact, I just took an online course on unit testing, and have applied it to a small library for the first time.
You can see that we're really starting at the ground floor.
At the present time we don't expect our code to be directly incorporated into the production code base, and in fact we use a different language. We're in an experimental group, so we're interacting with physical equipment, and our software guy has asked us to start including simulators so he can work on stuff from home. This is good discipline anyway because it lets us run our unit tests without all of the hardware connected.
I've noticed that the developers love layers of complexity and abstractions. Us normies, not so much. Keep things simple if possible. I've been moving to a more functional style, not due to thread safety but just the ages-old warning against using global variables. A big unwieldy parameter list is preferable to fetching parameters from globals.
We comment our code. I'm skeptical that comment-free code documents itself. At the very least. Scientists tend to be OK at explaining themselves in text, but doing so in code involves a learning curve.
I'll add one more thing while I think of it. You might be a good "lone wolf" programmer, but not good at working on collaborative software projects. Those projects are "big" because of team size, but also the expected lifespan of the code.
I've been asking for some mentoring on how to manage a shared project, where more than one person is modifying it. For instance, learning how to handle things like pull requests and merges, rather than just using git as a backup drive. I'm still at the front end of the learning curve on that.
I already know that there's a tradeoff, just from being adjacent to a real software team: Software product development is painful to watch because it seems so slow and bureaucratic. And OMG the meetings on top of meetings. But the devs have to strike a balance between reacting quickly to changing needs, and maintaining their sanity over lengthy project lifespans.
The devs think what we're doing is painful to watch too. ;-)
