Jobs and Projects (Chaos) over Books and Courses (Order) (Part II)

This is the Part 2 of 6 of a series I started last week about The Full Stack Career:

So, Why? Why should I care? Why should I go to this humongous effort of trying to go broad-first and find environments where I have mentors and can work ecosystem-wide?

---

First, I'm skeptical about learning only from books, courses, or side projects. To me, that is almost never close to reality. You can start there, but you have to know that that is only the tip of the iceberg.

Nobody should say they know a technology or a part of the stack if they have never delivered a couple of projects for a couple of years working on that full-time.

I'm a firm believer that the best learning happens when it is border-line to chaos, as Fabio A. wisely put it in one of his most famous Youtube Rants:?

• Rant: Learning at the Edge of Chaos | Rated R (in Portuguese) .

Full transcript available?here ?(in Portuguese). English version (translated by Google Translate?here ).

Below are some of my favorite passages (translated):

• "The goal is to use these online courses as one more tool, to quickly get an introduction to get started, knowing that you'll learn just 1%. The remaining 99% you'll have to hunt down on your own as you need it. No course will give you even close to 100%."
• Most books, tutorials, and introductory courses focus on teaching the "what" instead of the "why," and it makes sense. Explaining "what" to do is much easier than explaining "why."
• If you really try to teach genuinely, enforcing principles, explaining the "whys," & creating challenging situations, most students will get frustrated and give up.
• However, if you focus more on simple examples and procedures, even the worst students will be able to go through all the steps. And the satisfaction at the end will be greater because there is a false sense of learning something when, in reality, they just followed a procedure.
• That's why I say it doesn't really matter which course you take or which book you read; deep down, they're almost all the same because they all teach in more or less the same way: in a linear, step-by-step manner, which is rarely what you'll encounter in the real world. In the real world, you have a problem to solve, and your solution will depend on how much you've practiced with various tools and techniques.
• By the way, understand a course's motivation: to keep the paying student sufficiently satisfied, happy enough to keep paying. Often the right thing to do would be to say, "I really don't think you have a knack for programming, and I suggest you looking for something else." But I have yet to see a course do this frequently because, in a heated market, I would guess that a significant portion of the class consists of people who shouldn't even be there.
• The idea is not to speak badly about courses and books but to point out that it is impossible to create a course or book that can show you what programming is like in real life.
• They would become thousands of pages long and extremely tedious to read. The structure of courses and books aims to convey knowledge in the shortest time and with the least effort possible. (order)
• Ideally, teachers would give surprise tests all the time. And classes would be adjusted and modified after these tests. And the tests wouldn't have any rote memorization but rather logical reasoning so that most answers could be deduced through induction and common sense. (chaos)
• Everyone would hate it, and here's why: it would be chaotic, disordered, and might even seem unfair. But here's the reality: the real world is chaotic, messy, and unfair, and you've never trained for it (chaos again).
• That is why it is a waste of time to ask influencers or famous people who don't know you and your skillset what they think you should study, which courses you should take, or which books you should read. It doesn't matter! None of that matters if you're unprepared to live at the edge of chaos.
• Abandon this concept that there is always an order, and embrace moments of chaos and uncertainty as good things. Everything you do without thinking, just diving into chaos, will go wrong. Everything you over-plan and blindly follow a plan without stopping to revise will also go wrong.
• You need to balance order and chaos. This means alternating between periods of order (books, courses, procedures, plans, hypotheses) and periods of chaos (randomness, experiments without a recipe, outside the comfort zone). This is what finding balance means. And it's not random.
• In each interval, you measure and criticize the original hypothesis. Modify the hypothesis and try again. Neither order nor chaos alone. Take a step back to take two steps forward. This is what I initially meant by "trial and error," a cyclical way of systematically improving one step at a time: continuous improvement or Kaizen—always balancing at the edge of chaos.

You want to deliberately put yourself in stressful & unpredictable projects with some degree of chaos (of course, always balancing the risk) because you know that is where you will thrive and learn the most. That is where you will need to find information unavailable in any book or course.

It's normal to feel overwhelmed when taking on a project.

It takes time and energy to build the mental maps that let you navigate it all, and at the start of a project, it might feel like more than you can handle.?

"That feeling of discomfort is called learning." – Polina Giralt (Senior Staff Engineer at Squarespace)

Second, most of us will reach a plateau of knowing the 80/20 -?our point of diminishing return?- of some technology or a part of a stack after 2-3 years on a job immersed in delivering real production projects with resources and time constraints.

The level of effort needed to go from knowing the first 20% of an area/activity/skill/technology (a.k.a being an effective junior) to learning the remainder 80% to become an expert is massive, especially if you are at the beginning of your career and have not mastered all the fundaments yet.

That is why I say that to be a successful professional these days, I believe that one should go broad first (master the 20% that will allow you to deliver 80% of the tasks) and go in-depth only when there is a significant need, an ample opportunity, or a strong interest in keeping developing your skills further in a particular area. You must also be exposed to chaos under different constraints and environments to master the fundamentals.

A common belief is that specialization is the key to a successful career. However, research (more below) and real-life experiences suggest that breadth, diverse backgrounds, and interdisciplinary thinking are more important.

Range — Why Generalists Triumph in a Specialized World ?that was recommended by — no one less than — Bill Gates as?one of the best books he read in 2020 offers two interesting insights:

1. Elite performers often undergo a?"sampling period"?where they engage in various activities, learning about their abilities and preferences before focusing on a specific domain. For software engineers, this means exploring different programming paradigms, languages, and tech stacks.?
2. Repetition is less important than struggle when it comes to learning and retaining information.?For software engineers, this means working on complex problems that challenge your current skill set. By facing struggles and learning from them, we develop a deeper understanding and long-term memory of core concepts, leading to a more solid foundation in the field.

Third, it is a combination of the two: If you can only learn deeply enough on real projects with real people with real constraints (chaos) and if after 2-3 years, most of us will reach our point of diminishing return learning-wise, combined with the topic I'm going to explain below of approaching your Career Capital as a Skill Stacking problem that you have to solve via Graph Traversal, it will be hard to beat the strategy of?deliberately changing jobs every 2-3 years?along with seeking some degree of chaos and order.

Please note that I'm not recommending here changing jobs every six months. I'm saying every 2-3 years. I'm also not saying change companies - you can still change your job and stay in the same company.

Even if you can't change completely the part of the stack you are working on or your primary expertise (let's say from Mobile to DevOps), switching companies will make you change some of the core parts of your job, the platforms, the product, the people and the process (more on my article here ). And those are as important as changing stack, programming language paradigm, technologies, or expertise.

Sometimes you change your companies but don't change your job. (the 4 Ps are still pretty much the same). Sometimes, you don't change companies, but you change your job. (i.e., promotion, move to a different org, start to work on a different role).

Coming up:

Career Capital and Skill Stacking as a Graph Traversal Problem

...

"Jack of All Trades, Master of None" - The Strawman argument

...

How?

How having a "t-shape" mentality/approach (or, Paint Drip, Generalizing Specialist or Full Stack…)?can help I to increase my impact (and the impact of your team/company) anywhere I go and build an incredible & antifragile career in the long-term as an IC or as a Manager, Mobile, Backend, Infra and Beyond?

1. Not Layers or End-to-End Slices, Fully Baked Cupcakes! (Ownership)

...

2. Not only Solving the Problem, Discovering the best Ecosystem-wide Solution! (Efficiency)

...

3. Not Independent Work-streams, Autonomous Individuals & Teams! (Autonomy)

...