I’ve said this before only to hear “we don’t have time to set that up and agree on a common style” and “that’s team B’s responsibility since we’re contributing to their code base.”
Guess what kind of issue we kept wasting time on?
There are a couple of takeaways here. I think the main one is acknowledging that many technical problems are deeply human problems and the existence of a technical solution doesn’t mean we shouldn’t apply the human solution as well.
Common criticisms here would be that these endeavors stifle creativity and show the adoption of modern solutions. That said, I find conducting “code archeology” to figure out the idiomatic way of doing something in an old project very rewarding. Because computer programs exist in people’s mind’s, doing that with the support of original developers or subject matter experts is some of the most effective knowledge transfer I’ve ever witnessed.
That makes sense. I’m also involved in localization efforts. In niche cases, it’s paid off to work with the clients directly on that. You get you a good balance between correctness and day-to-day usefulness.
Since ladder is mostly diagram-based it almost doesn’t need to be localized and isn’t jarring when you use non-English variable and function names with English keywords.
Industrial controls equipment made by German companies can be programmed in English or German. You can also switch languages (German/English) at any time and the IDE switches over all the keywords.
There’s a lot to talk about from this point alone, but I’ll be brief: having gone through university courses on processor design and cutting my teeth on fighting people for a single bit in memory, I’m probably a lot more comfortable with that minutia than most; having written my first few lines of C in 10 years to demo a basic memory safety bug just an hour ago, you’re way way ahead of me.
There are different ways to learn and gain experience and each path will train us in different skills. Then we build teams around that diversity.
I’ve said this before only to hear “we don’t have time to set that up and agree on a common style” and “that’s team B’s responsibility since we’re contributing to their code base.” Guess what kind of issue we kept wasting time on?
There are a couple of takeaways here. I think the main one is acknowledging that many technical problems are deeply human problems and the existence of a technical solution doesn’t mean we shouldn’t apply the human solution as well.