Spencer Corwin's Blog

How to Create a Mind

Fri, 05 Apr 2019 00:00:00 GMT

“A computer would deserve to be called intelligent if it could deceive a human into believing that it was human.” — Alan Turing

In my first blog post I discussed why I decided to quit my job as a banker and become a software engineer. The primary reason was a shift in my thinking that was caused by Ray Kurzweil’s latest book How to Create a Mind, which was published in 2012. I read this book in mid-2017 and it completed changed the way I saw the future. Before reading this book I was under the mistaken impression that the ship had sailed on information technology. I thought it was essentially too late to get into the world of computers because by the time I would have “caught up” with the rest of the industry in terms of knowledge and skill it would be too late for me to make any real impact, so therefore there was little point in making such a transition. In my mind computers were cool and all, but it was just too late. I thought I might as well try to find another way to make an impact. Reading How to Create a Mind shattered that way of thinking for me and opened my eyes to the infinite potential that still exists in information-based technologies (ie. computers and software). In this book Kurzweil specifically tackles the human brain, how it works, how we will succeed in reverse-engineering it, and how our understanding of it is enabling us to create artificial intelligence. As AI has has begun to enter the mainstream it appears that we are on the verge of an explosion of applications that utilize AI for awesome new applications. It is this new “revolution” that caught my attention and inspired me to enter the field of software.

Ray Kurzweil and the Law of Accelerating Returns

Whenever I discuss my story with anyone I have to first ask if they’ve heard of Kurzweil and his ideas, because he is a somewhat polarizing figure to anyone who is familiar with his work. He is famous for his many predictions of when certain technological benchmarks will be met. Nearly every one of his predictions sound impossibly rediculous at the time he makes them, yet most of them have come true. But before I get to Kurzweil’s wildest predictions I should say that Kurzweil is not a professional theorist. He writes a lot of books and has spoken at many conferences, but his day job is as an inventor, entrepreneur, and Direct of Engineering at Google. It’s easy to make predictions, but it’s an entirely other thing to use your understanding of technological trends to succesfully invent and sell amazing products, which is what Kurzweil has done. The best example of this is a company started by Kurzweil called Kurzweil Computer Products, which he started in 1974 to develop the first optical character recognition system, which was then used for a text-to-speech synthesizer to allow blind people to understand written text by having a computer read it to them aloud. Eventually the company became Nuance Speech Technologies, which developed the technology that is now Apple’s Siri.

In Kurzweil’s first book, The Age of Intelligent Machines, written in the mid-1980s (published 1990), he predicted that a computer would take the world chess championship by 1998. IBM’s chess supercomputer Deep Blue famously defeated the reigning human world chess champion, Garry Kasparov in 1997, thereby fulfilling one of Kurzweil’s most famous predictions. In The Age of Intelligent Machines Kurzweil also predicted the emergence in the mid to late 1990s of a vast worldwide web of communications tying together people around the world to one another and to all human knowledge. Kurzweil has made many more predictions in past books and still has predictions outstanding, for example his prediction that a computer will pass the Turing test by 2029 (which would signal it has intelligence on par with a human). As Ray tells it in How to Create a Mind, ”The Age of Spiritual Machines included hundreds of predictions for specific decades (2009 , 2019 , 2029 , and 2099). For example, I made 147 predictions for 2009 in The Age of Spiritual Machines, which I wrote in the 1990s. Of these, 115 (78 percent) are entirely correct as of the end of 2009; the predictions that were concerned with basic measurements of the capacity and price/performance of information technologies were particularly accurate. Another 12 (8 percent) are “essentially correct.” A total of 127 predictions (86 percent) are correct or essentially correct. (Since the predictions were made specific to a given decade, a prediction for 2009 was considered “essentially correct” if it came true in 2010 or 2011.) Another 17 (12 percent) are partially correct, and 3 (2 percent) are wrong.”

Kurzweil’s predictions are based on his theory called the Law of Accelerating Returns, which states that fundamental measures of information technology follow predictable and exponential trajectories. This concept is beyond the scope of this blog post, but can be pretty well explained visually with the chart below. The most dramatic example of the LOAR is the remarkably predictable exponential growth in the capacity and price/performance of computers. The evolutionary process of technology led invariably to the computer, which has in turn enabled a vast expansion of our knowledge base, permitting extensive links from one area of knowledge to another.

The Pattern Recognition Theory of the Mind

How to Create a Mind seeks to understand precisely how the human brain works, and then to use those methods to create even more intelligent machines.

