I love messing around with technology. It’s quite a lot of fun if I’m honest and mostly I find that it teaches me much more about when to use certain technologies than either books (back in the 90s) or websites or people ever did.
The principle is simple. Actually doing something means you make mistakes and you learn from it.
I’ve carried this through right from the very first person who taught me to program (a guy called Mark Summerfield if anyone is interested — thanks Mark — I am no longer in touch with him) who literally sat me in front of a computer and said (something like) “Oh, you could do this in perl. Why not have a go?”.
Since then, I’ve never been afraid to have a go. It’s a releasing moment when you realise that your boss has an expectation that you’ve got to learn for yourself.
Frameworks and Abstractions
Over the years, I’ve seen many many different frameworks rise up (and many fall again) to make technology “easier”.
Frameworks often provide shortcuts for what you have to do.
Those shortcuts are often really useful so long as what you need to do is actually do something that the framework shortcuts for you.
There have also been many libraries/modules that provide abstractions away from code for you. These too are useful, if you need to simplify your coding because it’s too complicated.
The thing is, these kind of things are there for a purpose.
They are there to help you do things more easily.
They were not created as a way to keep people in line.
We’ve forgotten about the “Why?”
Too often I’m now seeing developers coming through the ranks who are specialist framework/abstraction programmers.
These people are often great at understanding the abstraction, and knowing what to do, but not always great at knowing “Why?”.
This has been particularly interesting given the rise of Serverless (Function as a Service) as a paradigm.
The first step for some people into Serverless appears to be this question:
“What framework should I use?”
Which is the wrong question entirely.
Why? Because frameworks are built for servers.
The thing is that frameworks appear to be great at doing certain things, around consistency of code and providing an easy way to share information around.
But the FaaS approach means that you have a lot less code coupled together (coupling can easily occur elsewhere, either in the data, or in the events) which means you can actually create two wildly different functions, and still have them be maintainable.
You can actually have two different languages living side by side without any inconsistency in approach (not necessarily the best idea, but it isn’t inherently wrong).
Because developers can easily understand and maintain single stateless functions far more easily than a framework based and coupled technology based upon a framework.
And maybe we should trust them more to be able to pick something up without a framework.
So stop using frameworks/abstractions?
Please hear me: I’m not telling you to stop using all frameworks and abstractions.
I’m just telling you to understand why you use them.
Because if you understand what a framework or abstraction does, then you can justify it’s inclusion (or exclusion) much more easily.
And what we’ve actually got used to is monolithic application building purely because we’ve forgotten to ask “Why?”
Be a better programmer and ask “Why?”
Because bad programmers use tools without understanding them.
Good users use tools only when they are needed.
Knowing when to use something (and not just how to use it) is the mark of a really good programmer.