(this is part 4 of the Algo-Trading Journey series)
Frameworks are like drugs that give you immense pleasure the first month, only to suffer for years to come.
Clean Code & Options
Options are one of the most traded asset classes, and they aren't even a "real thing".
They're a derivative... think of them as more like insurance.
So why do people buy options?
Because they want... options.
The same is true with your project or code. You want to have the ability (option) to change it and extend it (easily).
You want it to be clean and decoupled.
But what is the first thing people usually do?
Before writing a single line of code?
They couple it with a bunch of frameworks that tightly tie your code to them.
And then... there is no escape.
Productivity Myth
Yes, but what about all the extra productivity?
Well, let's analyze it...
First of all, frameworks want to be popular. This means they want to have a very wide appeal.
Nothing wrong with that, except a wide appeal means a wide variety of features.
Features you don't really need. Plus, it's a nightmare to add the ones you do need, but frameworks don't have.
So you spend 10% of your time to get 90% of the functionality.
And you're happy... no denying that.
Then, you spend 90% of the time setting up the other 9%.
(the last 1% never gets done)
But that's not all...
You spend another 90% of the time to make additional "10%" changes.
And another 90%, and another, and another...
And THAT is your productivity.
You're exchanging a month of euphoria for a lifetime of pain.
Security
Let's be honest... there is very little interest in hacking software that only 3 people use.
But the more popular the software, the bigger the target on its back.
Obviously, the best frameworks are the popular ones.
So when an exploit happens, you feel bad... it's even worse when this exploit uses part of the code in this framework that you don't even use.
(remember those extra unnecessary features)
Now, that's a proper slap in the face.
Software is a business!
I remember a time when frontend development only required one small library, and you were good to go.
(this was jQuery, and most of its functionality is now part of JavaScript ES6)
I also remember working on a fairly complex web app where I was able to be productive from day 1 (maybe 2) as a junior developer with barely any experience.
Try to do this today with modern React, Vue, Angular (or npm, webpack, babel, or whatever the newest thing is).
And speaking of Angular... what do you think about the apps written with the v.1. of this framework? Where can you even find people who are familiar with it?
Short answer - you can't.
I bet the owners of those apps are not very happy people today.
And what about the jQuery one I mentioned earlier?
I just went and checked (because this was 10 years ago), and the app/website still runs perfectly.
And the owners can still find FE developers who know almost nothing and still get good productivity out of them.
Now, that's a good business!
Frameworks Hate Junior Developers
If you're wondering why there are no jobs for juniors - part of the reason is that you need an insane amount of knowledge before you can do anything.
Basically, Mids are the new Juniors.
(I'm speaking mostly about the frontend)
Finance Game
Now, let's leave the easy world of web development, where things are somewhat predictable.
(no matter what, people will want to see pictures, text, and buttons)
And let's enter the world of financial modeling and algo-trading bot building.
When you start a project:
- you have no idea what the requirements will be
- or where your research will lead you
- and what unforeseen routes will you have to take
Your code needs to (easily) withstand all of it.
You need to fully own it and control it.
There is no room for a 1% compromise with the frameworks.
1% per day is the difference between losing all your money and becoming a billionaire.
Your (frameworks) cannot (and must not) stand in your way.
Build vs. Change Speed
I invite you to see the world with different eyes.
People always focus on "how quick can I build something?".
Instead of "how quickly can I change something?".
Because remember:
You will build your software only once, but you will keep changing it forever.
So, focus on optimizing the "change speed" instead of the build speed.
What's Next?
I plan to post my progress here on dev.to because I find it fun... and I enjoy it.
If you want to join me on this journey, then I suggest you:
- follow my profile for more updates
- bookmark this article for future reference
- and like this post, so more people can see it
Now let's go and conquer the market :)
Will
P.S. here are some cool resources:
1. Best Programming Language For Finance
2. (FREE) AI For Finance Tutorial
3. Starter Code For Bot Building
Top comments (0)