In his book, Kurzweil presents a thesis called the Pattern Recognition Theory of Mind (PRTM), which describes the basic algorithm of the neocortex (the region of the brain responsible for perception, memory, and critical thinking). Kurzweil uses his own thought experiments, as well as neuroscience research to create his PRTM.

Kurzweil argues that the neocortex is composed of a highly repetitive structure, allowing humans to create arbitrarily complex structures of ideas. We are capable of hierarchical thinking, of understanding a structure composed of diverse elements arranged in a pattern, representing that arrangement with a symbol, and then using that symbol as an element in a yet more elaborate configuration. This capability takes place in a brain structure called the neocortex, which in humans has achieved a threshold of sophistication and capacity such that we are able to call these patterns ideas. Through an unending recursive process we are capable of building ideas that are ever more complex.

The human neocortex contains about 300 million pattern recognizer modules, arranged in a hierarchy. For example, to recognize a written word there might be several pattern recognizers for each different letter stroke: diagonal, horizontal, vertical or curved. The output of these recognizers would feed into higher level pattern recognizers, which look for the pattern of strokes which form a letter. Finally a word-level recognizer uses the output of the letter recognizers. All the while signals feed both “forward” and “backward”. For example, if a letter is obscured, but the remaining letters strongly indicate a certain word, the word-level recognizer might suggest to the letter-recognizer which letter to look for, and the letter-level would suggest which strokes to look for. This is a single sentence summarization of the pattern recognizer that Kurzweil discusses at length in his book.

How To Create a Mind

So how would PRTM be repeated in computers? Kurzweil suggests that the best results will come from using hierarchical hidden Markov models and genetic algorithms, especially since he used all three successfully in his speech recognition work.

We would start with the pattern recognizer module. Make as many copies of the recognizer as we have memory and computational resources to support. Each recognizer computes the probability that its pattern has been recognized. In doing so, it takes into consideration the observed magnitude of each input (in some appropriate continuum) and matches these against the learned size and size variability parameters associated with each input. The recognizer triggers its simulated axon if that computed probability exceeds a threshold. This threshold and the parameters that control the computation of the pattern’s probability are among the parameters we will optimize with a genetic algorithm. Because it is not a requirement that every input be active for a pattern to be recognized, this provides for autoassociative recognition (that is, recognizing a pattern based on only part of the pattern being present). We also allow for inhibitory signals (signals that indicate that the pattern is less likely). Recognition of the pattern sends an active signal up the simulated axon of this pattern recognizer. This axon is in turn connected to one or more pattern recognizers at the next higher conceptual level. All of the pattern recognizers connected at the next higher conceptual level are accepting this pattern as one of its inputs. Each pattern recognizer also sends signals down to pattern recognizers at lower conceptual levels whenever most of a pattern has been recognized, indicating that the rest of the pattern is “expected.” Each pattern recognizer has one or more of these expected signal input channels. When an expected signal is received in this way, the threshold for recognition of this pattern recognizer is lowered (made easier). The pattern recognizers are responsible for “wiring” themselves to other pattern recognizers up and down the conceptual hierarchy. Note that all the “wires” in a software implementation operate via virtual links (which are basically memory pointers) and not actual wires. This system is actually much more flexible than that in the biological brain. In a human brain, new patterns have to be assigned to an actual physical pattern recognizer, and new connections have to be made with an actual axon to dendrite link. Usually this means taking an existing physical connection that is approximately what is needed and then growing the necessary axon and dendrite extensions to complete the full connection.

To implement this approach to self-organizing hierarchical pattern recognition we should use hierarchical hidden Markov models. Note that not all hidden Markov model systems are fully hierarchical. To build a brain, we will want to enable our system to create as many new levels of hierarchy as needed. Also, most hidden Markov model systems are not fully self-organizing. A key requirement is to allow for the system to flexibly create its own topologies based on the patterns it is exposed to.

Our digital brain will also accommodate substantial redundancy of each pattern, especially ones that occur frequently. This allows for robust recognition of common patterns and is also one of the key methods to achieving invariant recognition of different forms of a pattern. We will, however, need rules for how much redundancy to permit, as we don’t want to use up excessive amounts of memory on very common low-level patterns.

The rules regarding redundancy, recognition thresholds, and the effect on the threshold of a “this pattern is expected” indication are a few examples of key overall parameters that affect the performance of this type of self-organizing system. We would initially set these parameters based on intuition, but we would then optimize them using a genetic algorithm.

