Published on

Avoid Learning Things That Do Not Compound

Authors

Foreword

We are often ought to complete a task or learn a new thing; however, decision paralysis may hinder your ability to clearly define the boundaries. For many people, grasping the basics is not enough and they would like to rigorously study the subject, leading to inability to deliver on time.

If you are going to learn some new stuff, pr, for example, you are weighing in the prospects of accepting a job offer - always think about the consequences of your choice, or, more specifically, about if the stuff you'd be doing will compound, a term heavily used in finance. Simply put - can you use your newly acquired skills elsewhere and build on their foundation.

Now, to a more practical part.

The Method

Make use of the personal development thought map. Write down your possible choices and evaluate them based on how long of a continuous connecting line you could draw. Group them by some overlapping feature, link them together.

After writing down your initial scopes of interest, try to build a nested tree and arrange the items in such a way, that each item could find itself on a single level only and would allow for the minimal number of downgoing branches. Consider comparing the items by the effort required to do/learn stuff, time to complete the task, number of interconnection points with other items, and some other properties you may consider important personally. Ideally, you should eventually get to a flatted-out sequence of steps (that is, one item organically follows another), but if you're not able to achieve perfection, you'll end up with a tree of varying complexity. If so, evaluate not by the item, but by the branch from top to bottom, applying the same principle.

When I use the described approach, while evaluating items or branches, I ask myself - is a skill/task a dead end? I may accomplish a thing and would only be able to further my expertise with diminishing returns and utilize it in the single applicable field, but not elsewhere. If it is a dead end, it's probably safe to ignore that item altogether for now (or be content with a simple introduction/preparation work) and reevaluate the possibilities later.

As a developer, you would write down a map, put different areas of expertise (Front End, DevOps, specific frameworks, languages, etc) onto the paper, group the items if the domains intersect, and try to connect those. What you do here is building a learning curve you'd be comfortable with.

Personal Advice Based On Anecdotal Evidence

All said, I would like to outline some things in the software engineering domain which I consider non-compounding.

Back in the days when I was searching for a job, I would often be asked to write some kind of test (as many of you were too) by a prospective employer - I was so reluctant to pick up anything that would not teach me something new. So, your typical webdev exercise - write some REST server, utilize a set of specific tools, cover everything with units. And I have never finished of those, yet alone written a line of code! I had done such things countless times in the past, and such exercises neither sharpen nor build up my skills; thus they are a complete waste of time. However, when offered some task (with realistic expectations) I would be only happy to complete it ASAP. Time proved my decisions were right when I took on the tasks - to work on something that had never been done before or to build essential skills from the ground up in a domain completely unknown to me at that time - opening up numerous well-paying prospects.

Nitpicky tasks like something as basic as a REST server (and algorithms in hiring interviews) may be partly attributed to our broken hiring system, with all the gatekeeping to it; but it's a matter for another discussion.

Another thing I've noticed of novice front end web developers: those, who pick up tasks more demanding than their assumed current expertise PLUS those who like to cut corners progress faster, and eventually achieve more. The cutting corners part is as important as the heavy lifting part.

A nice work pattern for novice front end web developers - they spend time searching for the ready-made paid website template layouts on the web and tell their employer or customer to provide money to buy those, giving up on the notion of "Not invented here". Indeed, you can buy from an endless variety of ready-made templates and tweak those to the likings of you and your customer. In the meantime, all those minor tweaks will amass into a lot of nifty abstractions and snippets big enough to be considered your own css/js framework. And by doing so you have minimal friction - you do only what you have to do immediately, and most of the tasks are solvable with some googling.

Another especially dangerous place where one finds themselves at the dead end quite often is the systems and embedded programming. I've met many talented programmers in this field; many eventually became web and game developers; however, I think, they could have easily acquired the necessary skills faster. Held by their gift of being an embedded or systems programmer (and I mean an actually employed one), these people often exhibit higher than average effort to get to their desired level of income. I may attribute this to both embedded/systems being quite a niche per-se and to the practices aquired on during the employment tenures - old editions of a low-level language (C or C++) with dated patterns and underutilization of many modern abstractions.

Take this with a grain of salt, but I suggest you avoid getting colledge education in the CompSci field. You don't really need most of that stuff. Getting to academia is a dead end.

Closing Thoughts

One may say, the caveat of the proposed method is that you become a jack of all trades and the ace of none. Objection to this is that you're picking the skills required for the fastest and reasonable resolution. It would be rather hard to build on the foundations which are not solid; that is, your skills being acquired in a "fake it till you make it" fashion.

The obvious exception to this is if you're quite enjoying the stuff that you do, it makes you happy and you're content with and not afraid of hitting a dead end.

Immediate actions should have long-lasting positive consequences. And you should look ahead for the dead ends.

Made it this far? Enjoying the read?
Sign up for the newsletter to never miss a post