Custom software development

You receive a new task to start a brand new project.

Your eyes light up. You're epic software developer.  And you finally have the opportunity to use the perfect dev stack you've always wanted - you decide to use every new shiny framework, library etc....

Of course there is no better preexisting battle tested framework/system. You neeeeeed to build everything yourself.

Who needs already successful cms'es with extensible dashboards? Are you nuts?

Django cms? LARAVEL + Nova? Typo3? Joomla? OctoberCms? It's all a joke!

You see, all these giants are just way too generic. Using well written ORMs to retrieve data? Are you crazy?

We need GraphQl to get custom data types for specific needs. We want backend to be more flexible by overloading it with fancy woodoo abstractions. Writing bindings for our favorite Postgres and MySql databases is a joy!

On a FE side, the custom React front-end will contain all the best new graphql Apollo version! And queries. And you only need to update all of it every month! The configurability is the key! And it will not make your FE bundle size too big! That's Reacts job!

Ooooh all the abstraction levels! So helpful and beautiful. Global React context for main user data, specific contexts for themes. Maaaan it is great being a software dev!

But in reality, it's all wrong.

I have to admit. In the last 5 years attempting to write dashboards and configuration managers I started to understand that single page applications are not worth the hype anymore.

In fact it is so common to refresh the page when something goes wrong. I feel that (re)loading entire page without any animations is convenient. Actually you don't need to manage complicated state change anymore! You always have newest BE state representation on FE ... that's it.

As for dynamic UI components. Most of the times simple inputs are all you need. I am not against css libraries, but I tend to be more against overcomplicated javascript heavy state handlers for these ui components.

There's a balance, and I feel like we don't strive for a simple solution most of the time.

As an example of a better system(e.g. ui form creators, campaign editors, product list management) let's look at Django framework. Most of data management is done in the admin, where you expose your models in simple forms. Don't like existing inputs? Create a widget for a specific model field. E.g. Json editor with a jsonSchema validation. Don't like the styling? Adjust some well documented css for your admin pages.

It may seem stupid, but yeah ... it's custom admin pages that take most of the time in any project. Why not use a behemoth with a well established community and follow some rules? It saves so much time and there's less arguments about naming conventions or file structures. Most of that is handled by community best practices within Django ecosystem (insert other cool project).

It is an important choice to DUMB down your app and make it more usable with less frustration vectors.

Dynamic Ui using React or Angular? Or maybe all you need is a simple html template? There is ways to avoid complicated UIs.

Database? Well... I am sure non of projects I participated in in the last 5 years benefited from Postgress or  Mysql as we never reached many users.

Yep. A sad fact, many times the client comes up with a failed concept and outsource companies are happy to help them waste lots of money by managing huge DBs for little cause.

So sqlite would really be suited for 100% of projects I worked on. Maybe it is dumb for me to think that way. But have you seen Turso Db? Check it out.

Anyway, I feel like the 'not created by me syndrome' is to blame for the 3x code size and people switching jobs so frequently.

For sure, if you look at any projects code you will see sections where different people used work to do their personal project investigations. And they pollute everything with hyped up approaches where it's impossible for colleagues to make any sense about what's going on.

And then they leave! Leave to avoid consequences.

Use the behemoth!

Enough rants. Cheers.

From typed to scripting languages

My developer path over the years.

My first job was in C/C++. A year long journey. Failing miserably at everything and being humbled everyday. Toxicity was never an issue but the feeling of pressure was introduced in a healthy way.

During that and around that time I heavily learned some Open GL to try and become a game developer. 

It was during that time when I discovered the first scripting language - Lua. It felt like magic and there was no javascript equivalent integration inside apps at the time (2008). I learned how to interact with it in C++ using provided stack interface.

The first configuration methodology I learned and had to abandon just to start the next paying job.

It required iOs development in Objective-c, which I learned on company premises in about two weeks. Although it was a weird one, it introduced me to how garbage collected languages really work (at least autorelease concept). It expanded my horizons a bit but...

The client decided that since I am able to pick up languages on demand, so I also had to learn some Java for Android. 

Was I abused in that regard? Maybe. Did it open the possibilities for me? YES!

You see, when the skills you have make you unique, you get a level of respect and viewed more pressious for the company. That's when the better money appears. When does it appear? In my case after 6 years of grinding and not really progressing as a specialist. A quick to write and rewrite an app in another language programmer is not worth crap. Here is why.

You learn to adapt to something existing more rather than create some domain logic from scratch. I was really surprised that at the age of 28 and 8 years of language hopping for work would render me worthless at thinking of a project structure on my own.

At that time I had to switch to Javascript project too. This is when I encountered my first PR checks and realized my code was trash... always. And I was lucky the new team was willing to explain and tolerate a lot.

In short it was another humbling experience of being directed on how to write extra simple functional code and most importantly how to communicate my concerns better.

That was the mentor guidance I needed which never happened before. And by people younger than me.

My own desire to tweak things and learn new stuff was not beneficial as it resulted in me not caring about team members and my future self much. 

Reading unprofessional code I made was always a nightmare and I wish it wasn't a case still. But at least now my code is good and simple enough to be refactored and repurposed fast, unlocks fast prototyping for my current employer.

That being said, with constant flashy tech emerging on a horizon it is tempting to switch languages like crazy and dive into their philosophy for no reason only to end thirst for new shiny things.

Trying out Rust, Go, python etc was fun. But I am back at creating small games in typescript for my self. Improving slowly, structuring, applying practices, thinking if it would be a pain for someone else to contribute, and playing with code without even a dream of releasing anything. Which programming is all about I guess, pure unconditional love.

The choice of TypeScript might seem odd, but it is something I use for work everyday. And it is one of the most portable languages ever. Although it's type system is full of lies I can attempt writing something type safe. As for being slow for games...

I am developing my game on my own. So I don't plan on releasing 3d AAA titles. It's all 2d for me and very simple, so this slowness is fast enough to enjoy whatever I might create for a browser.

Soooo Not doing homework for someone else (another company) anymore in my free time. Only what I find interesting.

For that reason also I started a YouTube channel https://youtube.com/@alexandersemionov5790?feature=share8

Here I am trying to write game related tech like AI decision strategies and my own scripting language :) sharing ideas and failures I encounter. Even the boring stuff for you is and will be a part of unraveling the vision I have or might have in the future.

That's it.

I hope my mumbling was at least somehow interesting and I was able to share my passion for tech somehow.