A hierarchical pattern recognition system (digital or biological) will only learn about two, preferably one, hierarchical levels at a time. To bootstrap the system we would start with previously trained hierarchical networks that have already learned their lessons in recognizing human speech, printed characters, and natural-language structures. Such a system would be capable of reading natural-language documents but would only be able to master approximately one conceptual level at a time. Previously learned levels would provide a relatively stable basis to learn the next level. The system can read the same documents over and over, gaining new conceptual levels with each subsequent reading, similar to the way people reread and achieve a deeper understanding of texts.

We should also provide a critical thinking module, which would perform a continual background scan of all of the existing patterns, reviewing their compatibility with the other patterns (ideas) in this software neocortex. We have no such facility in our biological brains, which is why people can hold completely inconsistent thoughts with equanimity. Upon identifying an inconsistent idea, the digital module would begin a search for a resolution, including its own cortical structures as well as all of the vast literature available to it. A resolution might simply mean determining that one of the inconsistent ideas is simply incorrect (if contradicated by a preponderance of conflicting data). More constructively, it would find an idea at a higher conceptual level that resolves the apparent contradiction by providing a perspective that explains each idea. The system would add this resolution as a new pattern and link to the ideas that initially triggered the search for the resolution. This critical thinking module would run as a continual background task.

We should also provide a module that identifies open questions in every discipline. As another continual background task, it would search for solutions to them in other disparate areas of knowledge. The knowledge in the neocortex consists of deeply nested patterns of patterns and is therefore entirely metaphorical. We can use one pattern to provide a solution or insight in an apparently disconnected field using these metaphors.

We should provide a means of stepping through multiple lists simultaneously to provide the equivalent of structured thought. A list might be the statement of the constraints that a solution to a problem must satisfy. Each step can generate a recursive search through the existing hierarchy of ideas or a search through available literature. We will also want to enhance our artificial brains with the kind of intelligence that computers have always excelled in, which is the ability to master vast databases accurately and implement known algorithms quickly and efficiently. Finally, any new brain will need a purpose, a series of goals, to set it in the right direction.

The brain is extremely slow but massively parallel. Today’s digital circuits are at least 10 million times faster than the brain’s electrochemical switches. Conversely, all 300 million of the brain’s neocortical pattern recognizers process simultaneously, and all quadrillion of its interneuronal connections are potentially computing at the same time. The key issue for providing the requisite hardware to successfully model a human brain, though, is the overall memory and computational throughput required. We do not need to directly copy the brain’s architecture, which would be a very inefficient and inflexible approach.

Our new digital brain can be expanded in ways that a human biological brain cannot. Once a digital neocortex learns a skill, it can transfer that know-how in minutes or even seconds. When we augment our own neocortex with a synthetic version, we won’t have to worry about how much additional neocortex can physically fit into our bodies and brains, as most of it will be in the cloud, like most of the computing we use today. As soon as we start thinking in the cloud, there will be no natural limits— we will be able to use billions or trillions of pattern recognizers, basically whatever we need, and whatever the law of accelerating returns can provide at each point in time. Lastly, we will of course be able to back up the digital portion of our intelligence, never losing any knowledge or memories ever again.

As I hope I’ve summarized in this blog post, combining human-level pattern recognition with the inherent speed and accuracy of computers will result in very powerful abilities and a very bright future indeed, which is what got me so excited in the first place and has lead me to this point in my life.

How I Built My First Full-Stack Web Application

Thu, 31 Jan 2019 00:00:00 GMT

The Project

As I worked on the Free Code Camp curriculum I knew I wanted to work on my own projects. I had built up a list of cool ideas that I thought would be fun, educational, and were well within my capabilities. So after finishing the Free Code Camp curriculum in mid-December 2018 I was ready to go with my first independent, full-stack web application. I was eager to build something from the ground up that was entirely my own.

My best idea for this first project was called Digidex (short for digital-index). The idea is for the app is one that I had been contemplating for a while. In the past when I worked in sales position I usually had access to a customer relationship management software like Salesforce to keep track of leads, progress on deals, track workflow management, and more. Salesforce is a powerful and feature-rich tool for sales people in all fields. But I wanted to have a Salesforce-like tool to keep track of my personal acquaintances that didn’t necessarily belong in my employer’s Salesforce database. Usually these were, and are, people that I am not looking to sell anything too, but are people that aren’t necessarily close friends. I looked for a tool like this but couldn’t find anything good. So I figured this would be a great little project for me to pursue, since it was within my technical reach and was a product that I could design and build for the ideal user: me.

