NCZOnline Sign Up Information

What I''m thinking about: WebAssembly

Of all the JavaScript-related technologies that have popped up in the past few years, WebAssembly is still the one that seems to confuse people the most. I get asked fairly frequently, "should I learn WebAssembly?" The answer to this question isn''t a simple "yes" or "no" because people often aren''t clear on what it means to "learn WebAssembly." Confused yet? Let me try to clear things up.

The best description of WebAssembly comes directly from the website:

WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications.

The most important part of that description is the phrase "compilation target," which means you''ll ship WebAssembly as the last part of your process, not the first part. As a compilation target, WebAssembly isn''t intended to be hand-written, and so you will never have to learn to write WebAssembly.You might write your code in Rust, or Go, or TypeScript, and maybe one day pure JavaScript, but you are unlikely to ever have to write WebAssembly by hand.

What else is important to know about WebAssembly? It''s designed to have predictable performance. JavaScript performance can vary wildly depending on how you write your code, and therefore, which optimizations the JavaScript engine ends up applying. WebAssembly is designed so all optimizations available inside the JavaScript engine will be applied. That means that the fastest JavaScript has the same performance as WebAssembly, but again, it''s hard to please the JavaScript engine with hand-written JavaScript. For that reason, where performance is important (such as in games), WebAssembly makes a lot more sense than JavaScript.

So should you learn WebAssembly? The answer is yes. You should understand what WebAssembly is and that it can be a better option than JavaScript for performance-intensive applications. You should know that type-safe languages can be compiled to WebAssembly and used in web browsers and Node.js. And most of all, you should be aware that at some point in your career, you''ll likely end up using WebAssembly as part of building a web application.

What I''m reading

This past month, I read three books:

• How Fascism Works by Jason Stanley. You might not have noticed that today is election day in the United States. With all of the upheaval and discussions around what is normal and what is not, this book steps in to talk through the history of fascism in the world and the tricks that leaders use to establish and maintain power. The main goal of fascism is to divide a civilization into "us" and "them," and this book lays out exactly how that is accomplished and what to do to stop it.
• The Hands-Off Investor by Brian Burke. If you''ve been following me for a while, you know I''ve been researching real estate investing for most of the past year. This book explains a different way to invest in real estate: through syndications. Syndications are basically partnerships where a bunch of people pool their money to invest in a property that is larger than they could invest in on their own. A warning: this book is very dry with lots of numbers as it explains how to properly research a syndication to make sure that it''s not a scam and actually a good deal. Probably only interesting to people already considering such an investment.
• Negotiating the Impossible by Deepak Malhotra. This was my favorite book this month. As you might have guessed from the title, the book is all about negotiation, and specifically, negotiating difficult situations. This book isn''t just a list of rules to remember, though, it''s also an examination of situations where negotiations worked (or didn''t) in real-life, high-stakes situations. Why did President Kennedy decide against attacking during the Cuban Missile Crisis despite most of his advisors telling him to do so? This is a fascinating story that the book goes into and really helps hammer home the fine art of negotiation. If you''re interested in improving your negotiation skills, I highly recommend this book.

What I''m working on

This month I did a little bit of exploration around Google Cloud Run and TypeScript:

• Hello Node.js Service - a simple Node.js web application designed specifically to work on Google Cloud Run. Because Cloud Run natively supports Node.js, you don''t even need a Dockerfile to run a Node.js application. This is really just intended to be a sample you can use to check that your settings are correct.
• Hello Deno Service - the same as the Node.js service except written in Deno. Google Cloud Run doesn''t natively support Deno, so I had to create my own Dockerfile. Still, the setup is fairly simple and I now have a sample Deno application that works on Cloud Run.
• Create TypeScript declarations from JavaScript and JSDoc - while playing around with TypeScript, I discovered that it''s possible to generate .d.ts files directly from JavaScript so long as the JavaScript has JSDoc comments providing the additional type information. This little snippet shows you how to set that up.

Also, I''m just two sponsors away from releasing part 5 of my Creating JavaScript promises from scratch blog post series. As a reminder, I''m releasing a new post for every 5 additional sponsors I''ve received since part 4 was released. So far I''ve released four posts:

• Part 1: Constructor
• Part 2: Resolving to a promise
• Part 3: then(), catch(), and finally()
• Part 4: Promise.resolve() and Promise.reject()

