In some projects I always come across the following question, which is asked in the same way or differently:

How often do you meet developers who deal with your languages, architectures and frameworks?

After asking some questions these points come up:

• Developers copy & paste something together until it just works.
• Making changes or even putting parts into another context is not possible.
• No thought was given to language-/framework-properties.

This leads to a situation in the projects where it becomes difficult to find your way around and work "properly" because side effects are possible and cannot be estimated 🕳️

For me, this is the question behind it:

What are ways to convey how to do it right/better and to arouse the interest and enthusiasm of the team members.

To be quite frank, I'm familiar with these situations and sometimes I'm doing it by myself 😞🤦‍♂️ This means that there're situations where a certain "pressure" arises to find a quick solution. So that I fall back on an answer from Stack-Overflow e.g. without having to follow it up afterwards. By this, I mean that I don't always sit down afterwards and look at the solution in detail to…

• learn how it works and
• to grow on it, to do it better from now on.

If this is repeated often enough, it leads to an unhealthy "culture" in the team or even in the company and has long-term economic consequences (e.g. the effort to implement new features increases, maintenance and updates becomes difficult, even impossible).

Can be counteracted this?

My answer is: Yes, it can! I would go even further and emphasize that it have to do so starting immediately.

How can be counteracted this?

• Start with yourself 🤳: Start - from now on - doing it differently and better yourself.
• Pair/Mob-Programming 👨‍👩‍👧‍👦: It's incredibly motivating to work on features or bugfixes together with someone else. Everyone involved learns and knowledge is passed on. In my opinion, it should be taken care that partners fit together humanly and have different levels of knowledge also. This means that everyone should have different experiences; be it in terms of language, technology, frameworks, code history or other areas of a project.
• Pull Request 🔄: If Pull Request (PRs) are done with defined rules or even a ductus, then this can work "miracles". If PR's are reviewed in a constructive, friendly and benevolent manner, then this contributes to knowledge transfer and transparency. PR's should not be seen as an evaluation of the work. Rather, they should serve to push forward jointly defined guidelines and to recognize where things are repeatedly going in an unhealthy direction. It's therefore crucial that reviewers are "carefully selected" and that reviews are seen as important (e.g. there must be time for them). PR's have to be seen as a save-place where things are going in a good direction. By identifying what is missing or that something does not correspond to what was agreed upon. PR's are bidirectional.
• Lightning Talks/Demos 📽️: Besides demos, in which the newest features are presented, there should be regular lightning talks in which everyone introduces to others and shows what new architectures or language-/framework-properties are available (in short and on/with code). Or what is often noticed (e.g. through the reviews) and should be done differently. At the end of the talk, the team should then commit to it and incorporate what they have learned into the current development. Just to make it clear: It's not about a big presentation, more consciously about something small, concise and crisp. Quasi presentations from developers for developers.
• The pathfinder rule 📐: Clean code can be used in general and often it helps to apply only this one rule. So, leave the part of the code you're working on better than you found it. Means, that while you're working on a feature or bugfix, clean up at the same time. Refactor the code, update the code around it to the "latest" (agreed upon state) the team has committed to. I think it's important that you only refer to the part you're working on. This gives the entire project an iterative improvement and renewal. Do not change/adapt everything and it's also clear that there will be parts of code that will not be touched.

With all these points I'm not concerned with dogmatism. It's about starting with it and being the pioneer - the one who makes it better from now on - to lead by example.
To ensure that these things are taken seriously because they cause economic damage in the long term. In my experience, team members will quickly follow and critics will always be there anyway.

Do you know this from your own experience? How do you see that? What're your approaches to communicate how to make it right/better?

Cover Image by Rick Mason on Unsplash