The primary goal with building a full-stack project would be to learn. I especially wanted to fill a perceived gap in my knowledge of how to connect all the pieces of a web-application that I had learned as part of FCC. I knew conceptually how I would connect a database, to an Express server, to a React front-end, but I also knew that knowing something conceptually is not the same as being able to do it in practice. So my goal was to use this project as a course in actually building a real, live web application. I would use React and React Router on the front-end, NodeJS and ExpressJS for the server (plus some small er libraries), MongoDB (no Mongoose) for the database, and deploy it to Heroku.

At the very start I knew I needed to keep it simple but to also ensure it could do the following:

Register a new user
Secure login/logout of registered users
Create new “contacts” (people you want to keep notes on)
Update and edit existing contacts
Delete contacts

Inevitably it was more complicated and took longer to complete than I had originally estimated, which was a valuable lesson in-and-of-itself. Of course, “art is never finished, only abandoned”, as Leonardo da Vinci said. So I recognize this as Version 1.0 with much room to improve.

Room for Improvement

As I got through the project I knew I was going to have to come back and refactor large portions of the code I was writing. To me this was good because I felt confident that I could recognize where there was room for improvement in the project, and in my own skills. By the end of the project I also had the feeling that I likely did many things in a more verbose way than was necessary simply because of a lack of experience and knowledge. Despite recognizing where there was room for improvement I kept on my originally defined path in order to keep Version 1.0 of the app from ballooning into something I couldn’t manage. Here are the things that came to mind while I was creating Version 1.0 that in another scenario I would have included without refactoring:

Writing unit and functional tests with Mocha/Chai (which I have experience with) and Jest (which I have not used)
Designing for mobile first
Better Git messages with consistent format and style (declarative subject line, then empty line, then paragraph describing details of commit)
Better Git branching (I only committed to Master)
Redux for easier state management between components
Sass CSS preprocessor and CSS modules so that the CSS is more manageable and scalable
Better database modeling (one to many model as opposed to large single documents, which would make it easier to update and delete subdocuments without making it much harder to create or read them)

Luckily Version 1.0 of this project is small enough that refactoring the above will not be unmanageable.

By the end of this milestone I was pushing hard to get to my desired minimum viable product goal. I could see the finish line I had set for myself and was eager to achieve this goal. When I did I felt amazing. Now I have to take a few days to decompress before reading more into React, database modeling, and other techniques that will help me build on this initial success for bigger and better things. I also plan on working on an open-source project I’ve been eyeing for a while now. I look forward to the new and unique challenge of familiarizing myself with a large, complex, and sophisticated code-base, with the goal of making serious contributions. This will be great for seeing how experienced professionals write better code in a large project. Until next time, code on.

How To Connect A React Front-End to an Express Back-End

Thu, 10 Jan 2019 00:00:00 GMT

After at least a week of repeatedly banging my head against a wall I have finally, successfully connected my React front-end to my Express back-end. After finishing the Free Code Camp curriculum in mid-December I felt ready to finally build the apps of my dreams. My motto is, and always has been, to dream big but start small. So I swiftly got to work on my first independent, full-stack web-application, called Digidex. It’s not currently completed but I’ve just made a large personal breakthrough by connecting the front-end to the back-end. This may not seem like a big deal to most people, and maybe it’s truly not a big deal, but to me this was a major point of success for me. As I learned web-development I could not wrap my head around how the whole front-end/back-end dynamic worked. That was until I got to the very last lessons in Free Code Camp. Doing those back-end lessons and projects in Free Code Camp really opened up to my eyes to the larger picture of web development and allowed me to image the infinite possibilities and how I could create them. But Free Code Camp still glossed over how to combine the whole picture into fully-functioning web-apps. By getting this far in my first app, Digidex, I now feel I understand this dynamic much better.

The Problem

Before this point I understood conceptually how front-end and back-ends work together, but not practically. My problem for many stressful hours was specifically how to do a redirect from Express with React. Free Code Camp never covered how to use a front-end framework like React with a back-end like Express. The examples that FCC used were with an Express back-end but a plain HTML front-end, or at most using Pug.js. Well I was set on using React, and I was interested in using React Router, which I had never used before. So I created the profile page for the authenticated user and the login page for authentication and for registration, all using React. Now the tricky part. How to use React Router to redirect from login page to profile page using my Express login API? I knew how to redirect from Express. But how was I supposed to use the Express redirect on the front-end with React Router? I worked on this for many hours, playing with React Router, reading tutorial snippets, and reading Router documentation. But I got nowhere. I eventually relented, abandoned React Router, and went with my backup plan- I would simply create two React apps (I figured I could always come back to React Router later). One app for the login page and another for the profile page. Express would send the user the login page on one route (with response.sendFile()) and then redirect to another Express route which would then serve the profile page.