The next post will cover Promise.race() and Promise.any(). So if you''ve enjoyed this series so far and you''d like to see it continue, please consider sponsoring me on GitHub.

Jobs

Fullstack Python/Angular/AWS Developer (Fund Cogito, Remote)

About you: You're familiar with Angular and Python, maybe even Django, and have worked with systems built on AWS. You are security-minded, organized, and patient with your colleagues. You're excited about guiding a small company to the next level and you're interested to learn how foundations, endowments and family offices make sense of the $B investments they manage across asset classes. Learn more.

Fullstack Senior Engineer (Okay, Remote)

About you: You''re familiar with Node.js, Vue, TypeScript, DBT, Postgres, Kubernetes, GCP services and/or Figma to solve problems across the stack. You thoughtfully balance product velocity with best practices for engineering, security and design. You are excited about joining as a founding (second) engineer to help make the lives of engineering teams more productive and happy with a customer-first approach. Learn more.

Have a full-stack or front-end job you''d like to post on the newsletter? Reply to this email for more information.

Questions? Comments?

You can reply directly to this email to let me know what you thought of this newsletter or if you have ideas for future newsletters.

What I''m thinking about: Imposter Syndrome

Last month, I had a phone call with a former colleague. We were talking about what they were up to at work when they used a technical term I didn''t know. It was clear from the context that they expected I knew what it meant, but I didn''t. At that point, I was faced with a decision: do I stop and ask what the term means (and thus put my ignorance on display) or keep quiet and hope that the term wasn''t actually important to the overall discussion? What would you do?

While I was wish I could claim the mature, high ground in this situation, I cannot. I kept quiet, and luckily for me (and my ego) the term was not important to the rest of the conversation.

What I went through is what many call imposter syndrome. This is often described as the fear that someone will "find out" about you, that you''re not as good, as smart, or as competent as you somehow managed to convince them you are. If you read the beginning of this newsletter and thought, "wow, I can''t believe Nicholas ever feels like an imposter," then I''ve got news for you: I feel like an imposter frequently. Why?

Quite simply, it''s because there''s a lot that I just don''t know or understand. I''ve been in and around the software industry for over 20 years and there''s never a shortage of things to learn. There''s just no way I can ever know anything, and that necessarily means a gap in my knowledge that can make me feel "less than" in conversations about that gap. I''ve focused primarily on front-end engineering, and to be as good as I am in that, I needed to focus on those technologies and techniques and let everything else fade into the background. That''s a choice I made, and it''s a choice many software engineers make as their careers progress: you can''t know everything, but knowing something deeply often gets you further than knowing a little bit about everything.

I wish I could tell you that there''s some enlightened state that you''ll eventually reach once you''ve had X years in the industry, but in reality, there is no such state. Every competent, reasonably self-aware software engineer will experience imposter syndrome from time to time. You''ll be faced with the same choice I had in that conversation with a former colleague: do I speak up and acknowledge the gap in my understanding, or do I keep quiet and hope it''s not important? Realistically, both options are reasonable and you shouldn''t feel embarrassed about choosing either. The most important thing to understand is that not knowing something isn''t a character flaw to be ashamed of. If you had no reason to learn something in the past, then there''s no reason you should know it now. Not knowing or understanding something is a temporary state that you can address if necessary, and the best software engineer you know doesn''t know about something. Be kind to yourself.

What I''m reading

This past month, I read three books:

• Salt, Fat, Acid, Heat by Samin Nosrat. This one has been sitting on my end table for a while, and it''s pretty great. This is the first book I''ve read that explained, in fine detail, how cooking actually works. The author explains why salted your food is different than using other spices, how heat causes certain chemical reactions, and how water can affect your food in a variety of ways. There are recipes in the second half of the book, but to me, the real gold is the explaining of why cooking techniques have the effects that they do. As someone who must prepare each of his own meals due to dietary restrictions, this book opened up a world of possibilities for me.
• A Fine Mess by T. R. Reid. This book is about taxation: how it started, how it evolved, and where we are today. The author explores the various tax systems around the world and compares them to the U.S. tax system, which is a complete mess. This book piqued my interest due to all of the discussion around taxes in the past year in the U.S., as we expect new tax laws with the new president. This book explains why and how our tax code got so messy and how tax reform has been accomplished multiple times in the past. I found this to be a fascinating take on something I just don''t know that much about.
• Designing Data-Intensive Applications by Martin Kleppman. This book is not for the faint of heart! It contains just a mountain of information about every type of data storage and transportation mechanism on the planet. This is probably not a book that you''ll read from start to finish, as it''s incredibly dense and moves quickly from one complex topic to another, but it is definitely a good book to have as a reference. The author describes everything about databases, from how relational and NoSQL databases work, how partitions and indexes are created, how today''s cloud-bases databases scale, replicate, and error-correct...you name it. The level of detail is such that you might not ever need to know what''s contained in this book unless you end up designing your own distributed database.

