This article won’t delve into every detail of good software development or design. Instead, it’s grounded in the belief that all principles stem from deeper considerations of proper code management. Ultimately, the best practices are those that fit you and your team’s unique approach to crafting quality code.

This article contains some tips on getting in the right direction in building your new ecosystem(s). It gives you some inspiration on getting you on the right track. As you can read in my bio, I became an experienced developer. I gained more experience by making mistakes and shortcuts than by typing the holy first-time-right code. I’ve also gained a lot of experience by seeing things fail over time.

Therefore, I would like to point out 8 things I’ve learned in the past and wished I knew as a less experienced developer:

In my early twenties, I accomplished a great deal independently. I developed websites, web applications, tools, and even entire systems by myself. There were few problems I couldn’t solve. If you’re currently in your early career, you might relate to this sentiment. Others seemed to only hinder my progress.

This resulted in an abundance of code for me to manage solo. However, that was never a problem. I excel at juggling multiple tasks simultaneously. Rest assured, I’ve got it under control.

Suddenly, you realize you’ve been riding high on a wave of confidence, churning out applications that customers adore. But oh, the plot thickens! Just as you fancy yourself a coding wizard, the tower of code begins to wobble. Delving deeper into the arcane arts of proper programming, it dawns on you that maybe, just maybe, you’ve taken a few coding detours. Attempting repairs feels like deciphering ancient hieroglyphs (Did I really write this?). Welcome to the Valley of Despair, where not even the bravest souls dare to scrap it all and start  anew, though the thought does cross your mind.

Back in the day, collaboration was the spell I neglected in my grimoire. Now, as a seasoned sorcerer of software, I see the power of peer review and crafting code that even mere mortals can manage. Had I embraced this collaborative conjuring sooner, perhaps my code wouldn’t have needed as many revamps, not just for new tricks but for the old ones too.

Joining forces in the realm of code not only fortifies your digital creations but also weaves a stronger bond within the coven of coders. Remember, the true challenge of coding is not just casting spells for yourself but leaving behind enchantments that the whole team can wield. This collaborative craft scales heights far beyond the solitary spellcaster. So, invest the time to brew that potent, legible potion of code.

This topic is all about having logic in one place. I think this is probably the most argued thing in software development. I know what to code, but where should I put it? You can read a lot of this when you google the DRY principle. Don’t Repeat Yourself. As a software developer, you would like to do things once, and only once.

This principle can be the counterpart of creating readable code, so you have to be very careful in doing this. And now I’m not saying its bad practice, not at all. Just make sure you reflect this with other developers, if they still understand what’s going on in the code.

Having code in one place also keep in mind having data access to a table or dataset in one place. This will prevent writing to the same table from different parts of the system and makes sure the next developer is confident in changing the code if needed. We break up backend (API) services and make sure it is only writing to it’s own schema, when a single DB approach is being used.

A lot of things we create is to automate processes for our customers. Making things easy to use and having data input with the least possible effort. Even replacing repetitive tasks with fully automated solutions. Good work guys.

But a developer on average often forgets that repetittive tasks are also hidden in the development process itself. Typing almost the same code over and over again. Refactoring takes a lot of time to have the entire code-base consistent. Thats where tools come in. Now in my line of business we use a lot of HTML, C#, Razor/Blazor, SQL, javascript and some JSON. In the past I created a lot of tools in the same language as the output of the generator tools. This often lead to headaches. Therefor I decided to have a little change in that by using Python as a toolset to accomplish this. The second benefit was to learn the Python language.

But whatever you choose here. Make sure to re-think the code used for building the applications you just delivered. Maybe there is a way to automate a bit of yourself. The general idea — especially when creating an entire ecosystem — is to build the next project with less pain compared to the previous one.

As we discussed earlier in the don’t go solo topic, try and do everything together whenever you can. This also means that all written code by the team is also your responsibility. As you are part of the team, you should be able to fix it, same as everyone on the team. (I know there are different disciplines sometimes).

Again you don’t have to do take this part on your own shoulders, this is also a team effort. When someone gets stuck, help each other out. Learn together about common challenges ahead. Another thing I see often is that people point out towards others, this never made the code work all off a sudden. So this is useless. On the other side don’t wait to long in asking for help, we are in this together.

Follow us to get acces to part 2 where we will address the other 4 topics mentioned earlier on this page.