Here’s what the Express routes looked like (link to GitHub Gist here):

Here’s what the file structure of the two React apps looked like:

Maddeningly, this didn’t work! Firing up the Express server I could see the login page render, and I could also see the profile page render on their respective Express routes. But when the login page hit the Express API for authentication, the Express redirect did nothing. Keep in mind that I only got this far after hours of frustration, trial and error, and many console.log ‘s. It was time to search the internet for the answer…

The Solution

My main line of attack was to search something like “express won’t send response after passport authentication redirect”. From my view it looked like Express was doing everything except actually sending the response.redirect('/profile') back to the client. It’s really at this point that I realize I don’t know what I don’t know. I can’t quite ask the right question because I don’t know the nature of the problem. I was just about to give-in and ask Stack Overflow when finally I find the nugget of knowledge that is the key to solving the problem at this Stack Overflow question.

Here’s a photo of the Stack Overflow comment that tipped me off:

I learned that React has to handle the redirect. The browser won’t get redirect from Express directly. This is a key fact! I could now combine the two React apps into a single, easier to maintain app, and go back to React Router, which I have done and am still working on.

Here’s the new file structure:

What I Learned

When I realized I didn’t know what I didn’t know I also realized I would have saved many hours of frustration if I had a manager or mentor whom I could simply ask for direction. Personally, I like learning the “hard way”, because you never forget what you learned when you learn this way. But learning on your own, without people to guide you and focus your energy, takes too much time and to me is not worth the tradeoff.

Completing Free Code Camp

Wed, 26 Dec 2018 00:00:00 GMT

On December 19th, 2018 I completed the freeCodeCamp (FCC) curriculum to earn their full stack certification. FCC estimates that this represents 1800 hours of coursework. The curriculum covers the full spectrum of web development basics and is a phenomenal way for new developers (like myself) to get into software development. In this post I’d like to briefly overview the curriculum, what I thought of it, and what I would have done differently.

Curriculum Overview and Commentary

The FCC curriculum covers six modules: Responsive web design, Javascript algorithms and data structures, front-end libraries, data visualization, APIs & microservices, information security & quality assurance. The structure of each module is to go through many small exercises to introduce concepts and practice implementing basic code. Each module then ends with five projects that challenge you to implement the concepts you had just practiced into real-world, working projects. As any good student will recognize, these projects are where you will learn the most as you struggle to make your ideas work without structured guidance. To me this part is vital to the learning process and is part of what makes FCC so valuable.

The curriculum starts with responsive web design, which includes the full range of HTML and CSS, CSS flexbox, CSS grid, and responsive web design principles. When I got started with FCC I had very little idea of where to start, but I at least knew that I wanted to build cool, functional things, not just static websites (although that’s cool too). So when FCC started with basic HTML and CSS I was slightly flustered and impatient. I especially struggled with translating lines of text into spatial-visual components. So if you’re struggling with this aspect of software development, you are not alone.

The second module is Javascript algorithms and data structures, which includes basic JS, ES6, regular expressions, debugging, data structures, algorithms, object oriented programming, and functional programming. This section includes 21 intermediate level algorithm challenges, which I really enjoyed doing and gave me confidence to keep pushing forward. The final projects were similar to the intermediate challenges in this section and were equally challenging and fun.

Then front end libraries, which includes Boostrap, jQuery, Sass, ReactJS, and Redux. With this section you get a taste of the more exotic tools of web development. It makes you feel much cooler and more capable with your web development skills. When doing the projects for this section I focused almost entirely on React when building the projects. I did this because many people I talked to recommended I focus on learning React since it is a popular new framework for front-end development. You can see in the Google Trends chart below that React has exploded in popularity in the past few years, passing jQuery in interest. It has been a joy to work with so far, although I can’t compare it to much else since I lack extensive personal experience at this point.

Red represents interest in React and blue represents interest in jQuery

Then data visualization, which focuses on D3JS, JSON, APIs and AJAX requests. This section is a great introduction to retrieving data from APIs using ajax requests. At first I couldn’t see myself ever using D3 for data visualization after FCC. It didn’t help that the documentation for D3 is not very strong. But after completing this section I am glad I know some basic data visualization techniques and the general structure of SVGs. I can easily see myself using D3 or other data visualization libraries in the near future to create cool data visualizations.

