As 2024 begins and 2023 sheds it's calendar presence like the dust settling on a dirt road. I wonder what will happen to the tech industry as it reaches a level of layoffs not disimilar to the early 2000s.
I've worked in the industry for 15 years, for about 10 different companies. This has been very educational and also very inspiring in certain ways. My takeaway is simple, the most succesful companies built something of their own as the cornerstone of their product.
Lets take a step back and think about why I think this matters, but lets take a big step, a side step.
How do computer count?
I mean with on and off switches how do you do the amaizng things computers do. Let's start with counting.
This is the numbers one through four in a computer.
00000001 is the number one
00000010 is the number two
00000011 is the number three
00000100 is the number four
What? the number 100 is only 4? What sorcery is this. And how can such a dumb pattern lead to so much magic.
The answer lies in the compasable nature of positional values. But more importantly the important part is that this is how a *computer* thinks, not a human.
Humans think in 10s. 10, 100, 1000. But there is really no reason for this. 10 is not a more common number in the world than say 7 or 9, it's just much much more commonly refered to. Not 12 like the months in a year, or six like the size of a pack of beer, or... oh wait... 10 is how many fingers we have, oh yeah, I guess that is pretty familiar.
When computer programming became more widely practiced in the 90s something emerged called Object Oriented Programming. But without going into what that means I'd like to focus on how much of computing is essentialy repeatable patterns. How well computers repeat patterns, and how poorly computers are defined by the physical world we are all more familiar with.
The reality is that all computers do is repeat stuff. And talking about the stuff that they repeat involves the stages of a task, or states. Enter state-machines, the much hated pattern in most companies I've worked for. But what happens if programs are defined by states instead of objects is remarkable. The discussion around developing or using a program becomes focused on what it does rather than what it is.
If you talk outside of software engineers about a project, with managers and business personnel about the steps or states of a part of your product it makes a lot more sense than objects.
Consider these two statements:
"We are working on the part where the cookie is recieved and the user data gets loaded."
or
"I'm working on the session handler object."
To me the above makes way more sense to everyone.
As I think more about this the question I have is not weather engineers like to make things more human but weather engineers like to make things more certain.
State-machines are always full of edge cases that have to be thought through. Objects are always contained pieces of logic you can relate to and reason about. State-machines change and need maintenence. Objects can be extended, combined, or subclassed.
And lets think about why engineers would crave more certainty. Lets think about the mental place most engineers live all day as a background for this craving. If your a software engineer you are wrong almost all the time. Here's what I mean by that. Your day starts with you not knowing what to do. This is a harsh way of saying that you havn't figured out how to do the task in front of you.
Then when you have an idea, you will spend most of the day figuring out why it didnt work, and continues not to work, until it does. But when it does, it's no longer part of your day. It goes to a product owner, a quality assurance member of your team, or out to customers. The only time you will see it again is if it breaks and comes back for you to fix it.
This constant cynical state of working has a profound effect on software engineers that I have experienced and seen in many team-mates. As a whole, software engineers spend a lot of time talking about things to avoid or conventions to use in order to to minimize the negative experiences of broken or confusing code.
In this state of constant struggle it is understandable that there would be a draw to third party libraries that were already considred stable. That having a gaurenteed level of functionality would be sought after and desirable. The discussion now becomes less about the task at hand and more about the framerowks and libraries used that are *safer* and already functional. The objects not the states. The components not the phases of the task at hand.
If this trend continues long enough, there will be technology used in an organization that far outstrips the knowledge and capability of the team. The drive for safety has craeted a product that is designed from a frankenstein of existing free-software components that may not fit well together, may not be changable in the ways the orgranization needs. And if something goes wrong there may not be staff on hand to diagnose or address the problems.
This is the process of treating computers as if the uncertainty of the world avoidable. This is the problem with treating computers like the best things are things that are familiar. And I believe this is why the industry is struggling to keep pace with consumer demands. The desire for safety has driven us to talk far too much about what something *is* over what something *does*.
And the answer to all this pain and struggle for me is to use the creative power of the brilliant software engineers I've known to create something that works. And reason about the tasks of they system more widely within an organization. Focus on thethe framerowks, langauges, and libraries it stands on top of less.
If you take all that you know as an engineer and focus on what needs to happen as if you were not a technical person. The code will be more effective when it uses the basics of logic and hard work than the boilerplate solutions that have been popularized.
Computers are magical things and so are people. When software engineers meet computers where they are, and write code that is designed to function, the power of software is truly magical. And it's the power of authoring repeatable patterns, not human familiar ones, that has the most power.