What I''m working on

This month I did a little bit of exploration around Google Cloud Run and TypeScript:

• Env - I released a new version of this little utility that is designed to make reading environment variables safer. This version included embedding type information in the package to work better with Deno.
• ESLint Config Compatibility - I''ve been spending a bunch of time working on the config system for ESLint. I just finished up a compatibility layer that will allow the new config system to consume configs defined using the old config system. This is an important step in the process as it will allow us to start experimenting with the new config system without needing all configs to be in the new format.

Also, I''m working on finishing up my "Creating JavaScript promises from scratch" blog post series. I reached my goal of 45 sponsors, so all seven parts will be released. Here are the posts so far and what''s coming up next:

• Part 1: Constructor
• Part 2: Resolving to a promise
• Part 3: then(), catch(), and finally()
• Part 4: Promise.resolve() and Promise.reject()
• Part 5: Promise.race() and Promise.all()
• Part 6: Promise.all() and Promise.allSettled() (coming soon)
• Part 7: Unhandled rejection handling (coming soon)

This series is brought to you by my sponsors, so if you''ve enjoyed this series so far, please consider sponsoring me on GitHub.

Jobs

Staff Software Engineer, UI Platform (Rubrik, Remote/US, Palo Alto)

About you: You''re familiar with Webpack, GraphQL, Typescript, and React, and have experience building customer-facing web applications. You''re excited about working on problems that will enable hundreds of full-stack engineers to build beautiful, intuitive, and fast applications. Your impact will be through improving our UI tooling (builds, testing, observability) and building frameworks and reusable components to improve UX consistency and developer experience. Learn more.

Have a full-stack or front-end job you''d like to post on the newsletter? Reply to this email for more information.

Questions? Comments?

You can reply directly to this email to let me know what you thought of this newsletter or if you have ideas for future newsletters.

What I''m thinking about: Fault Tolerance

One of my favorite things in the world is painters tape (also called masking tape). It seems like something silly: some tape you put on a wall when you''re painting to avoid getting paint on the wall. The tape doesn''t have a strong adhesive, so it can be pulled back off the wall without damaging it. What I love about painters tape is the philosophy behind it: painting is messy, and rather than trying to avoid making a mess, painters tape allows you to make a mess initially and then clean it up easily. Even the best, most talented painter is going to splatter some paint here and there, get distracted, or otherwise end up with paint going where it shouldn''t. It''s a lot faster, easier, and less frustrating to use painters tape to cover up areas where paint is likely to go and then remove the tape to create a nice, clean, finished area. What does this have to do with software engineering?

Painters tape is all about a concept called fault tolerance. Instead of expecting everything to go well, you instead expect that there will be mistakes. When you expect there to be mistakes, you made decisions not to avoid all mistakes but rather to easily recover when a mistake occurs. Got paint where it shouldn''t be? It doesn''t matter if that spot was covered by painters tape. Forgot to put on the painters tape? Now that mistake is a bigger deal. As software engineers, we can think the same way with the code we write.

Making your code fault tolerant is about asking yourself the question: how will this fail? Not if it will fail, but assuming that it will fail, in which ways will it fail? Can someone accidentally pass null where a number was expected? Is there a calculation made with a lot of variables where any invalid input will result in an indecipherable error message? Is the code depending on an external dependency (such as a web service) that might not be there? How many ways can you imagine a problem occurring that you''ll need to recognize and recover from quickly?

Thinking in about fault tolerance is a different way of thinking about the code you''re working on, and as such, it can be difficult at first to make that switch. A good first step is to look over your unit and integration tests for gaps. You should have tests that cause your code to fail catastrophically and be able to identify which the exact problem by the error that is thrown or logged. In that case, you''re ensuring that you can correctly identify the cause of an error. Sometimes, you''ll be able to recover from the error by silently using some kind of fallback. You should also have tests for that case. Your tests are the first line of defense against unexpected problems, so make sure you include tests that break your code in a variety of ways.