Then APIs and microservices, which includes the Node Package Manager, basic NodeJS, basic ExpressJS, MongoDB, and Mongoose. This section, and the next, really tied it all together for me. Up until this point I felt I had a gaping whole in my understanding of how web applications, and the web in general, worked. By learning to setup a basic server, a basic database, and API endpoints, I could finally see the whole picture of how modern web applications work.

Finally, information security and quality assurance, which includes HelmetJS, basic web security, hashing with bcrypt, unit and functional testing with Chai and Mocha, and advanced NodeJS, ExpressJS, MongoDB, and Mongoose. Finishing this section and its associated projects was the most fulfilling of all the modules because it brought together a lot of the FCC curriculum into several challenging web application projects that closely resemble real-world applications. For example, the last project, and for me the hardest, was to build an anonymous message board, similar to Reddit. Just a few weeks ago I would have been discouraged thinking about how to go about building a Reddit-like application, or even anything approaching the seemingly large complexity of something like Reddit. I can’t be too hard on my past self because I had no database experience at that point. But now I can at least approach the mental challenges of thinking “well, how would I go about building this project I have in-mind?“.

FCC estimates all of this to represent 1800 hours of coursework. I did not keep track of how many hours I worked on each section or on the entire ceritication, but I doubt it took 1800 hours. I started FCC at the end of July and finished by mid-December. Even if I had worked 10 hours per day for approximately 144 days it would total 1,440 hours. But I certainly did not work 10 hours per day for 144 days. In the case of the first few certifications I was working a demanding full-time job while completing these certifications, so my time spent on FCC was spread out over many weeks with only a few hours or less per day. After I quit my job I was focused almost entirely on FCC and coding, which shows in my completion timeline. I got the first certification on Sept 30 (63 days), then the second on Oct 16 (16 days), the third on Nov 24 (37 days), the fourth on Dec 4 (34 days), the fifth on Dec 10 (7 days), and the last on Dec 19 (10 days). That’s a total of 144 days. In the first 75 days or so I was working full-time as a banker, with only a few hours each day to work on FCC. After mid-Oct I was almost working full-time on FCC for about 70 days. If I was working about 3 hours a day, on average, for 75 days, then for about 7 hours per day, on average, for 70 days, I would estimate I spent 715 hours total to complete FCC. The work got easier over time as I learned and retained more, which I suspect happens to anyone working through FCC and anyone learning a new skill.

What I Would Have Done Differently

If I could go back to the beginning and do it all again I would have focused like a laser on FCC and nothing else. I got distracted with side projects while completing the curriculum. It was not at all bad for me to take time away from FCC to work on side projects. In fact, I learned a lot from doing mini, self-assigned work in-between FCC modules. But it was not as efficient as if I had focused on FCC all the way through to the end. This was because I would finish a section in FCC, feel confident that I knew the material, then attempt something that was too far beyond my reach at that point. I would then struggle for an unnecessarily long amount of time before completing the project or putting it aside and then returning to FCC.

Now that FCC is completed I can look back and realize that the struggles and frustration I felt when doing those side projects were covered in later FCC material. I would have saved a lot of time and frustration by trusting FCC instead of looking for more challenges.

Conclusion

Overall I would highly recommend that anyone looking to become a software developer get started with FCC and stick with it until the end. At that point you will have great confidence in your ability to code up a project on your own and in your ability to learn new skills and expand your capabilities. Now get coding!

You can find my FCC certifications here or see my code for the associated FCC projects here. You can also return to the homepage of my personal website here to see a list of links to the FCC projects.

How to Remove All Distractions and Code Full-Time

Mon, 26 Nov 2018 00:00:00 GMT

I’m living the island life. Not the Hawaiian Island life. The Santa Catalina Island life. Catalina Island is an island off the coast of southern California. It is about 22 miles long and 8 miles wide at its widest point. It has only one official city, Avalon, with a population of about 3,500. Avalon is a somewhat popular spot for mainlanders to go on a weekend get-away. Otherwise there’s not much else on the island. The only other population center on the island to speak of is Two Harbors, with an approximate population of about 150 people.

