Context Generation
A spiel about overcoming fixation on best practice in learning; how tech can be made welcoming, and in extension, how to teach and learn better.
The ocean that is the collective human knowledge is endlessly vast, harrowingly deep, extending beyond the shortness that is human life… to learn something new is to plunge one’s self into the unknown; part-faith that said pearl of wisdom exists, part-belief in the self that she can, and will find it.
Sometime mid-2021 DigIO reopened its traineeship program after a period of COVID hiatus, opening a new chapter on our Sydney branch with its first cohort of trainees. Between brainstorming for ideas during and in the aftercare, I reflected about how mentorship can be done better, how tech can be made welcoming, and in extension, how to teach and learn better.
Some Assembly Required
My new mentee is, in a way, a chance for redemption. Many moons ago I attempted to get a promising young woman into tech on the basis of her meticulousness, her penchant for philosophy lending to sound judgements, and healthy dose of doubt to question every assumptions.
I did every mistake possible when it comes to mentorship, especially when it comes to not giving enough support — with my time, with proper care in seeding and propagating context — I threw courses and tutorial pages at her the way I started my software development journey, believing that she would have been be able to pick it up by herself. It achieved nothing but a lot of frustration, confusion, and self-doubt — I made the mistake of assuming that potential is independent of circumstances. As it turns out, things get done when there is enough motivation to make it happen no matter what it takes, and low-to-acceptable enough effort to achieve it — which, in this case, there was neither pressing need or want for her to take up software development1, nor enough help from my side to make it coherent for her.
The realisation came when I observed others imparting their wisdom and not having it “click” in my brain. Well-meaning, but ultimately meaningless. Things like “think of yourself as a company” when it comes to career development, “question the model” in terms of assessing too-good-to-be-true ROI deal stories, and what is now finally settling in and became one of the focus of my 2022 intentions, “think bigger” — though not strictly in the context it was given about getting and finding better deals. In software engineering, this comes in the form of “keep your code clean” or “SOLID principles” and the likes.
It took months to years until they formed another wrinkles in my brain, and only after many, many rounds of scratching around, and the good fortune from learning from the best people that it came to me that great teaching is about meeting the mentee where they are. If they can make it to the mentor’s level on their own just by listening to the distilled wisdom and best practices, there is no need for mentorship.
Principles are summaries of understanding, not what will lead to understanding in the first place; to truly understand it, one must first experience it.
The motivation part is the mentee’s problem to find a strong enough why to start keep going.
What all mentors can do is the part about making it effortless.
People fall into the trap of resource-dumping all the time: list of blogs, books to read, online courses on computer theory; everything that will provide the full and complete picture in the name of exactitude, paving the road to helplessness with the best intentions. The good intention is there: know the algorithms; know the data structures; know the design patterns. Know the building blocks well, so you can build it properly from the get-go… in theory.
Sadly this approach works against the brain’s natural built-in garbage collection mechanism. What doesn’t get used, gets lost — as was in my case. All those years spent learning about machine learning, self-driving cars, and even the four years of robotics degree were all truthfully for naught, serving little more than a very expensive virtue signalling of a technically-oriented mind, while the details died the honourable neural death.
(They do say the secret to mastery is knowing all the other ways it doesn’t work and picking one that you like the most — or as a minimum, the least painful one.)
Imagine this common, arbitrary separation of a mental model of web technologies:
Having enough context, one can zoom in and out, depending on the need for details:
But for a junior platform engineer, zooming in might look like:
Context Seeding
The problem with teaching programming is that it is not general knowledge; no context to begin building with, and so there needs to be some pre-work of context seeding.
What is context? It is the little things that make up the backdrop of certain interests: gardening, programming, cooking and so on, usually referred to as domain knowledge. It is made up of the little things that sometimes don’t make sense of their own, however once it reaches critical mass, creates a full picture of understanding.
Consider the act of growing a plant. In this case there is a baseline context where generally everyone understands that to grow something, you put a seed into the ground and water it, then it might grow into a plant. Besides the fact that everyone gets taught this in kindergarten, action → direct result. Not so with web development, or programming in general. One can write a line of program that adds 2+2, but how does it become a Google?
Imagine programming as trying to build something with toy bricks, moreover with Javascript, you’re building it with jellies cast like toy bricks.
Now imagine that right out of the door, you have the choice to customise the bricks’ shapes before even starting to build anything. After that, proceed to teaching people to customise the bricks and changing the materials first before we ever practise building houses. That is how classical computer science courses do.
Software development requires huge upfront mental costs in terms of effort before it returns any tangible benefits, making it difficult to grasp, and disheartening to tackle solo. Not impossible, mind you, but having someone show the way around is a definite boon.
Web development bootcamps, in a smart move to fill in the gap and slick marketing that detaches itself from the stigma of trade schools, takes care of this problem so that the cost to uplift people to production-ready level is not financially devastating for businesses2. Bootcamps take care of the initial incubation work, which is costly with little result (through no fault of theirs; getting from 0 to 1 is exponentially harder than getting from 1 to 10). More on this in another essay.
Generally said bootcamps gives an end-to-end overview of a specialisation, as shown by the syllabus below I pulled from Code Like a Girl. This provides the opportunity practice with full-time support, which is not a cheap thing in a developed country. The dollar amount yet to be spent on upskilling the graduates is still not zero — but since now people know roughly what to do and only needs to practice to do it better post-bootcamp, it’s viable enough for the business to spend resources on training and staying afloat.
My $29 Complete Web Development Course on Udemy does the same thing with less support. This is where the self-awareness on how much support one needs come in. My MATLAB script-hacking experience, though not directly interchangeable, shared the basic concepts — loops, data types, and so on — so I was able to pivot quickly and DIY the course in 2 weeks while day desperation-trading and arbitraging some data entry job, generating some proof of work to show potential employers.
I have done other actual from-zero context seeding in other domains since in a mix of personal interests and part of strategy to winning the long game of life. The details will be in the upcoming 0 to 1 essay, however I can quickly share my two main techniques to generate and propagate context: wormholes and grafting.
Wormholes
In the absence of a concrete starting point and meaningful comparables, likening it to the closest-resembling concept in a different domain that the mentee is well-versed in is a very potent way to grow understanding, and is one that my people guide uses a lot on me for good measure. In here, and in the accompanying essay, I attempted the same to well and truly drive my points home.
To demonstrate with a few examples:
If software development and investment portfolio management are lightyears apart, anecdotes are wormholes that connect disparate domains together, so that entities can be understood as EC2 instances, trusts as load balancers, and structuring in general is not all that different from provisioning. Franchise businesses are Docker instances, for that matter.
This way one tries to make as many parallels as to the mentee’s existing knowledge base. The goal is to copy it over so that the relational map-making is less taxing, because suddenly, the new concepts are adjacent to the current ones.
Grafted Development
It did not click to me until I was 2 years in that HTML pages and other resources are downloaded into our browsers, then our browsers themselves need to do process the files to different degrees before it can display the final result: a fully-rendered web page that handles known use cases. But it didn’t matter, because the way my work was grafted onto the work of other engineers, which made end-to-end transmission possible without a complete understanding of it all.
In upskilling people for production-ready programming, it is best to “graft” people into an existing, optimised context — say by extending a booking app that’s already up and running, or practice deploying a finished web with a ready-made infra script with some improvements, or configuring a hosted chatbot development. Shadowing is the real-life equivalent of holding exp share. This way, one can trace over the other parts of the build, exploring, building context, contributing, filling in the gaps, building a fuller understanding of this hundred-tentacled beast called web technology.
By now I hope it is obvious that what I call “grafting” simply describing the process of immersion. That which immerses, gets internalised, thus becoming habitual and effortless. This is one of the main tools in my upskilling automation toolbox; hang out with good, highly skilled people, and one will rise to the average of the group— that is to say, above average — so the hard work is minimised in the one-time conscious vetting of choosing well.
Remember, the goal is to generate as much context in the shortest time possible. Context makes people care. It makes it relevant; it makes sense, and past a critical mass it allows people to self-propel indefinitely. After context seeding, we can follow it up with some context propagation strategies as follows.
Context Propagation
Coming from a place where one can see the overall lay of the land, it is natural to assume that understanding can be taught top-down as well.
The only problem with this approach is that it doesn’t stick. Because in terms of having context, although the result is knowing that “the code we produced instructed the server, then the browser, to render finished web pages with programmed business logic that handles defined use cases, so when someone feeds the website with things — cookies, user inputs et al, it results in a reaction — showing targeted ads, site configuration using saved settings, confirmation indicators, etc.”; the way to get there is not so much about “learning to create a page, learning ins and outs of file storage, processing, and transfer protocols, learning about rendering cycles, storages, service worker and all the features of a browserAPI so that in the end, one can produce a well-designed website”. Context propagation in practice is more… agile.
What I mean by this is, even though ideally one teaches and teach good practices, good practice has the prerequisite of a large context base. In order to do that, we need to weave new ones into the existing ones, and letting it solidify into one chunk at a time. A lot like learning how to dance — you don’t expect to do full Jazz choreography from day one, you do a short sequence badly over and over until it gets good, layer another, rinse and repeat.
A good project is the one that’s just-difficult-enough. This means that a good first project, is the one that requires no prior knowledge to execute, then the second and third ones are the ones with limited, well-defined scopes, adjacent to the initial context.
All good projects are all alike in the way that it has enough pomp to see immediate progress — a lot like habit-crafting, if you will — while every bad projects is lacking in its own way. It is for this reason that creating a vanilla page is not a good first project; better having someone create a JSX product details page by copying the template from other pages and reusing built components, than an About Us page in vanilla HTML, though HTML elements are structurally the fundamental building blocks of the front-end web technologies, and React components are several abstractions away from it. For example, a front-end scope of responsibility might look like this:
Iteration 0: make a page using existing components (copy + paste coding) + integration test → ??? → live website
Iteration 1: create reusable components + unit and integration tests → ??? → live website
Iteration 2: create optimised static/server-rendered/hybrid web pages → deployment strategies and environment management → ??? → live website
Iteration 3: development workflow setup → web pages → CI/CD → networking → ??? → live website → event-based marketing workflow
Iteration 4: ??? → business strategies for quarterly objectives → presales + sales scoping for deal flow making and closing → delivery → ???
and so on and so forth… to infinity.
Solidifying a manageable amount of new concepts into a close-enough base of understanding, gluing them together, generating true understanding is the essence of having experienced; that is the work that the mentee needs to do. The job of the mentor is to come in with hairdryers and UV lights to help set the glue in faster.
The lack of context, before appreciation, is foremost a problem of recognising that:
there is a bridge
which can be used by way of crossing it
which lets us skip manually going down and up the metaphorical ravine, saving us time, energy, and other resources
in order to get to this better side that that person didn’t know about before
Often, it makes more sense for one to cross the bridge first without knowing how or why it was built or even what a bridge is. In terms of programming, it is running the CI/CD pipeline someone’s built then observing what goes on in each step; it is editing the properties of a component on the page and see what broke; it is clicking deploy without prior knowledge of orchestration. To get experience, people need to experience it. Theory is a nice reflection; practice is everything. Your mileage may vary, but at least to people who learn through insights like yours truly, doing is the highest ROI method to learn3.
Contextual appreciation comes after; the hows and whys one would build a bridge and cross it. It comes after having experienced something, a compiled result of having practiced, by diffing what one did with best practices, so it is prevalent how it can be done better next time around.
Contextual appreciation comes from having known the many other ways it could be. What the abstractions absolve us from; the bridges with which we cross over the chasms of prior crafts. The bundler that single-handedly cleans up namespace pollution. The library that optimises rendering and state-passing from the get-go. The set of scripts that create an optimised GCP tenancy.
Building Bridges from Both Ends
As I matured, as a developer and what I hope is a well-adjusted person, I’ve come to think of jargon as gravy. For the right counter-parties, they are handy shortcuts to refer to certain concepts, but over-reliance and over-use of jargon reeks of cowardice. It is an expensive mental operation for the otherwise uninitiated; good only if you want glazed eyes and non-committal quasi-agreements.
Jargons ought to be thought of as salt-bombs: full of flavour, but to be used sparingly. To overuse them is plain bad taste; no one is fooled, except for the ones who enjoy the Instagrammable aesthetics of dishes without tasting it.
In a pure meritocratic system these won’t matter, but as we see with the expectation around experienced juniors, this is not the case. Since common sense is not very common, as it stands, it is refreshing to see a company that sets the right expectations, that allocates the appropriate resources to support training that delivers tangible results. The jargons might not be there, and coming to terms that computers are made of millions of switches might take some time to set in, but the professional qualities of a person are fluid and cross-domain.
Clean code is about getting yourself together — becoming a tidy, organised, precise person. Agile is about constant negotiation leading to a shared agreed outcome. TDD is about setting clear goals and reaching them. KISS is about clear communication. If I put it this way, are these not universal concepts about “what to do to work together effectively”? There is no need for rockstars; give me a competent, humble person anytime, and let’s build them up.
The job of the mentor is to recognise the potential in mentees, and find ways to meet them where they are. To help them practice, to make the work of gaining experience less painful so they can fulfil their potential. Worry not about not knowing loops and the big O notation; worry more about not being able to synthesise these with what the mentees already know — inducing that spark of creation, from zero to infinity.
On the other side of the bridge awaits The Ideal Mentee.
Her priority was her family — she ended up going back home to help out her family business. Though I had thought — and still do — that it was a great underutilisation of a potential, it is her life. We remain best friends, trading memes, shitposts, and having great many interesting conversations about everything.
Although, given high enough shortage or low enough demand, this model can and will change — just look at the cadetship recruitment funnel of network engineers; a stark contrast to the 2014 mechanical engineering job funnel. Most recently, for example, the pandemic labour shortage swung the pendulum to the other end where employers are offering $500 sign-up bonuses for entry level jobs in the hospitality sector.
I am not sure what else to call it. Some say instinct, maybe pattern recognition, scatterbraining, but I don’t do well in learning theories and applying it — the other way works better as a series of semi-random, seemingly unrelated things that one day “clicks”. Maybe it’s worth looking into someday.