This blogpost is altered not to reveal information before the launch of CodeGlass
I want to welcome CodeGlass to the world with the story of how it came to be.
It all started as my university graduation project ….
…
So development started on what would, in the end, grow into CodeGlass began early 2018. …
In the middle of 2018, I graduated with a working prototype ….”
And this was what CodeGlass was supposed to be; a “gimmick” …
However, it did not end up this way.
Instead of getting employed full-time, I was offered a 24 hours contract due to financial trouble at the company I worked at. I agreed with it as I could use the other hours to finish my project and release it to the public.
Looking back at that period, I notice that it has been a waste of time; the 24 hours were spread over five days, preventing me from focusing on the project and making no real progress.
I did learn better methods to improve it, but again, I did not have time to commit to those new directions.
So early 2019, I decided to take half a year of unpaid leave to focus on the project entirely and its release; I had enough saved up to support the development.
Together with two friends who were also enthusiastic about my idea, we implemented those methods and developed two different profiler prototypes.
….
We managed to fix most of them, but after a while, I was again on my own tackling this problem and extended my unpaid leave for another half year. ….
2019 was nearing its end, managed to fix all issues, and once again had a working prototype that would only need some finishing touches to bring to market.
….
So I was at a crossroad, I could either:
- Finish this and go back to work knowing that I made something fantastic, but it would probably not become more than that, and a lot of time spent on other functionality like …; or
- I could continue, picking up some side jobs to fund it and try to make . . .
I choose the latter.
At this point, I was entirely in unknown waters; I reached a point that Stack Overflow would no longer be a source of information. I had to make most of the functionality from scratch and work from blogposts of people doing deep-dives into topics, like …, and even those would never give the complete answer. They were bugged, outdated, not working anymore, and always prototypes. But it gave me ground to work on to make my functionality from scratch.
In these deep dives, I also uncovered unknown …..
At this point, I entirely shifted away from doing things client-side as then, in the future, it would never become a bottleneck.
You might wonder why it still took so long to get to this point. Well, building an application on this scale on your own without supervision for so long, you are bound to make (a lot of) mistakes, so I learned a lot, most noteworthy the following:
- Keep maintainability at the highest, choose best solutions over quick and simple and common, I still have to understand functionality I wrote one year ago.
And really, the others below are primarily methods to do so.
-
You do not talk about keeping maintain...
- Think from another developer’s perspective, as this other developer is you in a year. This means when you write code think about how another developer would use it and break it and make it that they can’t. And if you cant prevent it, make it that the developer would think twice before using it by giving it a strange name and then adding a summary there. I choose to use a default naming scheme that informs me that I am probably doing something wrong (e.g. “Proxy_{Name}()”) and hid them in proxy interfaces.
- Do not try to make a solution for a problem that you do not have yet, or create a generic solution while you only have one use case.
- Keep it simple stupid. Yes, some patterns are cool, but a simple statement is enough 99% of the time.
- Decide when performance should factor in your decision. Short answer: only bother with it if a profiler says it is your bottleneck (Code is really fast); don’t bother with it, and always take the best solution to the problem. Even I do not pull out every trick in CodeGlass;…, and yes, then I ignore rule 1.
- Keep the code clear and followable even when it is not running, so clean code, no magic code, no auto mappers, no triggers (things that change your program without being able to see what caused it).
- SOLID principles, no, not just what it means, but really what it entails and why it matters, especially in an extensive program like this, but understand that it is a principle, not a rule, that is why it is in this place.
- Always work towards MVP, and accept that sometimes that means that not everything is up to your liking; this prevents you from getting lost in the many features you want to have and support.
Well, and that is the story of how CodeGlass came to be. I hope to build this company around it and hope you will support me in this endeavor, and if it doesn’t, I still learned a lot.
That is also why if it might ever happen that there is nobody to support CodeGlass anymore, I will make its source code available to everyone, so someone else can learn from it ♥ and you do not have to worry about losing it.
….
~Tyrone Krieger, Lead Developer and founder of CodeGlass