Two Harbors, that small town in the distance, is where I currently live and study. In a previous post I described how I quit my job as a banker to learn to code. Obviously many people won’t have the option of quitting their job to code full-time, but if you can then it’s a huge advantage. One of the biggest, most overlooked advantages, is the ability to focus on a single thing. It’s actually not all that hard to come home after work and start coding, assuming you have the right mindset and you don’t have other responsibilities like a spouse, kids, or even pets. But even in that ideal scenario you have to split your energy and focus on your day job and your coding. Inevitably thoughts from your day job bleed into your afterwork thoughts of coding. You’re sitting there trying to do nothing but focus on code and all of a sudden you’re thinking about the way your boss said something to a co-worker. It’s just not possible to make a distinct cutoff between work and code after 5PM. Not to mention all the other distractions that come at you: you need to get gas, pay the bills, get groceries, settle an issue with your roommates, get some exercise, see your friends, call you parents, and on and on. This obviously was my reality until recently. The way I solved this problem was to literally move to a remote island.

Frankly I like the quiet isolation of the island. There is so much less to worry about, leaving so much more time for coding, reading, and writing. Not to mention I’m on an island which is quite beautiful, as you can tell by the photos.

There are always distractions, no matter where you are or what you’re doing. But an effective strategy for combating these distractions is to simply get rid of them or make them more difficult for you to access. For example, if you live in New York City with all your best friends it’s going be very difficult to choose to sit in a room quietly by yourself learning to code over going out with your friends. But if you’re a bit further away, physically, from your friends and fun times, then it becomes just a bit easier to decide between distraction and coding. You can take that attitude as far as you can by simply removing certain activities from your life that are unnecessary, even if it’s temporary. For example, maybe you think you watch too much television. You could simply unplug the TV and move it into the garage. You can still watch TV whenever you want to, but you’ve made it a bit more difficult for yourself. If you wanted to watch TV it’s no longer a single step of turning it on, but at least a three step process of lugging it out of the garage, setting it up, and then turning it on. This is a simplified example but this kind of thinking is a very effective way of getting back more time and energy to focus on your coding.

I’ve practiced this all throughout my life and it has given me a huge advantage over my own inclinations to procrastinate. And the good news is that this attitude and focus on what you should be doing gets easier over time as you practice it. Today I’m on an island that I can get off of any day I want. I just have to get on a boat for 90 minutes and accept some sea sickness to get to the mainland and the world of endless distraction. It would be so much easier and more fulfilling though to stay on the island and code. Which is what I plan on doing until I accomplish my goal of becoming a professional software developer. For me, the only real way off the island is success.

How I Decided to Quit My Job as a Banker and Learn to Code

Mon, 12 Nov 2018 00:00:00 GMT

In 2014 I graduated from Whitman College with a degree in economics and was off into the real world. Like many graduates, I didn’t know exactly what to do, but I had confidence that if I just tackled things one day at a time then I’d figure it out eventually. Luckily I ran cross country and track all through high school and college so even at the age of 22 I was pretty good at setting goals and working diligently towards them. One goal that was always in-mind after graduation was to figure out what I wanted to do. I knew from observation and from talking to my peers and my parents that many people graduate undergrad college without having an ideal job they wanted, let alone a “passion” to pursue. So what would end-up happening to these folks is that they get a job that relates to their undergraduate major and would work in that industry for the rest of their lives, without having really conciously chosen it. I knew I didn’t want that for myself. I always followed the Steve Jobs ethos of “Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven’t found it yet, keep looking. Don’t settle. As with all matters of the heart, you’ll know when you find it”. So my primary goal upon graduating was to find out where to focus my time and energy. If I had to pick an industry or field to focus on for the rest of my life then I’d better chose carefully.

After graduation I worked a wide array of jobs in many different fields. I worked at a call center, worked at a running shoe store, drove for Uber, worked at a cleaning company, worked for a real estate developer, went door to door for a presidential campaign, worked at a commercial real estate mortgage broker, worked at a private equity firm, and most recently worked as a banker. That’s a count of nine jobs in four years. These jobs are almost entirely unrelated. Most people would look at my resume and think I was crazy, fickle, or afraid of commitment. To me this criticism doesn’t really matter. It makes total sense that any young person would go through at least 10 discrete jobs before finding the right path. What does matter is that with every job I obtained valuable skills in accounting, communication, business, sales, writing, reading, discipline, orgnization, prioritization, etc. I always knew that I could learn in any situation and that these sorts of skills would pay great dividends down the road. Thus, it was never a waste of time to work in career paths or jobs that I eventually would quit, as I’m sure many people would see this type of situation.

Well it was in late 2017 that I read How to Create a Mind by Ray Kurzweil and had my mind blown. In this book Kurzweil goes into the technical details of how the human brain works and how software can be used to create artificial intelligence. Reading this book made me realize the absolutely world-changing and still largely-untapped potential for software. It was right then that I decided I had to learn how to code and commit myself 100% to this field.

