Decogen

Experiments In Accelerated Learning

[decogen-blog]

Barbara Oakley gives us a way to think about different ways to learn and solve problems. She explains the difference between focused attention and diffuse attention, how to handle procrastination by using the Pomodoro technique, chunking and interleaving, and more.

She also has a course available on Coursera:

Learning How to Learn: Powerful mental tools to help you master tough subjects

[codingwhilefemale-blog]

The Psychology of Code Testability and the Importance of Updated Information

This week I took a course on code testability on Front End Masters. It was taught by Misko Hevery, of AngularJS. I found Misko’s explanation of testing to be super clear and a great introduction to testing even for someone who hasn’t tested before.

However, Hevery argues that the best code can be easily tested from the beginning of the development process. I think this is a fault in his logic, but this video was made in 2011. Lightyears in the tech industry.

I was convinced from the beginning that I needed to fact check this video. It felt like taking outdated HTML advice from W3Schools. 

Exhibit A: Hevery’s Blog. If you look past the awful UI, you’ll find that the content of his blog was mostly written in 2008. This is also a warning sign that his advice may not have withstood the test of time. 

So I turned to the internet for Exhibit B: A great medium article on Unit Testing.

Another fault in Hevery’s logic is that he does not cover Test Driven Development in such an actionable and streamlined way like this blog did. He actually spent most of the beginning of the course asserting that developers do not write tests because they do not know how. 

So here are a few great best practices on Unit Testing: 

1. Write tests first.

Tests are your first line of defense against bugs, and can also serve as a guide to figuring out the logic of your code. It’s like good pseudocode that also flushes out your edge cases if you are writing robust tests. 

2. Write Robust Tests.

A good question I always ask myself when i’m testing is “What will my code do with a type that does not match it’s intended input type?” I find that this question brings out a lot of edge cases I may have not thought of.

3. Refactor your code to be testable and readable.

There are several developers who have written about writing code that is intended to be testable, but I disagree. I think refactoring is an important process in development and refactoring to a testable codebase can show your edge cases very easily. 

So, dear Front End Masters, please give us an updated course on testing. 

[decogen-blog]

“Rethinking Asynchronous JavaScript” by Kyle Simpson

This past week, I began the course “Rethinking Asynchronous JavaScript” given by Kyle Simpson, head of curriculum at MakerSquare and author of You Don’t Know JS series. Unlike other workshops that focus on how to use a specific technology, Simpson works to build up our conceptual understanding of how JavaScript works before giving us example problems to solve. In the case of this course, he explains several patterns for dealing with asynchronous JavaScript calls, beginning with what is asynchronous versus parallel processing - the two are often conflated.

As he explains, parallel processing is actually the opposite of non-parallel processing. Giving the example of a rollercoaster ride, non-parallel processing is where a single person gets on a ride at once. With parallel processing, 30 people get on the same ride and experience it at the same time. Asynchronous processing is different from both of these. In asynchronous processing, two or more macro-level processes are broken down into micro-level tasks. These micro-level tasks are interwoven and happen at different times, but overall it takes the same amount of time to process both macro-tasks.

In asynchronous processing, micro-level steps happen not in order, but out of order, and the macro-tasks are said to happen concurrently. “Asynchronous patterns”, he tells us, “is a way to manage concurrency patterns,” which can become very complex.

One way to handle concurrency and asynchronous tasks is to use callbacks, but this produces some problems. One familiar problem is what is called callback-hell or the pyramid of doom, but Simpson explains that the real problem with these nested calls is not what they look like, but that it makes our code difficult for coders to reason about and to follow. The main issue with using callbacks to handle concurrency is what is called the inversion of control, which is when we hand over control of one part of our program over to another part of our program hat we don’t control. This exposes a trust point that creates bugs that can emerge in unexpected and surprising ways.

Our brains, Simpson explains, are single threaded at even the highest levels - as we have come to learn, there is no such things as multitasking. Wherever our brain diverges from how JS works, that is where bugs happen. If you write your code more like your brain thinks, there is less divergence and fewer bugs; if you can learn and use patterns that work like your brain thinks, that is the best approach. So we need better patterns with which to handle concurrency.

The rest of the course covers several different solutions to concurrency, and a single problem example is solved in these multiple ways to expose the particular strengths and weaknesses of each approach. 

