A secure home for every tinfoil-hat
:: Tinfoil-hat.net - A secure home for every tinfoil-hat
Git Projects
Posts Overview
 _____      _ _     _             _    
|  ___|   _| | |___| |_ __ _  ___| | __
| |_ | | | | | / __| __/ _` |/ __| |/ /
|  _|| |_| | | \__ \ || (_| | (__|   < 
|_|   \__,_|_|_|___/\__\__,_|\___|_|\_\
 ____                 _                                     
|  _ \  _____   _____| | ___  _ __   ___ _ __  __   _____   
| | | |/ _ \ \ / / _ \ |/ _ \| '_ \ / _ \ '__| \ \ / / __|  
| |_| |  __/\ V /  __/ | (_) | |_) |  __/ |     \ V /\__ \_ 
|____/ \___| \_/ \___|_|\___/| .__/ \___|_|      \_/ |___(_)
 _____      _ _     _             _      _   _                             
|  ___|   _| | |___| |_ __ _  ___| | __ | | | |_   _ _ __ ___   __ _ _ __  
| |_ | | | | | / __| __/ _` |/ __| |/ / | |_| | | | | '_ ` _ \ / _` | '_ \ 
|  _|| |_| | | \__ \ || (_| | (__|   <  |  _  | |_| | | | | | | (_| | | | |
|_|   \__,_|_|_|___/\__\__,_|\___|_|\_\ |_| |_|\__,_|_| |_| |_|\__,_|_| |_|

What a gem out there in the web!

First things first, I want to give credit to the author of this Article by linking the source of it’s:


Specialize, Specialize, Specialize. Want to create content for others to read? Specialize. It’s drilled into your head over and over again. Nobody looks for a book on music, but there are a lot of people who might be interested in a book about west-coast rap singers in the early 2000s. The more you specialize, the tighter your niche, the more you can work on appealing to that niche. Tighten your scope to win. Don’t boil the ocean. Focus.

Like the real-estate slogan “Location, location, location”, the mantra of specialization is drilled into our heads over and over again. Want to go to college? Great! What’s your major? Want to program computers, become a professional developer? Great! What are you an expert in? Dive deep, otherwise nobody will hire you. In fact, the best way to get a good job as a developer is to pick a few highly-technical areas and do deep-dives, getting enough experience that you become the local go-to person. If you pick the right combination of tech, you’ve written your ticket to a high-paying development job anywhere in the world.

That’s the best way to get a good job as a developer. That’s not the best way to become a good developer. Recruiters and job ads everywhere know that good developers are usually “full-stack” developers. This is a term that didn’t exist 10-15 years ago, and “full-stack developer” along with “10x developer” tends to make people quite angry now, especially developers.

A full-stack developer is a developer that knows the entire process and pieces used to develop technology. They can walk into a room with no technology in it and leave with a working solution that fits customer’s needs, from hardware to software and infrastructure. They’re generalists, which of course is the opposite of specialists.

The idea of a specializing generalist, or a generalizing specialist in technology development makes a lot of people’s heads explode. “How can you possibly know everything from the quantum world to how server clusters interact?” one person said. “If you know a little bit about everything, isn’t that the same as knowing nothing about anything important?”, “I’m only interested in one technology and it’s changing so fast I can’t keep up with it. How could anyone possibly know 40?”, or “This is just another way of saying bullshit artist, right?”

These are good comments. I think they show a misunderstanding of the full-stack concept. It’s perfectly natural since nothing in your life prepares somebody for being one. From early education to college to job seeking to job advancement, everything, every bit of common wisdom you’ve been told is specialize, specialize, specialize.

It’s not that it’s bad advice. It’s just woefully incomplete advice. You don’t want to be a full-stack developer. You want to be a full-stack human. Developer is just one part of it.

First let’s talk about what it means to be a developer, or a human for that matter.

Space Invaders
  • Approach a personal frontier
  • Observe how people and things interact at this frontier
  • Orient myself to how I view things. What’s important, what’s a given, what should I question, what are my goals, what are others doing, why are they doing it, where can I gain the most by acting
  • Decide on where I want to interact and experiment
  • Act on that decision. Loop if necessary
  • Walk away to a different frontier or go back to observing

I was a silly kid approaching electronics for really dumb reasons. But I sat on that book, I swam through as much as I could trying to fit my limited math into the algebra it was trying to teach me. I observed marking for resistors, formulas for current, and diagrams for simple circuits. I eventually decided that there was nothing I could immediately act on. There was nothing I could do except try to fit more pieces together later with what I’d learned here. One day I would be victorious! So I walked away.

A few years later, as part of a gifted program in school, they asked me what I wanted to work on. Easy! I wanted a computer!

They gave me a box of wires and electronic components from the local Radio Shack that was called a computer. You connected the wires and got different results: a light, a blinking light, a siren sound, a radio, lots of logic circuits.

Yikes! A radio! Just like when I was a little kid! So now, as I went through my little OODA learning loop with my new “computer”, I finally figured out how that communicator diagram worked. Like the little kid in the movie A Christmas Story, I realized it was just a dumb radio. There was no computer in that box, there was no communicator in that diagram I had seen years ago. Life consisted mostly of a bunch of dumb commercials for other stuff I didn’t want.

iMissile Command

Then I got my hands on a real computer, a Commodore PET, with 4k of memory, and a cassette tape drive to store programs on. It even had a programming language called BASIC! Heck, you could type both lower and upper case characters on that thing. It was amazing. A piece of Star Trek in my own high school library.

There was only one computer, though, and there were 30 or 40 of us kids who wanted our hands on it, so the nice librarian created a sign-up sheet which was based on the honor system. You wrote your name in for a certain time-slot. During that time you could use the computer. You could also bring along a friend, but no more than two people at a time could sit at the PET. It was an important piece of sophisticated gear, after all.

There was this one kid, Roland. Roland had red hair, seemed a bit of a loudmouth, and would erase our names and put his own in their place on the list. This caused many of us to hate Roland and wish he were dead. He seemed to think this was funny. He was bigger than us, so we couldn’t do much about kit. Such is kid life.

I could not kill Roland. Not that I was a violent person, but I was angry. I could do the next best thing. I could take this hot piece of smokin’ electronics and write a game where I could kill Roland on the little screen. Finally, I was using technology to make the world a better place!

So I wrote a game like Space Invaders or Missile Command, only with little Rolands that came from the sky as upper-case Rs. You moved your gun around on the bottom of the screen and fired using keys on the keyboard. When I started working on the game, you just could move left or right. The space bar fired. Later on, I developed things like smart missiles, invisible Rolands, a hyperspace button, and so on. It was a hoot.

Then something weird happened. As I started developing the game, other nerds at school wanted a copy of it. Those kids were also frustrated with Roland. They wanted payback. So I made two copies of the cassette, one for development and one for the other kids to use. As they played it, I saw what they liked and what they didn’t and adapted my game as I continued programming to make it more like they wanted. I had created my first feedback loop of awesomeness. It felt good. Really good.

This is similar to what I was given to use as a “first computer”

I was using the same old process for learning as I did earlier in my childhood. Because I had approached so many frontiers and walked away after learning from them, I had a lot of little pieces already in place in my mind. So when I needed a cool special effect for when the little Rolands blew up, I was able to go through the manual easily picking up the code. But I wanted something super cool. What I wanted, it turned out, was Machine Language.

Machine Language was the super awesome version of programming. It was programming “next to the metal” as they say today. You bypassed BASIC and instead provided binary instructions read directly by the Central Processing Unit, or CPU. What was a CPU? Well, looking at these technical diagrams for a Motorola 6502 CPU, it was a bunch of wires and electronic parts and … holy hell! It was just a super duper complicated version of that communicator diagram or those wires I connected for that dumb gifted program CPU.

I knew this stuff, or rather I knew enough of this stuff for now.

Did I dwell on how each piece was put together? I did not. Instead I grabbed the codes I needed for a loop that would make an explosion, coded it, and continued writing my game. After all, I had other nerds to pander to! And we had violence to commit against a common enemy using computers! Life was short, I walked away from 6502 diagrams and got back to mayhem.

So the process of learning was just the same as it was when I was a small child. I started noticing that there were the same pieces of learning no matter what I did.

  • Actors: people who want something from the context area I’m exploring
  • Goals: Actors have lives, motivations, and viewpoints. Based on that, they have some goals that we shared, like destroying our arch-enemy Roland
  • Context Area: where those actors had goals that created tests I was interested in created a circle called a context area. We learn inside the circle. Outside the circle life went on
  • Substrate (or Supplementals or Rules): Each context area had various rules that applied, a foundation. When I read the electronics book the substrate was math. Math defined how all the symbols interacted on the pages. With the first computer kit, the substrate was discrete electronic components. With the PET, the substrate was the CPU, BASIC language, display, keyboard, and so forth. You worked on top of the substrate in your context area to reach the common goals you had with the actors
  • Structure: The final piece was the work that you did, what you created, as you chose to act in our process loop, you created structure based on all of the other pieces. Maybe the structure you created was a new electronics diagram, or a new flashing light, or a new feature for your computer program. Structure existed to pass these tests representing goals you came up with based on the rules of the substrate you were using. Were you supposed to make the light flash when you clapped your hands using this kit? Then you adjusted the wires in the kit until it demonstrated this behavior you wanted. Did you want a cool explosion effect for this game for the other nerds? Then you coded some machine language until the screen did something everybody thought was cool-looking. Structure can be anything from wires to make a light blink to the text of a science fiction novel. It was logical, virtual structure, not physical pieces of stuff, although it could be. At its heart it was ideas and how they connected.

I never did finish the game. Instead, I keep tweaking at it, having fun in my mock violence. Everybody loved it, including, oddly-enough, Roland himself, who used to spend a lot of time blowing himself up using my game. He did this by erasing our names and taking our computer time, just like he always did.

People are weird.

Learning Stuff, Overview

In fact, I never did finish much of anything, instead flirting from one context area to another for most of my young life, interacting enough to get the general gist of how things worked, getting bored, then moving on.

People told me this was a bug. I should not be this way. Instead I should follow some pre-arranged set of rules society made for me and “do something useful” Be a doctor, be a scientist, be a businessman! You don’t really know anything until you spend a great deal of time actually doing it, otherwise you just think you know things when you really don’t.

They were both wrong and right. Some things, like math up until the second year of college calculus, or becoming a serious musician, were useful in thousands of other different areas. They were worth spending a lot of time on (in my young opinion). Leadership was like that. Some things, like learning to change the oil on a 1978 Toyota, might be really useful for a day, but not for much longer than that.

They were wrong because they were repeating what they had been taught, this canard that has been true throughout most of human history until quite recently. Specialize! Whatever you’re doing, there’s a division of labor. If you can pick a subset or a certain chunk of that work and become really good at it, you’ll be super awesome at doing that thing. All of you working together, each a deep expert in that one area, will be impossible to stop when working in unison.

They were wrong because this attitude of specializing was true for physical things in a physical world, the world humans have lived in throughout time. In virtual worlds, working with knowledge and symbols, knowledge work is infinitely divisible. I saw these two worlds separate in real time because I lived it. In 1970 when you wanted to communicate with a fake ship, you had two people and some kind of hand-held radio that looked cool. Each of those people could probably take some wires and make a radio if they needed to. In 2020 if you had two people who wanted to communicate, you could easily come up with 100 specialty areas that might be involved: electronics, signal processing, voice recognition, tcp-ip, networking, microwave towers, packet radio, edge services, CDNs, POPs, mesh protocols.

I could go on, continue to make a huge list, but no matter how big the list I made, you could pick one or two areas and come back in 60 years and have a hundred new specialty areas. Compare. If you had a factory making mops and tried to create specialty areas, you might have six or seven. You’d run out. There are only so many physical parts to a mop. But if you worked in the virtual world, no matter how many pieces you thought you had, they were all just the things you decided to use to solve that problem. You make your own pieces to solve problems, and you can make as many as you want. The number of pieces you make or use are not related at all to the problem like happens in the physical world. I could make a solution for two people talking in an hour or so. Or we could hire ten thousand people and spend the next thousand years working on it. The complexity of the work is not directly related to the goals. It’s much more related to the rules you’ve put on yourself while doing the work, the substrates you choose (or are chosen for you).

Becoming successful by becoming an expert

“I don’t want to be a good team member. I just want to be the best TypeScript programmer I can be.”

I looked at the young programmer I was teaching and didn’t know what to say. He was correct. I made a lot of money early on by picking the right platforms and technologies and then learning them in-depth. Or at least reading all the books and doing all the mental modeling work that others want to do but never get around to it.

He was wrong in the same way I was wrong. If you head down that path, you end up being the best guy possible in an arbitrary assemblage of stuff people are currently using to solve problems. You just don’t get very good at solving problems. Instead you get good at living in other people’s models, you get good at being good. You can be good, you just can’t create good.

“Most books suck. There are too many books around today,” a famous economist said last week.

He was making the same point but he thought he was talking about general mediocrity. In his mind, most books are mediocre, simple re-hashes of various simple patterns done over and over again with slightly different language.

If the is telling you to specialize in order to become popular, make money, and be successful, and we live in an age where you can specialize ad infinitum, then yes, most books suck. You can spend a career becoming the master of how the Motorola 65xx series of processors work and not know a thing about how to use them to learn and solve problems. In fact, if you specialize too much, you’ll quickly become an obstacle to others trying to learn and solve problems.

They were right

All of those well-meaning people were wrong when they tried to keep pitching specialization. Yes, it has an important role in marketing, along with certification programs. It has an important role in physical processes. But it easily and quickly becomes counter-productive in actually doing knowledge work unless you understand how learning works.

All those folks were right when they emphasized spending time actually doing and accomplishing things in these specialty areas. Until you go through the process of approaching through walking away in a certain area, with a bunch of OODA loops in-between, you don’t know what you don’t know. That is, it’s all symbolic and abstract, like that electronics book. Making goals happen teaches you on what’s important in that context area.

I quit stuff a lot. You’ll probably quit stuff a lot too. I sure hope so. But if you approach a new context area, interact with it, creating structures inside that circle to achieve your own goals and then walk away, you’re learning. Doesn’t matter whether that context area is selling books door-to-door or being the best tank you can be on your favorite MMORPG.

You have to go through the process a lot, you have to interact in a lot of circles, you have to specialize in specializing, become a true generalist, because there’s a life critical lesson in there that you’re not going to get any other way: each time you draw the circle and set up the structures on the substrate to meet your goals, the structures you set up are mostly arbitrary, even if they have the same names as structures in somebody else’s circle. Everything is bullshit, but it still works anyway.

Making a Customer Management System? Cool! Can you use your “Customer” components in somebody else’s program? Probably not. In fact, never. Is this a problem of technology? No! The “Customer” pieces you use and create to fix your problem are based on your interactions, your actors, your goals, and your substrate. The technology is just part of the substrate, and that’s a small part of the solution. Your customer won’t be my customer and my customer won’t be somebody else’s customer. But they all have the same English name “customer”

Spoken language is a game where we use the same sounds to mean all sorts of vague and ill-defined things.

The process you go through when you learn and apply that knowledge, creating those structures, gives terms meaning for purposes of that context area. I walked in to my adventure in building a Star Trek communicator with some simple, child-like, mystical idea of what a communicator was. With each interaction I had of how technology works I was left with different ideas of what the terms meant. For a long time I thought there was some universal meaning for everything, perhaps found in a dictionary. This is what they teach you in school, in books. This was the factory model applied to learning: big words are defined using smaller words, like a giant pyramid.

Different circles, different people, different goals, different structures, different substrates…all with overlapping and overloaded terms. That’s not confusing, that’s existing. Words don’t exist in a pyramid, they exist in a fuzzy web of half-meanings and kinda-works-here. What you learn by becoming a generalist is that we all create those meanings as we go along whether we realize it or not.

It doesn’t make sense, but it works, we can interact and do useful stuff. People aren’t robots. Not even close.

In fact, being a full-stack developer is an attitude, not a specialization skill. It is knowing deep in your heart that you can’t understand everything, that there isn’t a single everything to understand, that’s there’s no way you can know in every way possible every piece of what you’re doing. Then doing it anyway. It’s an attitude of competence and self-assurance bounced against a complex and unknown world full of mysteries and dangers. It’s not rational. It works anyway.

Richard Feymann famously said that if you want to truly understand something, understand it enough that you could explain it to a small child. His point wasn’t that life and the universe was simple. His point was that in order to explain a concept to a small child, you had to be able to scope out various pieces that weren’t important. You could know things in any depth you’d like, but you could only manipulate things with a vanishingly small number of axes of complexity, whether you were a child or a physicist. The human brain is a finite resource.

There is no universal child. Instead, each child comes with a limited number of life experiences and feelings. To explain something to a child is to understand where they are, then draw the people, arrows, circles, structures, and substrate for them, showing them how it all fits together.

The story of human progress isn’t a story of understanding how the blocks fit together at higher and higher resolutions. It isn’t a story of people external to our current interest and the things they believe and do. It isn’t a story of how people act with one another and with the concepts we run into every day and how we deal with it. It isn’t a story of how the substrate of our interactions continues to get more more nuanced and valuable. This last one is important, as that’s what progress is. But even the substrate changes depth depending on what circle we’ve drawn, which people are involved, and what we’re trying to do.

Each of these is important. These are all of the parts of knowing. They all come together every day in billions of combinations as we go about our daily lives.

The story of humanity’s progress is not a story of the parts, it’s a story of the story, the process. It’s the story of broken-ass people, broken in all sorts of unusual, weird, and pedestrian ways, approaching these frontiers, drawing these circles, identifying these people, choosing these substrates, and implementing these structures over and over again, sometimes walking away, sometimes hanging out for a while longer. And if we’re really, really, exceptionally good? The structures we build become part of the substrate others might use when they draw their circles, identify their people, and build their structures. We aren’t defining reality. Reality is defining us. The fact that we’re faced with reality causes us to make choices. Those choices are what we are.

Understanding that this is what we’re doing, that this dance of learning is part and parcel of the human condition, is a meta skill. It’s used everywhere, from heart surgery to carnival acts. These meta skills, just like any other, can be developed and honed over time, allowing a good student to learn anything and everything they want, based on their own life needs at the time. This is what a full-stack developer is. This is what a full stack human is. It’s a human that knows how to learn, how to skim, how to construct, and how to walk-away. Then they do that wherever it’s needed. A full-stack human doesn’t understand everything from the quantum world upwards to the structure of the universe. They know they don’t have to. What they do is interact with life, making passionate choices for their own broken-ass human reasons, learning as much as they need in any area and then moving on. This is the art of living life, it’s the art we all create whether we realize it or not. It’s what makes life worth living. It what makes us useful to other people.

Daniel B. Markham

I (the autor of the source // not the Blogowner) wrote this

GPG-Fingerprint: 266E 4882 C2A7 279E B012 C009 0D40 CFE3 4966 ·

Git Repo ·
Wiki ·
IRC ##tinfoil-hat.net ·
Mail: mail@tinfoil-hat.net ·
RSS Feed ·
Donate ·