This post is one big thought that I’ve been struggling for quite some time to put into words.
It’s a trait seen in some distinct engineers. A pattern of behaviour that makes a huge difference in one’s work. Even seems quite difficult to put in a typical thought process to repeat and reproduce.
I’m talking about Computer Engineers who have deep interest, curiosity, and even passion for their craft, to the degree that they develop an intuition for it.
Intuition
Noun— The ability to understand something immediately, without the need for conscious reasoning
We all have varying “levels” of intuition (in life) that we rely on and experience in daily struggles. It’s not the topic of this post to discuss its link to instinct, or subconscious; interesting as it is, I’m here to (barely) cover its effects and development factors in our craft.
You’ve seen it
If you took a look at the dictionary definition highlighted above, and reflected it upon a workmate, a schoolmate, a developer on a youtube video, or even yourself, I think there’s a good chance you know what I’m talking about.
Facing a problem outside your domain, with close-to-zero familiarity with a platform, and non-existent experience in the tool/ framework/ language. And yet you face no hustle in probing for the right spot to make the whole issue go away. If you’re feeling a bit dramatic today, you can say “it was a revelation!”
How did this happen? How can one develop this intuition? If it’s something that’s not directly controlled by active cerebral reasoning, then why do most of us lack it?
Those who are gifted, and those who acquire their own gifts
I’m not sure if one can measure intuition or talk with certainty about its nature. But it’s intuitive that some people are more intuitive compared to others. And I know that intuition can be developed and acquired.
One can say in a very broad sense that the more you know about something and the more experience you have with it, the more natural it becomes. And the more natural it is, the more intuitive it is. and this is quite intuitive!
So knowledge is a one lead
But knowledge is not a specified, pre-determined path that one can follow. When it comes to Computer Engineering (and pretty much all highly-cognitive crafts) it’s even more broad and branchy for one to easily get lost in without ever making it to the other side.
I’ve been in this field for more than a decade, and I’ve had a different experience from pretty much everyone when it came to my “journey” in this field. I’ve always been looking for ways to introspect the (good) effects my journey had on me and my career, and how to make them somewhat transferable to others.
We have a lot of what’s never enough
Branches became their own fruitless trees.
“It’s an ever-lasting journey of learning” they say. It’s true, but we seem to interpret this as just any form of studying is equal. As long as you’re putting X Hours a day then you’re good to go. This is school talk I’m afraid.
If you’re to develop an intuition for something, you have to deeply understand it, and know what you don’t (yet) know about it.
We spend too much on our specialities to forget that all of these specialities were pretty much one single topic a few decades ago. Our specialities became our own new fields—branches became their own fruitless trees.
Symptoms
Self-imprisonment
Some engineers look at it as if you’ve hired a carpenter to change a light bulb.
Over-relying on one’s domain or specialty makes them dependent on it to solve (or not) any problem they’re presented with. Some people even shrug it off immediately, without it tickling any of their curiosity antennas.
Some engineers look at it as if you’ve hired a carpenter to change a light bulb. And even in that case, assuming a carpenter couldn’t help you with this is just because it’s the safest bet. But we made it a general rule, forgetting that a carpenter (as much as any other human being) is also capable of changing a light bulb if needed.
However, imagine asking a lumberjack to rid you off a dead pine tree and he tells you he has been cutting only maple for 20 years and there’s no way he would be able to do pine. This is the problem of most of our lumberjacks engineers.
Language barrier
While it should be similar to a surgeon explaining a C-Section to an oncologist.
Not a programming language barrier, even though it’s an obvious symptom. I’m using ’language’ here as a metaphor; Many engineers seem to find trouble communicating with other engineers that work in different domains and fields.
It’s sometimes as painful as watching a surgeon explaining a C-Section to a football player. While it should be similar to a surgeon explaining a C-Section to an oncologist.
Oversight Deterioration
Everything becomes a heavily detail-oriented thought and discussion. Nothing is generalised or abstracted. Every problem is a pressing issue that must be handled before moving on to the next one.
Knowledge out of context
Chances are you have seen someone confusing web sockets with sockets. Or someone thinking dynamic linking is a concept exclusive only to iOS.
Almost all of the domains and specialities are nothing but opinionated implementations of classic computer standards, protocols, concepts, and programs. Only we did forget this or were never aware of it in the first place.
Does it ever go bright in this post?
Symptoms are plenty, and I think at this point we’re quite aware of our issues. We just don’t know how exactly to fix them. And I believe it’s not a success recipe for everyone.
Instead, I’ll do what I do best, list my observations of the traits of people who have this intuition, and don’t suffer from almost any of the aforementioned symptoms.
Computer Foundation
You wanna work computers, you gotta learn computers
A Good engineer knows the roots of all of his craft. You wanna work computers, you gotta learn computers.
Easier said than done. Many engineers out there have no idea how their tool, their assistant, and their product, work. Even worse: most don’t know what they don’t know.
A good engineer can root his issues deep down beneath the soil of his domain if need be.
Platform-Agnostic
Until you find a camping spot where you can plot, search and model your map.
There’s a reason we have alternatives for almost everything we use in our industry. No one is expected to know about each and every one of them, but you’re expected to find your way home when dropped in an uncharted territory.
After all, you’ve been trained to cope with and adopt differences as you go. Until you find a camping spot where you can plot, search and model your map.
So if you hear yourself complaining about a deployment on an OS or developing for a platform you haven’t worked with before it means you have no idea how any other platform you work with actually works.
Domain-Aware
Do you know how to comfortably operate within your domain of choice (Backend, ML, etc…) without a tool or a framework? To what degree? Are you using the framework to make your life easier or because you can’t build on your own?
Can you talk with other engineers in your domain that use a completely different set of frameworks and tools?
Cross-Domain
One way to root your knowledge (when it’s too late) to its original context, is by finding similar knowledge in other domains. If you’re a backend dev who thinks he is the farthest from mobile development then you have no idea what you’re building.
It’s even worse with people who think a frontend/ backend specialty is an actual domain of knowledge and expertise that can be separated from the rest of the product domains.
For some reason, working fullstack is considered a brave, and distraction-risking endeavour. As if it’s combining two massive knowledge branches that are not deeply correlated.
For some reason, a mobile developer hasn’t the slightest clue about exposing a network interface. Even with all the standards, tools, and resources that we have today.
Imagination (Abstraction)
We’d never reach the level of sophistication we have today without the brilliant imagination of the original computer engineers. Abstracting away nuances allowed us to build the seemingly impossible.
Engineers continued to abstract away all non-needed details with more human-level concepts and worked out several paradigms not to just write instructions, but also to model sophisticated concepts and make computers “understand” them.
OOP, FP? Too cool for that?
Do you know why did engineers go through the hassle of building such complicated and advanced paradigms and concepts? It’s because this is how we advance!
I’ll not tell you to learn/ use Java. I’ll not tell you FP > OOP or vice versa. But I’m telling you if you haven’t been through any of these (or other comparable languages/ paradigms) long enough you’ll have to be a genius to come up with enough intuition for abstracting your thoughts and understanding others'.
I know you can “code” with whatever language you have, I know you know a couple of principles and patterns that guide your way. But if you’re going to continue your way as a user, you’ll only go this far.
If you don’t have enough imagination. Go to the imaginary playground and exercise. Even if it’s full of Interfaces, Beans, Factories, Decorators, Visitors, and Monads. Someday you’ll have your own imaginary concepts to help fight away the evil imaginary Beans.
The Seeker Mindset
Sometimes not following Mufasa’s advice can be good for your growth.
This one can sting a bit, you can’t acquire knowledge by just being a receiver. If you’re not seeking it, and if you’re not curious enough, you will only walk your first step. Always unprepared, always challenged, always surprised, always overwhelmed, always facing a learning curve.
But if instead of being passive, you proactively seek the unknown. Facing a new problem will be basically continuing a thread you once started. Sometimes not following Mufasa’s advice can be good for your growth.
Context-Free
At this point, when I mention Context-Switching, it’s obviously a derivative of applying everything above; you’ll no longer need context-switching because you’re no longer attached to one specific context.
You only have tiny contexts on you to operate on a current problem, but generally, you have a pool of contexts ready for dispatch whenever needed. And the best part is, your intuition will be handling the switching for you.