In what follows, Simpson explains a very old pattern that has been around since the 60’s, called thunks, a pattern that underlies modern Promises. Now, Promises is a solution not only to concurrency and managing state in asynchronous Javascript programing, but also the trust point issue. But Promises exposes another set of problems, and Promises is best paired with generators. This will the subject of the rest of the course, which I will cover in a subsequent blog post.

[decogen-blog]

Frontend Masters’ “Learn Functional-Lite Programming” by Kyle Simpson

It is easy to see why Kyle Simpson of You Don’t Know JS fame is so beloved amongst javascript coding newbies. He has the uncanny ability to boil down concepts to their essence without compromising conceptual rigor, and he as careful as a philosopher with his use of language. For example, at one point in his “Learn Functional-Lite Programming” tutorial on Front End Masters, he kindly corrects an audience member’s question, saying that it is not appropriate to say that in the case where:

x = [1,2,3]

y = x

“x” and “y” are the same, but rather they are references to the same array, thereby illustrating values that are passed by reference. The tutorial is a set of excellent lectures on core functional programming concepts, structures,and techniques available for use by all (javascript) programers.  

Kyle Simpson explains and give examples for the following:

Side effects

Composition

Immutability

Closure

Recursion

List operations or transformations, including:

       .map()        .filter()        .reduce()

The examples Kyle Simpson offers are carefully constructed to best illustrate the concept at hand, and the exercises are pitched at the right level of difficulty to stretch the understanding.  

He is also careful to distinguish the common usage of terms versus how they are used from a functional programing perspective. For example, one of the most interesting examples for me was that of compostability. The idea that you can set one of the parameters of a function in this way was new to me.

I believed that I was going to review materials that I had already encountered, but as it turned out, I learned a number of new things not only about functional programing, but about how javascript actually works under the hood. Kyle Simpson’s understanding of javascript, and his ability to explain it, is a gift.

[decogen-blog]

Learning React Using Perceptual Learning Techniques

In this blog post, I will give an account of my first attempt at learning how to use perceptual learning principles for learning React, “a declarative, efficient, and flexible JavaScript library for building user interfaces.” 

The Basics

With REACT, we are dealing with a particular way of laying out code, or architecture, commonly referred to as “the React way,” and a set of concepts important to understanding React, such as states (i.e., state-full vs. stateless functions) and intermediate functional programming operations. There is probably more to be said here but this is what I understood of React as I began this experiment. I had no previous experience working with React when I began.

Perceptual learning is premised on the idea that our subconscious is between 500,000 to 200 million times more powerful than our conscious. What we can consciously register is minuscule when compared to all the work that our subconscious is doing to help us navigate the world. What if we could harness the power of the subconscious and put it on the task of learning something? This is what perceptual learning is all about.

Perceptual learning is “perceptual” because it uses our incredible powers of perception (outwardly, these are our senses) to access our subconscious. I used my vision to read code, and sound/hearing to listen to the code I was reading (using text-to-speech feature built into my computer). 

[ I should have enlisted my tactile sense by using my left hand and finger to follow along with the code - next time. I did not use smell, taste, or proprioception, but will think of ways of enlisting these in future experiments.]

I set the task to expose myself to many good examples of React over a short period of time to see if I could achieve expertise in React in a matter of weeks, not months or years. The examples have to be good examples - and by good I mean well organized, readable code of increasing levels of complexity. Below is my account of week one on this task.

What I Did

The first thing I did was, in retrospect, counterproductive, and my first instinct was to rely on old ways of learning. I watched a tutorial to get an orientation in React. I chose the React Fundamentals course on Pluralsight because they offer uninterrupted (by quizzes) videos that can be watched on high speeds. In hindsight, I should have jumped into reading code right away....

The hardest thing was finding good examples of code, of increasing levels of difficulty, to read. Here are some resources that I uncovered:

5 Practical Examples For Learning The React Framework - five tiny projects of increasing difficulty, with comments, explanations, and the ability to run the code and see the results.

From the React getting started documentation page, this Tutorial: Intro To React that takes you through the steps to build an interactive tic-tac-toe game.

React.rocks collects a number of cool React projects and I followed some of these links to take a look at the projects’ code.

I spent about two hours reading through React code (unfortunately, not long enough), and I like to work in blocks of 40 minutes with a 5-10 minute break in between sessions using this Pomodoro Clock that I built for FreeCodeCamp. 

