blog
date: 2021-06-04
summary: Essential Learning Concepts
This post is about learning a new thing, and focusing on the actions that produce the value from the new thing.
I do not care to learn how to tune the fuel injectors in my car's engine.
- I put gas in
- I drive the car
- I live my life
However, if fuel injection stops me from driving the car, I either Google how to fix it or hire someone to fix it. Then I put gas in, drive and live my life.
In software, there is no end to the mountains of knowledge you could pursue.
Did you know there is a mailing list dedicated to the
curlcommand?
Bill Gates once said: "...build breadth of knowledge over depth of knowlege"
Suffice to say, you can nerd-out on many things.
The Breadth/Depth Dilemma is to choose the depth you need for a given thing, while you live your life.
In 1999 there was a very thick book that covered PC hardware. 464 pages of glorious detail, a surefire cure for insominia. At the time, this thick book was loved by many IT technicians. Had you spent months reading that book in 1999, you would have been highly qualified to service PC hardware of that day.
Today it is a of piece history. If you spent a lot of time learning PC hardware of the late 90s, you might cry in your beer that the jobs of today do not value your talent, just as the Luddites complained about machine looms taking over their jobs of weaving cloth in the early 1800s.
The same dilemma confronts all of us today, especially in software engineering.
We have to constantly choose where to invest our attention to:
1) Do our jobs as developers
2) Build and maintain our personal skillset / brand
It can be demoralizing as a developer to constantly compare yourself to a guru on a given subject. My goal with this post is to isolate the forces and factors behind going wide or deep on a given subject, based on your own, discerned, evolving need to know forces and factors.
It is OK to NOT know some things, PERIOD.
It is OK to NOT know some things, YET.
It is imperative to learn some things, NOW.
How wide and how deep you go, DEPENDS.
There are things that are not worth your time learning.
There are things that are not even worth bookmarking in your browser. Having bookmarked thousands of things along my learning path, I can tell you that much of it is rarely used, has changed or can just be Googled again should I need to go there.
My own tendency is to gather and hoard knowledge, links, books, tutorials and minutiae. It comforts me that I've stored these things somewhere. But I am becoming more pragmatic, asking myself if I really need to store everything, or can it be effectively Googled.
Please forgive yourself for not knowing everything.
Be confident that you can pick up new skills as needed.
As a software developer, there is a huge ongoing list of things you could/should know.
I will not create a new list here.
Ok, can't resist, here is an example.
The awareness of the major categories of your list based on YOUR goals is what is most important. You do YOU. Figure out the meaningful list for your goals. And if you are a web developer in 2020's, you should at least be aware of the major categories that you will encounter in a job.
You want to develop this awareness as you journey in your job and personal growth. Watch for major things you need in your skillset and create placeholders for them.
This is the list of things:
- that are in your immediate future
- that your job requires for success
- that you are most interested in (life is short, it all becomes dust faster than you know, go for the worthwhile things you enjoy, and hopefully can get paid to do)
I have had to develop the ability to quickly scan documentation and determine:
- am I getting a grounding of the basics
- should I read first, or watch an overview tutorial
- what are the key elements
- what commands should I learn
- how to do hello world in this subject area
- how does this fit into the developer landscape
In any endeavor, I want to fit this new thing into my personal tree of knowledge.
for example
I need to know how to ssh into a linux server, because I need to deploy apps and troubleshoot issues in devops.
However, I don't need to know how to optimize the memory in a Linux server, YET (maybe never? if I'm focused on front end work?).
I don't need to know every folder in the server right now, but I do need to know how to ssh in, create users, deploy apps, connect to a database and find and grep the error logs.I don't need to know
how to launch a small scale nuclear attack from the command line, but I do need to know how to navigate, crud files and folders, create scripts, cron jobs and how to use Vim and Nano editors.
For me the holy grail of learning is where I can go from zero to hello_world to building my desired outcomes using documentation and written tutorials. However, my experience is that I need to attack the problem by a combination of reading, code alongs, code improvisation and videos of experts who narrate their code as they go.
Personally I love the teaching style of Maximillian Schwartzmuller, of Academind and Udemy.
Max has German as his first language, so his English is very specific both in his usage of words and especially his usage of tone to categorize thoughts as he speaks. He provides essential repetition of concepts covered, so that I ingest the knowledge more readily than if he were to just spew out code. He has a way of communicating the 'why' along with the 'how' while connecting it to things you have just begun to understand.
Get a second opinion! It is amazing how a concept comes to life when you learn it from different teachers. You'll get new insights while confirming things you've learned from other teachers, which turns into deeper understanding, sooner.
No one method of learning works for everyone. Using a variety of good resources creates a multi-brain, visceral learning experience. If a tutorial is not grabbing your attention, or is going too deep in one direction for what you need right now, find more resources. Code along and build mini apps. Practice good Git hygiene along the way, so that when the pressure is on to deploy on Friday at 5PM, your chops are ready!
Try to find where the actual value lies in whatever you are learning, and learn the actions that produce that value.
Users pay for functionality that acheives their goals.
For the most part, users do not want to pay you for tinkering in your workshop.Ultimately, there is a set of tasks that equal success in your job, where the company is your customer. You owe them an earest effort to continually seek out this list and do embrace it.
Whenever I'm about to do something, I think 'Would an idiot do that?' And if they would, I do not do that thing. -Dwight Schrute
AWS never stops growing in functionality, security layering, interaction and documentation. It has become a discrete study, as if you were learning Java or Golang, AWS is a beast of its own.
So if a job description requires AWS Lambda for example.
Yikes that is a huge thing! But maybe not.
Maybe if you can deploy some code using it, tweak it and get a foothold on how it works, you'll have more confidence when it comes up in an interview, or lands on your task list in a job.
Let's explore some high level ideas about learning a thing as it pertains to web development
Thinking about coding languages, frameworks, devops, etc.
Some things are based on syntax and DSL (Domain Specific Language)
Some things are based on configuration and usage of existing functions/methods from a package, gem or module. (such as Ruby and Gems, or Node and NPM)
Some things are complete ecosystems that have specific config settings to interact with. (such as GraphQL)
Some things require mastery/memorization of phrases and snippets so that the tools are in your head, so that you can connect them with problems. (such SSIS for SQL Server)
Some things only need to be installed, configured and "talked to" from some other thing.
Some things come in chunks, for example if you learn how SASS variables work and how to integrate it with BEM styling, you pick up a whole world of expertise with a few basic learnings. Contrast this with learning Go or Python for the first time, you'll have a longer ramp up to get conversant and productive.
Knowing this, you can trouble-shoot things based on a minimal understanding, simply because you have understood how a thing fits, how to talk to it, how to configure it, where to find the magic functions it provides and the end result you need from it.
We all have imposter syndrome to some degree. It would be impossible to not have it given the huge buffet of technologies we deal with, combined with any level of personal integrity.
I think that clients, bosses and coworkers will give you the benefit of the doubt if:
- you are sincerely growing your awareness and prioritizing of the various lists
- you are nimble about refining where to put your attention
- you are always working on improving both your breadth of awareness and your depth on the right things that matter most in your goals and job
- and most of all you are communicating sensibly about blockers and current understanding
In my past I have played music with a few world-reknowned musicians. My experience is that the best players are the most receptive to helping you, given your sincere efforts, humility and ability to take suggestions.
I personally invite you to join any of our open source projects, spin up a new project or suggest a project you wish to work on. I will join you and we can focus our energies on learning the basics together!