If you''re dealing with a distributed system, it''s even more important for you to think about fault tolerance. The very idea of cloud-based architecture is that your virtual machines and containers may disappear suddenly, and the system should be able to continue working. This is actually one of my favorite things about today''s cloud-based applications: by setting the expectation that your resources may not be available, it''s forcing everyone to think about fault tolerance from the beginning.

As we start 2021, I''d suggest an additional new year''s resolution: start to think more about the ways your code will fail, and how you can be notified of those failures and recover quickly from them. Your manager and your teammates will thank you, and you''ll be well on your way to that next promotion.

What I''m reading

This past month, I read three books:

• The 80/20 Principle by Richard Koch. If you''ve never heard of the 80/20 principle, I can sum it up as this: 80% of some output comes from 20% of some input. For instance, 80% of your bugs likely comes from 20% of your code. While the numbers might not measure out exactly, it is a well-known occurrence that there is generally an asymmetric relationship between outputs and inputs, and by accepting that, you can optimize your time and energy to its best use. This book explores the 80/20 principle and how it applies in various situations. Honestly, it gets a bit redundant after the first couple of chapters, because once you understand the relationship between inputs and outputs, it''s fairly easy to apply the principle to any situation. Still, I recommend this book because understanding the 80/20 principle is important for any software engineer.
• Traction by Geno Wickman. A lot of entrepreneurs get stuck in their business because they end up doing absolutely every part of what the business requires. The approach discussed in this book, called EOS (for Entrepreneur Operating System) shows you how to start delegating tasks so you can focus on the parts of the business that you''re best at. If you run or are thinking of starting a small business, this book is for you.
• Getting the Money by Susan Lassiter-Lyons. This book was recommended to me by someone who''s helping me get started with real estate investing. There are only so many properties you can buy with your own money (unless you''re independently wealthy) and the next step is to start getting people to invest in your real estate business. This book walks through the process of finding, pitching, and closing investors. Before this book I thought, "oh, it''s probably just about asking a friend or family member to borrow some money," but there''s so much more to it than that. The approach discussed in the book is probably useful for raising money for anything (if you ignore the real estate-specific pieces).

What I''m watching

I''ve become a big fan of YouTube videos in 2020, and here are a few that I''ve really enjoyed in the past month:

• Building Small Containers by Google Cloud Platform. A short video on how to make your Docker containers smaller and therefore more secure. Very helpful and not as Kubernetes-specific as the title card makes it appear to be.
• Golang in 7 Hours by Free Code Camp. Definitely not a short video that is an introduction to the Go programming language. I had a personal goal to learn a new programming language and chose Go to be that language. This is a great overview.
• "Good Enough" Architecture by GOTO Conferences. Are you focusing too much or too little on architecture? This talk explores how architecture fits into our everyday lives as developers and how to deal with.

What I''m working on

This month I was excited to launch my new Human Who Codes Money blog! If you''re a longtime reader of my newsletter, you know I''ve been looking more into investing, especially into real estate investing. I''ve spent the past year reading, listening to podcasts, and watching videos about real estate investing and managing my money better. Just as I do with tech-related things, I intend to document everything I''ve learned to share with others. My first blog post is entitled, Why I decided to start investing in real estate in 2020, and here''s a preview:

A lot of people were surprised when I suddenly announced at the end of 2020 that I was under contract to buy my first rental property. To some, this was completely out of character. Why would a software engineer who often spent his free time working on open source projects and writing books suddenly up and decide to buy a rental property in the middle of a pandemic? Well, it wasn''t as sudden as you might expect.

Also, I''m working on finishing up my "Creating JavaScript promises from scratch" blog post series. I reached my goal of 45 sponsors, so all seven parts will be released. Here are the posts so far and what''s coming up next:

• Part 1: Constructor
• Part 2: Resolving to a promise
• Part 3: then(), catch(), and finally()
• Part 4: Promise.resolve() and Promise.reject()
• Part 5: Promise.race() and Promise.all()
• Part 6: Promise.all() and Promise.allSettled()
• Part 7: Unhandled rejection handling (coming soon)

This series is brought to you by my sponsors, so if you''ve enjoyed this series so far, please consider sponsoring me on GitHub.

Jobs

No jobs to share this month. :(

Have a full-stack or front-end job you''d like to post on the newsletter? Reply to this email for more information.

Questions? Comments?

You can reply directly to this email to let me know what you thought of this newsletter or if you have ideas for future newsletters.