The modern world is built on abstractions.
A good abstraction lets the user focus on doing something rather than concentrating on how they are doing it.
If you take driving for example. A car is a fantastic example of an abstraction that hasn't changed much in over 100 years.
Whether you are driving a 1919 Ford Model T or a Nissan Hyper Force (which looks like it has come straight out of cyberpunk game) they both feature a steering wheel and pedals. You don't need to know how the car works under the hood to be able to drive it.
Having this stable contract means that anyone who has learned how to drive can get in any car and be able to drive it (assuming you didn't learn to drive in an automatic).
I am no mechanic, but I am pretty sure the internals of a petrol car compared to an electric or hydrogen car are very different. For the end user however, it doesn't make much difference until it comes to refuelling.
This is the power of having good abstractions, and it is something we should all strive for when writing software. The problem is, it is incredibly difficult to do.
In order to write a good abstraction you need to predict how your application is going to change in the future.
The reason that cars are such good abstractions is that the requirements are simple.
- Must be able to change the direction of the car
- Must be able to increase the speed
- Must be able to decrease the speed
- Must have lights to see in the dark
- Must have indicators to show intentions to other drivers
Combine that with some hefty regulation for car safety, and you have a solid contract on what a car must look like that is resistant to change.
One form of abstractions are interfaces, however not all interfaces are abstractions. Mark Seemann has a great article on this, and it is something developers get wrong all the time.
We think we are creating an abstraction but often implementation details leak into the contract spoiling its usefulness.
If you want your interface to stand the test of time, it needs to be resistant to change and describe the functionality not the implementation.
The downside of abstractions
Abstractions are great for software design and ease of use, but they come with a hefty price.
A good abstraction hides from the user the implementation details and design decisions. This is great for end users, but it also makes it too easy to be ignorant of how things actually work.
Abstractions hide a lot of complicated details from users, which is good but as engineers, you aren't going to learn anything by always relying on abstractions.
Many people used to fix issues with their cars themselves, but now they are so complicated that most don't bother. It is the same for a lot of products that we use. We all know how to use a TV, but there aren't many who would be able to fix one or described how it works.
As developers, we use other people abstractions all the time in the form of frameworks and libraries. By using these libraries we can write code faster and save ourselves time on maintaining them but at the same time lose out on all the knowledge we could have gained by implementing it ourselves.
I am not advocating for not using libraries, they are essential in modern development, just take the time to learn how they work.
For those of you that work on the frontend, how many of you can build a UI with just HTML, CSS and raw JavaScript?
I know on the backend I would struggle to build anything useful in C# without using 3rd party packages such as Dapper, FluentValidation or Moq.
Can I really call myself a developer if I can't build an API with just C# and no other packages including the Microsoft ones?
I am sure it would take a very long time, but I am sure I would learn a lot in the process.
β€οΈΒ Picks of the Week
π Article - Google Brain founder says big tech is lying about AI extinction danger. This is an interesting take on the real threat of AI. AI isn't going to take over the world. The scaremongering is to force legislation to be put in place that will throttle growth in the open source space.
π Article - The costs of microservices. This is a good article explaining the costs of switching to microservices. I particularly like the clear diagrams. As I described in my piece on "Monoliths vs Microservices", it is always better to start with a monolith and then switch to microservices when the need arises.
πΎ Game - House Flipper. I pretty late to the party on this one. There are very few computer games that my wife and I both enjoy. When we were younger we used to enjoy playing Sims 2 purely for the house design aspects. We have both been enjoying House Flipper this week. It is like Sims 2 without all the annoying people aspect. I have been playing it on my Steam Deck, but they also have versions for XBOX, PS5 and Switch. House Flipper 2 is due out in 6 weeks on Steam which looks even better.
π Article - The architecture of today's LLM applications. I find generative AI fascinating, but a lot of the content is difficult to read. This is a great piece on the GitHub blog that goes into how to use AI in your applications.
π Article - Hypercritical: Appleβs Blue Ocean. I hadn't heard of the "Blue Ocean Strategy" before, it is all about making the competition irrelevant.
π οΈ Tools - OpenSign: The free & Open Source Alternative to DocuSign. It is always good to see Open Source alternatives to software that would otherwise have a monopoly. OpenSign looks like a great alternative to DocuSign.
π Article - Fixing the Volume on my Bluetooth Earbuds. I love the lengths that this person has gone to, to try and fix their headphones. That loud startup sound must have been really annoying to warrant this much effort. Still it has some great tips on how to reverse engineer tech which I found fascinating.
π Article - Why you should probably be using SQLite. I must admit I usually jump straight to using MySQL or Postgres for most of my projects. If you just need to store some structured data somewhere you can save yourself a lot of effort by just using SQLite.
π Article - How to draw beautiful software architecture diagrams. Half a developers job (at least it should be), is documenting what you have built. They say a picture is worth a thousand words and this couldn't be any more true when it comes to architecture diagrams. If yours end up looking like a spaghetti mess then give this article a read.
π¬ Quote of the Week
Efforts to deepen your focus will struggle if you don't simultaneously wean your mind from a dependence on distraction.
Much in the same way that athletes must take care of their bodies outside of their training sessions, you'll struggle to achieve the deepest levels of concentration if you spend the rest of your time fleeing the slightest hint of boredom.
From Deep Work (affiliate link) by Cal Newport.
π¨ Are you looking to level up your skills in the tech industry?
My weekly newsletter is written for engineers like you, providing you with the tools you need to excel in your career. Join here for free β
Top comments (0)