In a nutshell that’s how I came to decide to learn to code. To me, finding out what you want to do is the hard part. The easy part is doing it. So at this point in late 2017 I’ve made a decision. Now how to get to my goal of being a professional software developer? Without doing too much research I jumped in. I started with Free Code Camp, learning HTML and CSS. Well I got bored of that rather quick. So I saught out something harder and more computer-science-ie. I started learning Python with a great book called Automate the Boring Stuff by Zeiwag. I fell in love. It’s a great book to learn to code that I highly recommend for beginners. I committed myself to learning to code on nights and weekends outside of my day job as a banker, so it was great to have a book to guide me and give me projects to work on. But eventually I finished the book and completed all the projects. At that point I hit a major wall. My workload at the bank was ramping up and I didn’t know how to progress further, especially with limited time and energy after work. As many beginners realize, once you finish the basic guided tutorials the only way to progress further is to build your own projects. Well that takes a lot of energy, especially as a beginner. And I didn’t have enough hours in the day to do well at my day-job and to keep learning to code. So for a few months I stalled. I didn’t know how I was going to reach my goal of becoming a professional developer. So I tried to find an intermediate step from where I was to where I wanted to be. I did all sorts of research on jobs at tech companies that I would quality for. Jobs like product manager or financial analyst. I figured it would be much easier to prove myself in a tech company with my existing skill-set and then make a lateral move into software development within that same company. I was working on that idea for several months when I talked to a friend of a friend who was looking for newer software developers who were willing to get paid below-market rates. Boom! That’s me. I was all in for this and I saw my opening. I sold myself to this guy and asked what I needed to learn to get the position. He told me to focus on JavaScript and ReactJS, and that we could have an interview in a few weeks. This jolted me into action. I immediately started JavaScript and ReactJS tutorials on Codecademy. I finished them all, even the premium content. I didn’t think I was ready for an interview but I figured I could sell myself on my discipline, tenacity, and work ethic. I may not have known JavaScript and ReactJS all that well but I would in a matter of time. I could guarantee that. Well for various reasons that interview never came. But I had newfound hope. One of my problems when I started was that I didn’t know what kind of development I wanted to do. What would be appropriate for a beginner like me to aim for? Should I keep learning Python? What was the most realistic path from beginner to professional? I talked to friends who were developers, friends who were data scientists, friends who were product managers and tech entrepreneurs, and even tech recruiters. While they all gave me valuable information, none of them could really say definitively how I could accomplish my goal of becoming a professional software developer. I finally came back around to Free Code Camp. I was listening to a Free Code Camp podcast with Quincy Larson when he explained why Free Code Camp focused on JavaScript and web development. I was already starting to think that web development was the best way for beginning developers to get started. So when Quincy eloquently and confidently explained that Free Code Camp focused on web development because web developers are in high demand and JavaScript keeps growing in popularity and usability I was sold. I also realized on a practical level that with web development I could build my own cool websites and web apps that would be easy to host and for other people to actually use. I could never quite see how I could use Python to build anything other than small scripts that would be difficult to share. So my motivation to learn HTML, CSS, and JavaScript was really high. I still had a large workload at my day job as a banker. I didn’t want to sacrifice the quality of my work at my day-job, so I frequently stayed late at work and put a lot of energy into making sure I did a good job. I did well enough to get promoted into a sales position with even more responsibility, even as I had my eye on the door. This was a great confidence boost to me, but it meant even less time and energy could be used to code. So I needed to find an alternate route. I just didn’t have the time to build the projects I knew would get me to my goal. It’s at this point that I realize I’ve saved a decent amount of cash and that my brother was living on nearby Catalina Island. After doing the math and putting a lot of thought into it, I decided to quit my job, move-in with my brother on a remote island, live super cheap, live off my savings, and code full-time.

So here I am. I currently live in a small town on a small island with nothing to do but code. I’ve completed the Free Code Camp Resposive Web Design certification, Javascript Algorithms and Data Structures certification, the Front End Libraries certification, and soon I will complete the rest of the Free Code Camp curriculum. I’ve also completed dozens of CodeWars challenges in Python and JavaScript, I’ve at least begun a few exciting side-projects. And I’m overall extremely happy with my decision to quit my job as a banker and learn to code. Stay tuned for more advice and hopefully more technical posts on this blog.

Feel free to reach out to me or to checkout my work at my personal website. I look forward to connecting with you. Code on!