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:

Did you ever use stack overflow, github solutions or even chatgpt to copy that piece of code that should make it all work?

Guess what happend, the next day it seems to not really work as expected in production. Now you need to change the flow of that copied code, and make it work properly. As you did not built this thing from scratch and you didn’t really take a good look at it, this could take you a tremendous amount of time to get it right.

Find a good balance in using code you haven’t seen before from other sources. Verify if it works as supposed within your solution, and find out the basics of the code you took.

As a development manager I always tell members of the team to get inspired. We are always learning new things. New ways of coding, techniques, new solutions, new approaches and even new languages. Try and get inspired by guru’s from all over the planet and don’t follow them to be cool, but occasionally try and get valuable information from their posts, articles or videos.

Another tip is “don’t do this during customer time”. I used the word inspired as you should find your own path, or find that path that suits your team. You probably want to follow 80% of your guru’s thoughts, instead of 100%. Don’t spend weeks on getting inspired. I personally look at new things once every 2 months on a rainy Saturday (In the Netherlands we have a lot of these). I spend about 2 hours every 2 months on average. It also depends a bit on what trends are out there. As a younger programmer I spend a lot more time on this, also trying out the new things on hobby projects. So the next time my boss asked me to jump in on new techniques I already had some hobby experience.

The part about new techniques, choose them wisely. In the beginning you try to jump on anything you can grab, thats natural. When getting more and more experienced you’ll find out that some new things are never going to make it. Before you know it you can almost predict that chasm. Next thing is that it is not bad to look at something completely different for a change. So as a .NET developer you could try JAVA for a change – without judgement – try to get that up and running. When doing this try to stick to the basics. You will see that you can reach the same goals using a different language. Try to keep an open mind here and try to point out the pros and cons of using that other language. Some patterns are more used in C# and others are more common in JAVA.

Did you ever wonder how your solutions are actually being used? Or even worse, did you ever built code but haven’t got the slightest idea who is using it, or what type of user is using it?

It’s not that unusual why we programmers loose scope in what needs to be built. Or better put, what’s the purpose of the application. What are we trying to solve or automate here. Very often we are missing the big picture.

You are very deep in you code to make it work. You are deciding the right patterns to use and making the code readable. Another thing concerning you is how you connect to the database tables, and where you seed your data and stuff like this. In other words, a lot of things we are doing day to day is way more deep than painting the big picture.

So how do we handle this, how can we keep our customers satisfied with the end results? The trick here is to “Show down” earlier. Most of use fix things until it fully works, then show it to the customer. Now the customer is always satisfied, right?……….

Wrong the customer is never fully satisfied. He leaves a bit of comments about the application. And you’ve been working overtime to get the job done on time. The problem now is, the software isn’t that flexible. So some comments would take far to long for you to fix. What you probably will do now is create concession software — as I always call it — . You try to point the customer towards a less time intensive road, so you can deliver your end product and finish it. And now you just delivered a piece of software which is not exactly what the customer wanted.

If you “Show down” early —  and a lot more then once or twice — you will make your piece of software a journey kind of adventure. In this journey you can use prototyping, or just simple questions to get to the right direction. Try to keep in mind that the end users can’t imagine what the solution will look like in the end. So try and visualize that for them.

Last remark. Will this lead to perfect software? Hell no… your just getting started. When the end users are using the software products in real life, they will still run into things they would like to do differently. But the main direction prevents you from starting all over again.

Back in the day I created a lot of software. From small tools to a enterprise solution or customer specific solutions that fit like a glove. It doesn’t matter what you try to create, thing can suddenly become bigger. This is where other members of the team come in and try to add things to your tool, custom software, enterprise solution or even your hobby project.

Maybe not even entirely, but you try to pin out an example for a certain problem you solved before. When these snippet examples are not that well programmed, it will lead to the same problems as discussed in part 5. The code can not be copied or reused. So try to leave things which are copyable.

Next thing is the choices you have to make for having great software that stands the test of time, is a small plan on what to do and what not to do. In the .NET world you probably know things about nuget packages or npm for angular and so on, and so on. These packages need to be sorted out carefully. Make sure you use packages that you either created yourself, code for it is available or packages are commonly used throughout the world. This prevents you from future updates breaking your software.

Last tip, when creating custom software — software specifically for one customer — try to set a standard. Not just technically but also functional. Try to build the software as if it can be used for other types of industry as well. This doesn’t mean you have to add fields and tables to the software which are never going to be used. This means if the company changes, you are flexible in changing or adding new features when you need to. I found out — the hard way — that working with reusable components works a lot better than having custom designs and approaches for each new project. I will write an article about that some other time.

These are some coaching tips to get towards a more professional result.