After this, I jumped into an Open Source Software (OSS) Project available to me as a learner at Learners Guild - a clone of Trello. This was my official project for the week, and we had three issues that we were working to fix, one of which entailed building out some React components. Me and my partner on the project spent a good amount of time orienting ourselves in the code (about four hours) and working our way up to the task. 

I also had the opportunity to shadow a group working on another OSS project at the Guild, read the code they were working on and observed their process. 

The Results

After a couple days or so of perceptual learning and orienting myself in the well-organized code base I would be working with, I was able to jump in and navigate our team through extracting our a search bar component, putting it into its own file, and injecting it into the two places where it needed to be used.  But I did have the help of the team lead (a professional programer) in implementing the changes.

I would not say that I acquired competency in React (I’d say I acquired familiarity and was comfortable working in a React code base) because I did break the code pretty badly a couple of times and had to revert to a prior commit and start over.  When I broke the code, I tried to fix it and what I tried seemed to make things worse - not being familiar with reading React error messages made it difficult for me to troubleshoot the problems. 

All in all, I came away feeling that what I had done to learn React was not that much different from what i have been doing in the past, availing myself of tutorials. I feel that I did not push myself hard enough to learn in a different way, and next time I will try to get out of my own way more and give my subconscious the space to do its work.

Take Aways

I probably jumped into the OSS project too soon. I feel that I should have spent some time building a small React project, where I would have been able to break and fix things more easily. But the good news is that building a simple app would have been well within my ZPD (Zone of Proximal Development)...

I got the grasp of some basic concepts that are well used in React, such as state-full functions, components, and controlled components, but I also realized that I needed to know a little bit more about functional programing - so I did discover some holes in my knowledge that I can work to fill. 

I also came away with some questions about what is the use of React - I mean, it’s a javascript library so there is nothing you can do with React that you cannot do with plain old javascript. I found that all the compartmentalization that comes with building things out with components in the React way created a number of problems - maybe more than necessary. That is, I wasn’t sure what kind of project would benefit from React. 

So I did a Google search and found a good answer:

React is cool. Switching to React helped me do :

1. Get rid of any jquery-like library.

2. Get rid of my HTML/Handlebars files :)

3. Generate dynamic CSS classNames for my components allowed me to get rid of stylesheets naming conventions / strategies ( BEM, etc. )

4. With the help of Flux ( yahoo's implementation ) I got rid of writing two code-bases ( front-end / back-end ). Now I'm putting everything in one place, this is awesome! ( I did it with server-side rendering, so I didn't loose anything at all )

Source: https://news.ycombinator.com/item?id=10348117

I also found this blog post on Medium helpful: “React is cool, deal with it”

[decogen-blog]

Let’s start at the beginning. Here is the video that inspired me to think more deliberately about how I was going about learning how to code, which lead me to start this blog. 

At around 15 minutes into this video from FLUENT 2015, Kathy Sierra begins to talk about something named perceptual learning. What is perceptual learning, you ask? It basically entails exposing yourself to a lot of what it is that you want to learn over a short period of time as a way of gaining expertise; but here is one more formal answer: 

"Perceptual learning is the specific and relatively permanent modification of perception and behavior following sensory experience. It encompasses parts of the learning process that are independent from conscious forms of learning and involve structural and/or functional changes in primary sensory cortices."    [my emphasis; source: http://cognet.mit.edu/book/perceptual-learning]

Now, I will write more later about this, and what others have said about perceptual learning, but I wanted to share that with you here so that I can build upon it. 

In my next blog post, I will write about this past week’s experiment in perceptual learning as I applied it to learning REACT. As you might imagine, I looked at a lot of REACT code over a short period of time, and the results where .... [cliff hanger!]

[decogen-blog]

Hello World!

I’m experimenting with accelerated learning methods in order to learn how to learn to code not only furiously fast, but also deeply.

The Decogen blog will take you along on my adventures so that maybe you too can learn how to best develop technological expertise efficiently and quickly. 

In brief, I’ll share what I’m learning about learning, practical examples from my own experiments (learning full stack javascript), and the specific methods I am using to build my learning capacity and accelerate my learning.

What ever it is that you want to learn, I hope that you will find some useful tools here at Decogen. And if you’ve tried something that worked for you, drop me a line and maybe I will cover it here!

Dr. A

Self-taught Front-End Web Developer, currently a Full-Stack Apprentice at Learners Guild with a background in Philosophy, Higher Education, and Photography.