DEV Community: Nik F P

I moved to Neovim and love it, but is it right for you?

Nik F P — Fri, 06 Jan 2023 16:37:11 +0000

Let me start out by clarifying a few things so that you have a better understanding of the point of this post.

First, this won't be a sales pitch trying to get more people on the "Vim" bandwagon. I honestly don't think it's the right tool for everyone. I do think you should try it if you haven't, but I'm biased because I like it. In the end, a code editor is designed to edit code, and Vim is one of many tools that can edit code effectively. If you already have a fast and efficient workflow with another editor and you are happy with it, this post might not be helpful to you. (but you still might find it informative!) If you are curious about Vim or you feel that your current editor experience is lacking, read on.

Second, keep in mind that learning a new tool to do something you already know how to do is a chore. If you decide to try it, it will take some time to get comfortable, and it will take some time to gain proficiency. You will move slower at first, you will have greater mental overhead during the adjustment period, and you may be frustrated often. So if you do feel inspired to try Vim, or any other new tool, give it enough time to say you gave it a fair shot. And make sure your comparison is fair. If you are using VS Code for example, and if you haven't looked through all the menus and done at least a cursory read-through of the documentation, I think you should. You could be missing features that could change your whole workflow for the better.

What I would like to do here is tell you about the drivers behind my decision to try Vim in the first place, why I decided on Neovim vs Vim, and how my experience has been so far. I won't go into the "how to", but I'll provide some links later on that can help you if you are interested. The goal I have in mind is to help people make an informed decision on whether or not to try it. Nothing more, nothing less. I want to maintain a level head and provide some honesty to cut through the noise. I hope you find my experience helpful.

The Back Story - Why look at Vim in the first place?

My first real coding experience was in Visual Basic for Applications, writing custom logic for an MS Access program. I soon realized that VBA wasn't the language I was going to stick with and I wanted to learn a common enterprise language, and C# appeared to be the best bet. So I downloaded Visual Studio Community Edition, bought a Udemy course on C# and got to work. (Thanks Mosh Hamedani btw, awesome teacher!) I enjoyed the language but struggled with the IDE. Visual Studio is a BIG program, with a lot of deep integrations. It turns out, many of those integrations are just Gui skin over command line tools anyway, so I started using the CLI more to do things like run, build, add dependencies, etc.

This worked well enough for a while, but I always felt that Visual Studio was just too big. Load times were long, and it was heavy on system resources. And Visual Studio Code was on the scene by this point with extensions coming up everywhere. It looked like I could get the bulk of the functionality I used in a lighter package with quicker startup times. So I made the jump.

As time marched on, I started to get more confident and I was having a blast creating, but I hit my next stumbling block. I started to experience friction between thinking of the code I wanted to write and getting it into the editor. Refactoring and generally moving around seemed harder than they should be. I was turning my hands into crab shapes to hit Ctrl+Shift+whatever-else to use shortcuts. And I'm not a full time developer, so it takes longer to develop muscle memory on things like shortcuts just because I don't use them as much. Also, I take the chances I can get to write some code. If I hit the button to start an editor and it takes a minute or two for startup and for the language services to initialize, it bugs me, and VS Code was doing this to me. It was also still more resource heavy than I like with a half a gig of RAM usage and multiple processes hitting the CPU.

I'm not the fastest typist but I am a touch typist. Coding speed wasn't the issue, but in a flow state I found it very annoying to have to stop and try to remember a keyboard shortcut or dig back in to the shortcuts editor to find it again, or wait for some unexplained lag to stop happening so things would work. Reaching for the Ctrl, Alt, and Shift keys in strange combos with other keys just felt uncomfortable. My excitement for coding was being tempered by a growing feeling of "Is this the best I can do?" when thinking about using the editor.

I knew there had to be a better way, but I didn't know where to start. Most code editors with advanced features have similar outlooks on keybindings, and are often heavy on resources. I looked into Jetbrains products, looked briefly at Emacs, read up on Sublime a bit, and wasn't thrilled with any of them. (Though they are all great, just not for me.) And then I saw a thumbnail for a Youtube video on "Your first VimRC" and watched it over a lunch break. And I thought, "This does look different. Why not try it?"

A Brief primer on the Vim way, and Vim vs Neovim.

The first thing you need to know is that Vim is a modal editor. This means you have different modes for doing different things. Normal mode is for moving around, insert mode is for actually writing text into the editor, visual mode is for selecting words, lines, and blocks and manipulating them, and command mode is for issuing commands to Vim to do anything from searching for something to quitting the program.

The next thing you need to know is that Normal and Visual modes both depend on something called motions, which is how you move around the editor screen. Vim is designed to be used without a mouse and the motions are how this is done. There is also a huge variety of other things available, including forward and backward search, keys to scroll up and down, and so on. Vim aims to follow the Unix ethos of doing one thing and doing it well, and it's great at being text editor.

The last important thing to know is that Vim and Neovim use the same motions and actually share a lot of the same source code. Neovim is a fork of Vim and the two teams are on good terms and work together on many things. The casual user can use the same base installation of either one interchangeably. The key difference is that Vim uses a special language called VimScript as the primary extension and configuration language, whereas Neovim uses Lua. Neovim can read most VimScript as long as it doesn't use the most current features. However Neovim has embraced Lua and a full API layer from the core program that interfaces with Lua, and as a result the ecosystem for plugins has exploded with Lua development. Vim in contrast is now using a newer version of Vimscript that Neovim doesn't fully support. The result is that plugins for one won't always work on the other.

Not all babies are pretty!

When you first open a raw, unconfigured instance of Vim or Neovim, it's ..... kinda ugly. The colors are pretty harsh and there isn't much in the way of visual niceties that you might be used to seeing. I started with Vim because it was already installed and I just wanted to try it. So I fired up the included interactive tutor and started working through it. Pretty quickly I had the basics of just moving around, albeit slowly and with some thought involved. Then it was on to the included manual. There is a lot of great information that comes with the base installation and I enjoyed getting familiar with it.

Once I realized I was enjoying myself, I looked at how to start customizing things.... and hit a wall. VimScript just isn't intuitive to me. But I had already heard that Neovim used Lua, so I installed Neovim and started playing around with it, and it felt like a better fit. I knew that learning Lua would have a payoff beyond Vim as well. (A lot of common tools use Lua as a scripting language, such as Redis, HAProxy, and MySql workbench)

The first thing customizers usually do is install a package manager, and I was no exception. Then I installed a color theme, restarted the program, and things looked better right away. And I had my first config! It was only about a half dozen lines that just changed the theme, but it was a start!

Let's make VS Code in a terminal text editor!

This was my first direction. It turned out to be a mistake. I tried to copy (more or less) the experience I was used to with VS Code into a Neovim configuration.

Now, to be clear, there are "distributions" of Neovim configurations that will get you really close to a VS Code style experience by using pre-made and well-maintained configs and plugin arrangements and handling a lot of the complexity I'll get into later. These are great options if that is what you are after and you want an out-of-the-box experience. I wasn't aware of them at the time though, so I just tried to make a VSClone myself. Also, knowing what I know now, I would choose to go another direction anyway.

The way plugins work in Neovim is that you have a package manager that links to the location of a plugin and pulls the code into your local file structure if necessary. Plugins can be local directories or Github repo's of the code for the plugin. You include the plugin path in a table in a Lua file, run a command, and the package manager will download the code if needed and make sure Neovim knows where to find it. In some cases this is enough for it to work, but most of the time you still have to set up and configure the plugin so Neovim can use it. And most plugins have decent documentation on how to do that, complete with code examples in Lua. So I started adding plugins and setup code without really knowing what I was doing. (Copy / Paste are not always your friend!) I got some things working, but it quickly turned into a mess that I couldn't fully understand. Some plugins were overwriting configs for others, keymaps were everywhere, and it was ugly.

Out of frustration, I deleted it all and started again. But I learned an important lesson, and this is probably the biggest takeaway from this post. If I was happy with my coding experience in VS Code, why was I looking at other options? And why was I trying to turn those other options into VS Code? By extension, if you are happy and productive with your experience in any code editor or IDE, why leave? A tool only makes you a better developer if it is solving a problem for you, and if you don't have any problems that need solving, your time and energy might be better spent by focusing less on the tools and more on the code itself. If something is working, maybe ignore the FOMO and work on other things instead.

I wasn't happy in VS Code though. In fact, that sense of unease and that sense of friction I mentioned earlier were really nagging at me, to the point that I wasn't enjoying writing code. But what I'd cobbled together as my first attempt at a Neovim config wasn't making me happy either. Once I thought about that, I realized it was foolish to try and copy VS Code, because Vim in general is a very different tool than VS Code, and I needed to look at it differently. So I came up with another approach.

Personal Development Environment

Before I started hacking another config together in Neovim, I took a moment to reflect on what I had learned so far. And I came to a realization of just how much a tool like VS Code is doing for the users that they never actually see. It's easy to find an extension to do something like formatting or adding support for a new language, and then just install it and maybe change something in a menu and it works. There is a huge burden of compatibility and stability that falls to the extension authors, and the users get the benefit at the cost of configurability. Neovim doesn't have that, though the plugin authors work hard to make sure things stay working. When you install a plugin, you also need to write the related setup code (or copy it from the docs) and then you need to verify that it's working as intended. It's also probably a good idea to look through the source code of any extensions and make sure they aren't doing anything shady. (though I haven't found a single bad apple yet)

Keeping these thoughts in mind, and knowing I had to own my own configuration and handle it responsibly, I decided that I would start using basic Neovim with a color theme installed, and just start working with some code. Whenever I came across something that was causing friction, I would research how to change it or approach the problem differently, and only install a plugin if it was appropriate to do so. I would also take the time to understand what the plugin was giving me, what setup options were available, and how it would interact with other plugins I already had set up. Off I went!

And then things started to get interesting.

The Neovim community talks about the idea of a "Personalized Development Environment" and even though I had heard it before, I didn't fully understand what it meant until I started carefully building up my own setup from my new, more strict philosophy. I also think there was a good deal of value in failing to set it up once, because I was more aware of what not to do. I found that the key idea is that I can add and change functionality to fit my needs, in any way that I see fit, for better or for worse. And by letting go of all of the conventions I had learned through 2 other editors, I was able to focus on what I needed an editor to do and not how to bend my needs to fit the model of the editor. As a result of this process, I don't have a huge list of plugins and each one has a purpose. Some of the highlights are as follows:

File navigation the slow way - Most IDE's have a file tree in a window on the side of the editor that people use to navigate files. Out of the box, Vim has something called NetRW which is a simple version of this with several other capabilities built in. When you open it, it takes up the whole screen by default, and when you pick a file, it goes away and the file you picked takes up the screen in its place. It's a simple tool that does the basics of file navigation well enough. As a result, I didn't need to add a file tree plugin at all. (though there are many!) NetRW does its job, and I have a plugin that makes it look nicer with things like file-type icons, but there are other ways to move around in projects as well.
File Navigation the fast way - Most IDE's also have the concept of a fuzzy finder to get to files. Once you have an idea of the file structure of a project, using the fuzzy finder is helpful to move around much faster. Now imagine that your fuzzy finder allows you to bring up a list of files, and as you scroll through them you see a preview of the highlighted file in a window off to the side. And what if the same fuzzy finder could be used to find keymaps, help documents, and even search for a term inside files and allow you to jump right into the file at the location of the search term? This is all easy to do with the Telescope plugin. And Telescope will allow you to search through any source that can generate a list. Not all at once mind you, that would be too chaotic. But it's the same interface for searching different things, and you use a "picker" to access each type of search. The list of things you can search through with the built-in pickers is pretty insane, and then you can write extensions for it to add more pickers. There is even a built-in picker for searching through built-in pickers. And it all runs really, REALLY fast. As a result, the bulk of my file navigation is now done through Telescope, along with searching help docs, finding open "buffers" (analogous to tabs in other editors), etc.
Snippets on steroids - Most people who write code are familiar with the idea of code snippets, and they are very useful. And of course, Neovim has multiple plugins that allow you to use them. You can even use these plugins to load snippets in both the VS Code and Snipmate styles and use them as is. (You might need to install a regex tool for some advanced transforms though) This allows you to use snippets collections from VS Code plugins and a wide variety of other sources. However, someone thought that wasn't enough and wrote the Luasnip plugin. It can load snippets from other sources like I just mentioned, but also has a programmatic API that allows you to build extremely complex and performant snippets with code. You can use snippets inside snippets, and have one part of a snippet fill in based on a calculation from another part, do code transforms, conditional jump points, etc. The end result is a huge amount of power and control, limited only by your imagination. I've barely scratched the surface of this one and I already love it.
A better way to map keys - In Vim, keys are done in sequence for pretty much everything. You still have access to the Ctrl key, but only with one other key at a time. Instead of mapping actions to a number of keys pressed at the same time, you map things to trigger after a sequence of keys is pressed. There are a number of sensible maps that come standard, like "ciw" which maps to "Change inside word" and will delete the word your cursor is on and change to insert mode so you can enter something different. You can remap any of the basic keymaps as well. However, you also have a "Leader" key that you can set to any key you want. (I use the space bar.) The leader allows you to move to a user-defined keymap palette and specify key sequences to do whatever you can dream up, without interfering with the built-in mappings. So I have mine arranged in groups. Leader key, then "f" for finding things, "g" for going places, "c" for changing things, etc. By typing Leader-f-f in normal mode, I open my file finder, and Leader-s-v splits the window vertically. It becomes much easier to use keymaps because I rarely have to reach for the control key, and mappings are in logical sequences making them easier to remember. But what if I don't remember them?
Everything is discoverable - You can find anything from within the program, starting with keymaps. I have a plugin called Which-Key that works as follows. Say you start a sequence for a key mapping and forget where you are going. After a short delay, a window pops up along the bottom of your screen that tells you where you can go next based on what you already entered for mappings. So if you forget something, it prompts you along to the result you need. But what about when you forget how to start the sequence? I also have a keymap set up that opens the Telescope plugin that allows me to search through keymaps in the same search tool I use for everything else. What if I flat-out forgot how to use a plugin? Telescope again allows me to fuzzy search help topics, and nearly all plugins ship with documentation in a formatted text file that you can jump around in, almost like HTML in the terminal. The result is that I can find things with less effort and thought than I ever could in VS Code. It helps me to become a more proficient user faster with less effort involved.

These are just a few of the things I've discovered as I've built the configuration I'm using now. I have tools to do advanced find and replace using Regex captures (Native to Vim - not a plugin!), key maps to move lines or blocks of code up or down, etc. I also understand what everything I'm using is giving me, and how the pieces fit together. This means if I find anything that is bugging me, I can go in and fix it. This is true from keymaps to functionality to window layouts. I have control over my editing environment now, and that makes it personal and functional to me.

It's also really fast and light on resources. Since Vim in general is a terminal-based program, everything is done through text representation and the use of Nerd fonts for symbols and the like. No GUI rendering overhead. I can navigate to a project directory, hit the command to open Neovim, and it's ready to use in less than a second. (and I haven't even started optimizing yet!) And since it's all done using code to configure, I can keep my config under version control, push it to github to back it up, branch it to try new things with no fear of breaking a working config, etc. So on top of the speed and the personalization, I have the freedom to experiment. It's all very liberating.

But like anything in life, the good comes with the bad. And there are some things you might find challenging that we need to discuss also.

The hard parts

The first thing to mention is that Vim is stable and is at version 9.0 as of the time this was written. Neovim is not yet at version 1.0. As of the date of this post, Neovim is at version 0.8 with a nightly dev build of version 0.9 available, and since it's in beta status there are still several things in the API that are changing. Furthermore, many OS package managers are shipping an earlier version, so if you want to be up to date with the latest and greatest, you will need to download and build from source code or download an app image and configure it to run as a binary. If you aren't comfortable with doing that, Neovim might not be the tool for you. (though there are many guides floating around to do this.)

Next, the whole ecosystem is moving very fast. It's not uncommon for plugin authors to add a ton of updates and maybe introduce breaking changes in a very short amount of time. It's also very easy to forget that fact, and then ask your package manager to update all plugins while installing a new one, and suddenly something else stops working and you have to debug it. General rule of thumb: If you have a working Neovim config, leave it alone and go write some code.

Also missing are some of the deep language integrations that you can get from full blown IDE's that will allow large-scale intelligent refactoring and code suggestions. If you are using features like this in IntelliJ, Visual Studio, or other IDE's and you count on them, you may miss them in Neovim. And if you are a full-time Java or C# dev, you might struggle to get what you are used to from Neovim in its current state.

If you want to use Neovim to its fullest, you will also likely need to learn Lua. It's a nice little language with some quirks, but it's generally easy to get up to speed and it's not a complex language to use. It's still another thing you have to learn though, as nearly all of the plugins will require some setup code to integrate with Neovim itself and that code will be Lua. You can also use the Lua API in Neovim to do things like keymaps, editor commands, set core config options, and a whole host of other things. So it's worth the time to learn if you want to use the tools. However, if you aren't yet comfortable with coding concepts like abstraction and modularity or if you are still learning to code in the first place, working with Lua and all the API's can get overwhelming very fast. See the next section for some options that might suit you better.

Speaking of setting things up, you will have to do a lot more of it on your own. Things like language servers will need to be set up, along with the adapters to make Neovim talk to them, and a completion engine for Intellisense and snippets, and plugins that allow the language servers to act as sources for the completion engine. And of course a range of plugins that allow these things to integrate into your configuration in a variety of different ways. There are some things that handle parts of all this setup for you, at the cost of your own ability to customize as needed. There are also plugins that offer sane defaults you can start from and then change things as needed. Conceptually though, you will see under the hood of what a lot of IDE's are doing on your behalf.

If you aren't someone who likes to tinker and tweak, Vim may not be a good fit also. Something that is commonly mentioned in the Vim community is that your personal configuration is an ever-evolving project on its own. You will find yourself adjusting, adding, refactoring, and trying new things all the time. If you aren't that type of personality, you might not have a good time. Note that you can leave it as the stock installation and not configure it and it will still edit text, but a lot of the really nice additions either won't be there or will be harder to reach, like LSP for example.

Also, if you aren't comfortable working with the command line, Vim probably isn't right for you either. You'll be spending a lot of time in a terminal by design.

And some things are just plain painful to work with. Setting up Javascript and Typescript debuggers was one of my pain points. I have a Node debugger that is currently working, but it's using a deprecated adapter. Sooner or later I'll have to figure out how to get the current adapter working.

So keep in mind that there are tradeoffs to everything, and you have to be willing to take the bad with the good. In a lot of cases, the convenience and stability of other IDE's might be right for you.

Is there a middle ground?

Yes there is. Actually there are a few approaches to meeting in the middle, and any of them might be good for you.

First, most IDE's have a way to set up Vim keybindings so you can start using the motions. And for what it's worth, the motions are actually pretty good. You can research that option for your IDE of choice and still keep the rest of your workflow intact.

In the case of VS Code, it goes a step further. With the VSCode Neovim plugin, you can use a fully featured Neovim instance embedded inside VS Code, including Neovim plugins. This gives you the best of both worlds, but you will still have the runtime and rendering overhead of VS Code itself. Still, many people are very happy with it.

If you want to go full-on Neovim but want a more or less ready-to-use experience, you can check out AstroNvim, LunarVim and NvChad. All three of these are well-loved in the community and can work as-is for an excellent experience, or be customized and extended to meet your needs. There are some others out there as well, but these three names come up all the time. (Quick note on this though, by using these you are abstracting what the configuration is doing, so it might actually be harder to start understanding and customizing your own config)

If you want a jumping-off point to build a config yourself, you can start with Kickstart.nvim which is a basic configuration with some niceties included and is designed to be built on top of. TJ Devries also made a great Youtube video walking through setting it up and using it for the first time.

And if you want to start from scratch and build your own configuration, you can't go wrong with the Youtube tutorial by ThePrimeagen that walks you through how to do it from the ground up.

Also, if you are looking at Neovim, you should also look at straight-up Vim, which is mature and very stable. The base, unconfigured installation is virtually identical to Neovim in how you use it, and does come pre-installed on many systems. The range of plugins is also quite large and most are very stable themselves, and Vimscript might be a better configuration language for you.

Lastly, I would be doing you a great disservice if I didn't tell you about Helix, which is a modal editor that works in slightly different style than Vim. From what I've seen around the internet, it's really good already and it's still in early development. If you are looking at Vim, you'd better look at Helix also. I've only done a cursory look at Helix myself, so I can't provide much more, and that would be outside the scope of this post anyway.

And if you are Vim-curious and need some help, there are resources sprinkled around the internet, Reddit groups, discord channels, and Neovim also has an IRC channel that you can join if you want. The people you will come across are passionate about the tools they use and will genuinely want to help. Neovim also has Neovimcraft which is a site dedicated to plugin discovery. However you seek help though, don't be surprised if the answer you get is a pointer to the built-in docs. They are extensive and useful, and constantly getting better. Both the Vim and Neovim communities want them to be the included and relied upon source of truth.

So, is Neovim right for you?

I can't answer this question for you. What I can do is encourage you to keep an open mind and ask if you are getting what you need from whatever tools you are using. I can also ask you to do a deep dive on all of your existing tools and figure out what you might not be using that could be helpful. You might be surprised at what you discover.

From my perspective, I'm enjoying writing code again. It took a lot of work and a lot of learning though. I have a much better appreciation of the time and energy that goes into any modern code editor. There are a lot of brilliant people out there that are making awesome tools for all of us to use. (You might even be one of them! Thank you if you are!) Using and configuring Neovim gave me a window into that work that I hadn't seen before. Switching over was the right thing - FOR ME! That doesn't make it right for anyone else.

So however you go about doing it, I hope that your coding experience is something you enjoy. Hopefully I've also inspired you to experiment and find the best workflow and tools for you. Make it yours, play around with it, and have fun, regardless of what you are using.

Thanks for reading, and please feel welcome to leave a comment on your own experience. I'd love to hear about it.

Special note: The terminal background image I used in the cover image is a beautiful photo from Jaanus Jagomgi on Unsplash, with a semi-transparent layer placed on top to darken it. Thank you Jaanus for capturing and sharing that photo!

How to think like a programmer: What are variables, really?

Nik F P — Fri, 18 Nov 2022 17:16:42 +0000

Photo by Dan Cristian Pădureț on Unsplash

Ah, the mighty variable. It's a core tenet of programming. You assign them, you use them, maybe you reassign them. They store your strings and numbers and booleans and other things from time to time, and you don't give them much more thought.

But how well do you know these little pieces of code? What are they up to behind the scenes? What pitfalls lurk in their more esoteric uses? And most importantly, how do you make sure the variables you use will do what you expect them to do?

This post will work through a few if these questions, and is designed to help get you thinking about more than just the variable name, and to inspire you to dig in to your language of choice and gain a deep understanding of the humble variable. This is not designed to be a tutorial on how to use variables, however. There are countless resources out there that do that already, and better than I could do it. I assume you are coming in to this with at least a small intro to a programming language under your belt. Instead, this is designed to help you figure out why you use variables the way you do, or at least get you excited to find out on your own, and to get better at understanding their strengths and limitations. This post came out on the long side, but hopefully you find it entertaining.

So lets get started!

What is a variable in the first place?

This is an interesting question, because it seems so basic. It's not as simple as you might think though.

The official Wikipedia definition of a variable is some pretty dense reading. There is a lot of jargon involved. It's accurate, but can be confusing until you know what everything means. So we'll make this simple, by giving you a few bullet points to remember.

A variable is a place to store information that you need to use later on in your program.
A variable has an identifier (also known as a name, or a symbol) and a value.
You can assign values to variables as the information you need to store becomes available.
In certain cases you can initialize a variable without giving it a value.
You can retrieve the information later on by referring to the name of the variable.

Pretty straightforward, and you can get really far with just what we've covered so far. Assign variable by giving it a name and some information, use it later. Got it.

But what happens when your program starts doing things you don't understand? What if your variable changed and you can't remember where it changed? What if you are sure you assigned the right value, but something still isn't working right and you want to hit your keyboard with a hammer? How do you go about protecting yourself from bugs that might be hard to track down?

Let's dig deeper and see what we find.

To mutate or not to mutate?

For this example I'll show you some code that is designed to do a series of steps: Assign a variable, then assign a second variable based off the first, then reassign the first variable, then print both variables. Then we'll start tweaking things. This is designed to showcase what you need to know about the variables you are assigning and what can happen if you try to change them.

Let's start with Javascript. Your first code example might look like this:

var a = "hello world"; // assign first variable
var b = a; // assign second variable
a = "hello again"; // reassign first variable
console.log(a); // print first variable
console.log(b); // print second variable

This code will run, and you will get the following output on the console:

hello again
hello world

Simple enough, right? You assigned the variables, reassigned one, then printed them both. Just like we planned.

Now let's update this to more modern syntax. Using var in Javascript is now considered obsolete and is rare to see in new code. Instead of using the var keyword, we can use the const and let keywords to declare the variables. We'll start with const.

const a = "hello world";
const b = a;
a = "hello again"; // try to change a variable
console.log(a);
console.log(b);

This code will not run, and you will get a message Uncaught TypeError: invalid assignment to const 'a'. So what happened?

By using const, you told Javascript that you want to assign an immutable variable - a "constant". That means that once it is declared, it can't change. On the third line, you tried to reassign it, but since it can't change JS threw an error. By being explicit that the value should remain the same, you gave the Javascript runtime a hint to your intentions.

And this is the heart of mutability: Are you or are you not allowed to change something? And should you? We'll discuss this concept further in just a moment, but let's continue exploring first.

Getting the code to work again is pretty simple. You change the const keyword to let when you assign variable a the first time. This tells JS to allow you to reassign the variable later in the code. By using let, you are marking the variable as mutable, or able to change. So this code runs again:

let a = "hello world"; // Note the change here
const b = a;
a = "hello again";
console.log(a);
console.log(b);

At this point, you might ask yourself, "Why not just make every variable mutable? Then I can do what I want with them." The answer to this question is that creating immutable (unchangeable) variables is saving you from yourself. Being able to change every variable in your code at any time is like trying to fly an airplane by holding every knob, button, and control all at once. You forget what you are doing, you bump things by accident and pretty soon things get out of control and you crash. (In both cases!) By having information that can change, you then have burden of trying to find out where and how it changed when things don't go as expected. By creating immutable pieces of information, you eliminate this problem: If a variable is not what you expected, go to where it was assigned and see what's going on. In turn this means you can decrease the mental burden of thinking about your code, and code becomes easier to write.

.... sort of. I'll touch on why in a few minutes.

The next question that comes up is "Why not just make everything immutable? Then I don't have to think about it as much?" The answer to this question is that sometimes it does make sense to have information that you can change. For example, if you have a counter of some sort, it won't always have a value of 1. Otherwise it's not counting anything. So you often have to store information somewhere that is subject to change.

The happy path is to use immutable information (const in JS for example) as the default. When you need a variable that needs to change, switch to let. But think hard about why a variable should be mutable before you create a mutable variable! By understanding that it needs to change and where, you will be thinking harder about what your code is doing and you will be far less likely to make mistakes.

You should also note that in certain languages, All variables are immutable! This is the case in functional programming languages in particular, which tend to live by the idea that once data is created, it should not change. The paradigm for how these languages are used is also quite different from the most highly popular languages, but should never be ruled out: Functional programming is known for creating rock solid, reliable programs. The downside is that you will hear things like "A monad is a moniod in the class of endofunctors" which sounds like gibberish and is actually 100% accurate. I encourage you to explore functional programming at some point if you haven't already, but make sure you have a firm grasp on the basics first.

For now though, let's look at some more examples.

In JS, you can declare variables 3 ways:

var a = "hello"; // mutable - can change
let b = "world"; // mutable - can change
const c = "Hello again!"; // immutable - cannot change

There is technically a fourth way, by just assigning to the variable name such as a = "hello" but a) this only works in non-strict mode (look up JS strict mode for further info and use it!) and b) - Just don't declare variables this way, it's bad form. Be clear with your intention and use the keywords.

You can also assign mutable variables without giving them a starting value, and you can assign multiple variables in the same line.

let a; // variable is initialized but doesn't have a value yet
let b, c; // 2 variables initialized

Note that you can't do this with the const keyword, which makes sense because assigning a constant with no value is completely useless.

Let's take a quick look at some Rust code for our next example. In Rust, the most basic variables are are declared like this:

let a = "hello";

Notice that this is exactly the same code you would use in Javascript to declare a variable that you can change later. But if you tried to change this later in your code, Rust would throw an error. This variable in Rust is Immutable. That's because by default, all variables in Rust are immutable. You have to tell rust that you want it to be mutable, by adding the mut modifier to the variable assignment:

let mut a = "hello";

Rust still allows constants, using the const keyword (which cannot be modified with mut) or by using the static keyword. Depending on what you need to do, you can create mutable, static variables in Rust and the idea is that the variable lasts for as long as the program runs. But you'd better have a very compelling reason to do so, or you could be chasing some very difficult bugs later on.

These examples are to make a point: Things can look similar and might even behave the same at first glance, and you might think you know what they are doing, but your assumptions about their behavior could be wrong, and your code might fail as a result. So whatever language you are using, take the time to deeply understand how variables are assigned, when they are available in the code (lifetimes), when they are no longer available (also lifetimes), and how your code will behave as a result. Don't assume anything, or you could wind up chasing bugs that don't make sense, simply because what you think is happening isn't what is happening.

This is also nowhere near an exhaustive example of either language shown. Be sure to read the documentation for whatever language you are working with and to ask questions whenever you don't understand something. You will be assigning a lot of variables, so it's worthwhile to take the time to get it right.

Stacking things up to get things done

Before we can continue with variables, you should have a basic understanding of how code executes so the rest of the examples make sense. We will cover a few concepts briefly, but I encourage you to dig deeper on your own. I also simplified this a bit on purpose to make it more accessible.

When code is executing, you have the concept of a call stack, which is a data structure that the language controls, with a last in -> first out behavior. (Technically this is controlled by the runtime, but just say it's part of the language.) The language uses this call stack to execute your code. This is accomplished by adding stack frames, which are discreet units of code execution. Think of each stack frame like a box. You stack them on top of each other, and then begin unloading. You don't start on the second box until the uppermost box is empty.

Now, each stack frame can run code that can add more frames to the call stack (functions), but when this happens, the first frame that created the new frame must now wait for the stack frame above it to complete before it can continue (This is called a return btw). Again, back to our box analogy, imagine you are unloading a box and you get something out that says "Add another box to the top of the stack", so you do and now you must work through the uppermost box before you can continue on the one you were working on.

If you execute a function you are adding a stack frame. If you execute another function inside the first function, you are adding yet another stack frame. We can illustrate this with an example. We can create three functions and execute (call) each one inside the next, and the output will show us the stack frames listed in order.

function one() {
  console.trace(); // I'll explain this shortly
}

function two() {
  one(); // calling function 'one'
}

function three() {
  two(); // calling function 'two'
}

three(); // calling function 'three'

When you run this code, it creates all three functions and then calls (executes) the function named three. This creates a stack frame for the scope of three, and inside that scope, two is called. Inside two, one is called. Then inside one, I called console.trace(), which is a special method that prints out the stack frames from the uppermost "active" frame, all the way to the root frame which is where code execution starts. (Which JS calls ) This is called a stack trace.

What you get is this something similar this for the top 4 entries:

one - debugger eval code:1
two - debugger eval code:1
three - debugger eval code:1
<anonymous> - debugger eval code:1

Depending on where your code executes, this might look different, and might have more info underneath, but this is your call stack that you just created and it should have entries, for one, two, three, and <anonymous> in order. (If you try to do this in an online playground like Codepen it probably won't work do to technical reasons specific to those kind of platforms. Try to do this in a local development environment if you want to try it.) The uppermost entry is the one function, just like we expected, and you can see two, three, and the root <anonymous> frames as well, stacked on top of each other.

You may have also noticed through writing and running other code that if you write code that produces an error, you get a message that includes a similar stack trace to the one shown above. (names of the frames will be different of course) This is not an accident, this is the language attempting to give you information on how to fix the error. Starting at the location the error was thrown, the message will lead you all the way back to the root scope, so you have an execution path to aid you while you look for the problem.

What do stack frames have to do with variables then?

It turns out, stack frames and variables are deeply interconnected. I'm not going to go deep on scopes, which govern when you have access to which variables, but you should look this up as further reading and I will touch on them later in this series as well. (If you follow tutorials for your language of choice they will nearly always explain this also.)

What we will cover though is how variables are stored in memory. This discussion is widely known as Value vs. Reference types, and Stack vs Heap Memory, for reasons that should be clear shortly. Again, I have simplified this a bit to make the concept easier to understand. As always, dig deeper once you get the concept.

Also, all examples here are in Javascript, but be sure to read the documentation for any other language you are using because some things will be different.

First, you have primitive types, which are the very basic data types that a language supports. These are basic, they are a known size in memory, and they are immutable. (more on this shortly) In JS, these are string, number, bigint, boolean, undefined, symbol, and null. Primitives are also known as value types, because when you use them, you are directly using the value.

Then you have reference types, which are more complex. They might not have a known size, and may consist of multiple types of data brought together in a collection. In JS, these are called Objects and the data they contain are called Properties. You will also come across collections of data of the same type, called Arrays in JS, which are a specialized type of object. Regardless, these types behave differently to primitive types. They are created the same way though, like this:

// Note 'const' declaration below, just like we saw before. 
// We'll talk about this trickster soon! 
const a = {
    hello: "world"
}

Whenever a variable is created, it is stored in association with the stack frame that created it. For primitives (value types), the actual data is stored in a data structure that is dedicated to that stack, which is easy for the program to manage and is a linear data structure. (It also happens to be a stack, just of memory). The underlying values are also immutable. So how does it work when you reassign them? A copy is made of the value and the new copy is stored with the new variable name, inside the memory for the stack frame where the new variable was created.

This means that when you do this:

const a = 5;
const b = a;

You are storing the number "5" in two places in memory. In this case, variables a and b are part of the same stack frame, but that frame has 2 distinct pieces of memory in use for the 2 variables.

But what about reference types? They can be very big and very complex. The stack frame might not have the space to handle them. So the stack frame reaches out to a larger memory store, called the heap, which is bigger in size, unstructured, and generally can grow or shrink in size as needed. The way this works, is the program asks a part of your language, called the Allocator, for a block of memory of a size large enough for your information. (In some languages, like C, you as the programmer ask the allocator for the memory in a manual step) The Allocator then goes to the heap memory and finds a block that is not in use and is large enough for your information, marks it as in use, and comes back to the program with a reference to that section of memory, which is a set of directions to where the information can be stored. That reference is what gets stored in the stack frame: It's a known size of a known type, and small enough to fit inside the stack frame. Then the program can follow the reference to the heap memory and store the information.

There are 2 big implications for this memory behavior. Well address the first one in this section, which is speed, and get to the other one in the next section.

When you store or retrieve the data in a value type variable inside the stack memory, the value is stored in a linear data structure with very fast access. It's super fast to get that information or store it in the first place. This means your code can execute super quick. But when you initialize the variable for a reference type or ask for that data back, your code has to pause execution and take the time to interact with the allocator and the heap memory. Then it has to bring that info back and work with it. This adds time to the whole operation, as the heap memory is much larger, is unstructured and non-linear, and is much slower to work with.

// faster
const a = "hello";
console.log(a);

// slower
// Note 'b' is an object, created with '{}'
const b = {
    hello: "world"
}
console.log(b);

This can have significant performance implications for your code. In some languages it is much more pronounced than others also. If time is a factor, you can save some of it by striving to store information in the stack memory (as primitive types) as much as possible. But you must also keep in mind that stack memory is limited and is preset when the stack is created, and if you run out of it, the stack overflows and the whole program crashes. (and possibly the operating system it's running on) So only start optimizing this way when you have a defined need to do so. Otherwise, do what makes the code easier to understand and write, and just keep this in mind. And again, learn the specifics for whatever language you are using.

When a constant isn't a constant - and immutable things mutate!

Remember when we were talking about mutability, and I said that using immutable info made the code easier to write? There are still some pretty big gotchas in this, and you need to be aware of them to truly understand what your code is doing.

Remember when I said there was another big implication for the way memory behaves? This is also where that will come into play.

In fact, this is where the variables discussion all ties together to help you fully understand these sneaky little bits of code. And it all begins back on the stack frame.

Let's start with value types, and let's review what we looked at above.

What do you think happens when you assign a variable based of of another variable like this?

let a = "hello";
const b = a;

On the surface, you would say that a stores "hello", and b stores the value of a. This is mostly correct, but if you recall what we discussed above, what is really happening is b is storing a copy of the value of a. This means that the values of both variables will resolve to "hello", but it's 2 different, distinct copies of "hello" in memory.

That means if you then mutate variable a, and then log both values, you will see them as different. This code:

let a = "hello"; // Note this is mutable :)
let b = a;
a = "world";
console.log(a);
console.log(b);

Produces this result:

world
hello

So far, so good. But now let's look at a reference type.

Remember that reference types store instructions in the stack memory for where to find the information. So when you create a reference type, then make a copy, what do you think happens on the stack frame? Let's take a look.

If you run this code:

// Note we are creating objects here, using curly brackets!
let a = {
   hello: "world"
}
const b = a;
a = {
    hello: "old friend"
}
console.log(a);
console.log(b);

You see this:

{ hello: 'old friend' }
{ hello: 'world' }

It turns out, a and b are behaving exactly the same as we expect. So far so good, right?.....

So what if we wanted to keep a as immutable, create a copy of it, and then change something in the copy. The code will look like this:

const a = {
   hello: "world"
}
let b = a;
b.hello = 'old friend'; // this reassigns the property value 
console.log(a);
console.log(b);

We execute the code and we get this:

{ hello: 'old friend' }
{ hello: 'old friend' }

Wait, what just happened? We assigned a as a constant, which means it can't change! We assigned b as a copy of a, per the rules above, then we changed the hello property of b, but a also changed. Doesn't this break the rules?

No, It doesn't. In fact, it's doing exactly what it's supposed to. I'll explain.

When we worked with value types before, we were making copies of the value types as new variables. That is still what is happening in this example. The critical difference is that when we store a, it is a reference type now, because it's an object instead of a primitive type. Remember, this means the actual information is stored on the heap, and just the reference is stored on the stack. So when we create variable b, we are creating a copy of what the stack has stored for a - which happens to be directions to the information on the heap. Different reference, but pointing to the same place!

So when the property in b was updated, we didn't break any rules, because a is just directions to the information, and so is b. The underlying info can change all day long, and a would still be correct. By changing the information in b, you are asking the language to change the underlying information that both variables are pointing to! So now you have gone and mutated your "immutable" variable.

You might have noticed before that we successfully reassigned a reference type, with the code that looked like this:

let a = {
   hello: "hello"
}
const b = a;
a = {
    hello: "world"
}

So what is different, that made our code fail when we tried again? It's a subtlety of how the variables are being reassigned. And we can highlight this with another example.

This is VALID JS that will run as written:

// Note we are assigning this as constant
const a = {
    hello: "world
}
a.hello = "again"; // Note we are reassigning a property of variable 'a'

Remember how I stated above that the underlying information for a reference type can change and the reference can still be valid? That is what we did here. a is assigned to the same reference the whole time, and we are just changing the information inside that reference.

In contrast, this is NOT VALID:

const a = {
    hello: "world"
}
a = {
    hello: "again"
}

The key difference is that we are trying to assign an entirely new object to a, which is asking the allocator to give us a new heap reference, and the const keyword prevents that from happening.

Having fun yet?

It can get worse, depending on what language you are using. If you work in a language that has manual memory management, you can allocate heap memory in your code and assign the reference to a variable, use it, and then free the memory up again (called deallocating), and then forget that it was freed up and try to use the variable again. This means your code is trying to use information at an address that was shown as free to the rest of the system - and may be in use by something else! If you extract that information, it might be totally useless, but it might be sensitive information that your code has no business using, and now this flaw in your code could be used to extract information from the underlying system. This is a security issue now!

Or you could go the other way and assign a reference type, but never have a mechanism to release it. This is called a Memory Leak, because your program will keep allocating new memory without releasing the used memory, and if it goes on long enough your computer will run out of available memory altogether, and the program (and possibly computer) will crash.

Rust has a borrow checker to avoid exactly this issue. Other languages that make it possible have common patterns for programmers to help them avoid it. No matter what though, it pays to know how your variables will behave.

On the other hand, sometimes this behavior can be useful. By having multiple references to the same source of information, you can use that information as a single source of truth for the rest of the application. Care needs to be taken to do this correctly, but nonetheless a seasoned programmer can use this to their advantage in many interesting ways.

What do you do about this memory issue then? Quite simply, you learn about it in the language you are using, so when you write code, you understand what it's doing. Some languages will make you clean up your own heap memory. Some will use a "Garbage collector" - an algorithm embedded into the runtime that periodically frees heap memory you aren't using anymore. Some languages will let you share variables across threads, and the rules will differ based on the language. Take the time to get familiar with the way your language handles this issue, because if you write code this will eventually matter.

So what's the takeaway?

If you get nothing else from this article, I want to leave you with one thing: Understanding how variables work in the language you are using will make you better at writing in that language. You will have a deeper understanding of what the keywords you are using are asking the language to do, and you will have more trust in the values you get from your variables when it comes time to use them. Ultimately you will be better prepared to do what programmers are supposed to do - Solve problems.

Computer programs are fundamentally just information in -> information out. What happens to that information in between is in your hands, and your variables.

Assign wisely!

What's next?

Join me when I publish the next installment of this series, which is all about taking control of your code. See you then!

How to think like a programmer: The human part

Nik F P — Fri, 11 Nov 2022 22:31:52 +0000

Welcome to the inaugural post of this series, designed to help you think like a programmer! I got the idea for this series after a comment that I posted on a blog post got a good reaction, and someone asked me to express this in article form. So here we are.

This series is designed for people that are early in their programming journeys, however intermediate developers will also find this series useful to help fill in some gaps and understand what might be valuable to learn next. None of the topics will be exhaustive, but instead will be designed to get you thinking in the right direction. My goal is to get you excited about the concepts I present, and inspire you to seek further knowledge on your own. So let's get started!

Why the human part first?

When you think about programming and how to think like a programmer, your first instinct will be to look at the concrete skills required to work with code and make things run. However in this post we're going to take a step back and look at an often overlooked aspect of programming: The human part. Why? Because at the center of every program is a human being that took the time and energy to put it together. In fact, that human is a requirement for the program to come in to existence in the first place! So logically, it makes sense to consider the person writing the code when you are thinking about writing code.

It goes without saying that we are all human, but our own humanity also influences the way we approach technical work and how deeply we can think and understand things. Without considering the living, breathing, thinking part of programming (us), we limit ourselves to just a subset of our creative potential, and ultimately limit our own success. So through the following sections I would like to share some things I have found to be true. These ideas apply much more broadly than just programming, but in the world of code they are particularly true in my experience.

First off, You gotta wanna!

Perhaps the most overlooked part of being a proficient developer is that you have to enjoy the process of building things and understanding things. First and foremost, your role is to bring something to life out of nothing. You will be thinking in concepts, many of which will be very foreign when you start. You will be challenged to make things that don't exist, without a blueprint, and you will need to be creative to do so. You will be pushed to gain a deeper understanding of everything you touch, so that you can make it better and become better for yourself in the process. And to do any of this well, you must find joy in it.

Finding enjoyment in the work you are doing is critical, because without it you won't have the drive, curiosity, and perseverance required to get through the tough times of writing code. And there will be tough spots. Programming is hard. The mental anguish you can experience while looking for that missing semicolon, the heartbreak of a timeout error, or the sheer panic of an unexplained stack overflow can all be staggering, especially when you have a deadline to hit or a critical bug to fix. You'll need the grit to push through the crazy times.

It can also go the other way. Sometimes you just have to write a lot of boilerplate. It can feel repetitive, slow, and not engaging. You'll want to go do other things. It can get boring, but you need to have the will to push through the slow times.

Sometimes your code won't work the way you expect (or at all) and you won't know why. You can spend hours changing one small thing here, another small thing there, and still getting strange results. You can feel confused for days on end. You have to have the patience to work through the problem.

Sometimes a concept will simply be over your head. You have to have the humility to accept that you don't know everything, start small, and fill in your knowledge gaps the best you can.

I really don't want to scare anyone off (in fact quite the opposite), but this is important to think about, because in programming you are going to be frustrated a lot. It's the nature of the beast. You are stitching together technical concepts, each with their own limitations, into a system that can do the thing it's required to do. You might have days on end of no productivity. You might have a particularly hard problem that you can't solve. You might have crippling imposter syndrome. You might have all of these, all at once. You are not alone!

The flip side is you might have incredibly productive periods, where everything clicks and things just flow together. Problems are easier to solve, bugs are less frequent, and you are less inclined to turn away and do other things.

The number one thing that will keep you going is enjoying what you are doing.

From my experience, when I expect code to work that isn't, or I expect code to behave differently than it is, I become almost obsessive until I can understand why. (to the frustration of my wife at times!) I'll roll the problem around in my mind - sometimes for days - and turn to Google to see what others have to say. At some point, something will click or some information will surface, and I will be able to solve it or at least move in the right direction. I then have a moment of joy that I was able to overcome the problem, and go looking for another one.

And I write code because I love to write code. I find the creativity within technical limitations fascinating. I feel that all programmers should approach it like this. The money is secondary, and I should point out that I don't get paid to write code. (Someday maybe) In fact, all of the best developers I follow would continue to write code even if they weren't paid at all. In their spare time, this is exactly what most of them are doing with open source, because it's fun to them. So if you want to be great, do it for the joy of it!

Remember that you are human.

Like it or not, you have basic needs that you must attend to for peak performance. Sitting in front of a computer for 18 hours straight is not meeting those needs. You need rest. You need variety. You need healthy food and physical activity. This is for everything, not just programming, but it's particularly important for people that work with code.

An example of this for me is that I frequently need to get up from my desk and just go for a walk. Sometimes it's just back and forth inside. Sometimes I go outside. Stepping back from time to time allows me to reset, and come back stronger.

I also find that the more I focus on eating healthy, getting enough sleep, and getting some exercise, the better I feel AND the better I perform when I'm working, or writing, or coding. It's all interconnected. You are the sum of all of your parts, body and mind. Taking care of each aspect in turn improves the whole.

So take the time to be good to yourself. Don't expect to learn everything in a day or build everything in a day. Don't expect good results from long hours of coding and nothing else. Don't get overwhelmed and give up, but instead give yourself the space and the time to do things right, at a pace that is natural to the way your mind works, as much as you can. Feed your mind and your body, then exercise both, then get enough rest for both. Find the balance that works and is sustainable, and you can set yourself up for continuous growth and success.

The most complex things are just big collections of simple things.....

If I asked you what your definition of a computer program is, what would your answer be?

For me, a program is a series of instructions designed to take information in, work with it, and give information back out. That's it. Simple? In theory, yes. But when you look at what that might mean in practice it can quickly become very complicated. The inbound information can be very complex, or there could be huge amounts of it, and the outbound information might need to be equally complex, and there also might be huge amounts of it. Some things might be incomplete, or malicious, or utter nonsense. You might need to efficiently restructure information that seems very foreign to you. There might be restrictions on what information can come in and when, and what information can go out and when. There might be specific reasons for code to behave a certain way, and then some parameters change and it should behave a different way. Pretty soon, the simple, "Info in, Info out" program is actually a complex monster.

How do you build something like that? You come at the problem like a programmer!

The fundamental method of solving a problem with code is to break it down into simpler problems and solve them one by one. If the simpler problems are still too complex, break them down into simpler problems. Repeat until you are able to solve each problem, one at a time. By doing this exercise you are able to build systems far larger than what you can hold in your mind at any given moment. You can account for changing conditions, and change the behavior of your code. You can create flexibility and resilience. This makes your programs more powerful, and makes you feel powerful!

But make sure you understand the big picture.

The essence of programming is that you are solving complex problems by using a collection of tools and concepts, to solve collections of simple problems, building up toward a complete solution. But before you can do this, you have to be able to back up and just look at the whole problem. This takes a great deal of patience, because your first instinct will be to start writing code and see what you can come up with. However, taking the time to really understand the problem before you work toward a solution means you are approaching it with a level of thought and maturity that allows you to develop a complete solution. In other words, you have to think about things from the perspective of how to build it, but also from the perspective of the people using it, and also from the perspective of how it fits into a larger system.

Take the standard Grep program as an example. For those who don't know, grep is a program designed to search for a matching pattern of characters based on an input. And for many people, that is enough of an explanation. They might even start implementing their own version based on this. They might be shortsighted in doing so, however.

A second view is that Grep is a program to help people find what they are looking for. The important subtlety here is the people it needs to work for. Now, I don't know if you have ever used Grep before, but if you have it's pretty clear that you can't use it without first reading a manual or instructions of some sort to get you started. It's not the most intuitive. It's likely that the people that built it were originally building something strictly for like minded people, so the layperson wasn't accounted for, and as a result they built a powerful tool that can sometimes be very confusing to use.

Where all this is going is toward this point: Before you can start breaking the larger problem down, you need to understand the problem. Not just from the viewpoint of the person writing the code, but from the viewpoint of the person using it, and how it fits into the ecosystem it will exist in. Doing this will help you build programs that people actually want to use, and that perform the way they need to perform.

Everybody learns in their own way

There are 2 very important aspects that this section needs to cover.

The first is that you need to understand what methods of learning are most effective for you. It could be through books, through activities, through watching videos, or many other methods. In programming you will always be learning, so getting a grasp on how to personalize your learning path to fit you best will supercharge your growth. Then, as much as possible, you need to tailor your learning environment and your learning plan to fit your learning style.

This means that you need to be aware of distractions while you are learning, such as outside influences and your own habits. Do you have a quite place to think and learn? Do you tend to procrastinate? Do you have all the things you will need close at hand? Do you keep getting notifications? Etc, etc.

For me as an example, I have found that I do best with a quick tutorial, and then just diving in and actively working with things. This is how I learned to write code: by getting some basics down, then getting myself into problems and getting myself back out of them. It's an unstructured approach that tends to work best with the way my mind works. For others though, a more structured approach with tutorials or books might be best. I have zero opinion on which method is better, because I don't believe one is better than another. The important thing is that you keep learning in a way that fits you.

I have also found that I do best with mellow instrumental music as a backdrop. This isolates me from the distractions around me and allows me to get in to a state of flow. I do my best work when I have long stretches of time without phone calls, notifications, or people interrupting me. This seems to be true for most people, but some people love having the energy of others around them while they work. It helps them to maintain their own energy levels and stay productive.

The end goal is always the same no matter how you go about it. You want to retain the technical knowledge you need to do the work (like how a language works and what syntax to use), but you also need to retain the higher level principles, concepts and patterns that allow you do the work in the first place. Setting yourself up for success and knowing what is most effective for you is critical to achieving these 2 milestones quickly. So take the time to understand what works from you, from methods to locations to how loud the music is when you work. Doing so will help you immensely.

The second learning related thing you need to keep in mind is that not everyone else learns the way you do!

It's all too easy to look at a learning resource you have available and think that is doesn't make sense to you or it doesn't fit the way you would like. You might even be tempted to bring that to the attention of the person that created the resource.

But before you do, make sure you consider that the resource you are using might have been designed for someone that learns in a different style, or might have been designed to target as broad an audience as possible. Things like presentation, pacing, ordering of subjects, and the depth of examples might have had a lot of thought put into them, and might be targeted to the group they connect with on purpose, and you might happen to be outside that group. I encourage you to have discussions with the creators of these resources, but keep it positive and connect with the mindset of genuinely wanting to help. They are creating for a reason: They want to be helpful themselves. With this in mind, any assistance you can provide is likely welcome and often needed for them to improve.

Another layer to this is any time you need to teach something to someone else. Try to be aware of how they learn, how fast they integrate new information, and the signs of when they are becoming overloaded. It's not always obvious, and people generally want to do well and aren't as willing to admit when they have run out of steam as you might think. Try to adjust your teaching style, pacing, and break points to the audience you have, if possible. You will learn a lot about how other people think and about communication in general this way, and it will help you to improve overall.

In short, be human about learning and teaching, and empathize with the people teaching you and learning from you.

Onward!

In this post we covered just a few of the human parts of writing code. There are many more and I encourage you to continuously work on this aspect of being a programmer, and being a human in general. Understanding how to be healthy and productive will help you to live happier and achieve more.

Stay tuned for the next post in the series, where we'll dive in to the deceptive world of variables. You might be surprised at what you learn.

Programming is everything and everything is programming!

Nik F P — Fri, 14 Oct 2022 19:34:38 +0000

I was recently reading through comments on a Youtube video while eating my lunch (You know, like you do) and I came across one that got me thinking. It was a question from someone looking for guidance early in their coding journey, and concerned about the effects of a coming recession. It read:

What if you are new? Like started coding 1 month ago? 0 experience. Trying to learn the basics of web dev currently. You don't have any job currently, and already started to burn through your savings. Any advice?

This got me thinking about what I've learned in my career, the choices I have made, and how it could apply to this person's situation. I've been where this person is, more or less, and I truly feel for them. Granted, I'm not a professional dev and not in a hurry to get there, but I've had a "colorful" career so far, that has led me to a good place and taught me a lot of lessons along the way.

I realize now that learning programming has had a vast effect on my ability to think and to interact with the world, and interacting with the world has likewise had a vast effect on my ability to envision patterns, retain principles, and write code. So I started thinking about what I could say to help them, or at least lend some encouragement. It turns out what I can offer as my opinion is beyond the scope of a comment on a video platform. So I started writing this post.

Life and code have more in common than you think

Everyday life is like programming, I guess. If you love something you can put beauty into it.

Donald Knuth

Think about taking care of a houseplant, or a pet, or a child. The more you spend time with it, nurture it, provide what it needs, and give it the space and resources to grow, the more it will grow, be healthy, and flourish. The opposite is also true. If you neglect it, it will start to decline, possibly decay, or worse.

Code works the same way. Give it the time to make it better, the resources to run properly, and maintain it well, and it will stay healthy. But if you neglect it, it starts to rot away. Sure, the actual code is still there, but runtime updates, dependency updates, and emerging best practices will make it obsolete over time, to the point that eventually it won't run anymore. Your code is dead.

This all sounds quite gruesome, but I wanted to make a point. There are a lot of parallels between code and life, between programming and living, and between the abstract world of technology and the very real but still abstract world of reality. Both have patterns, systems, best practices, and things you just don't do. If you can start to uncover the patterns in life and in code, you can start to find similarities. You can start to see things in both life and code as reactive, responsive systems. You see inputs, you see outputs, and you see how it all ties together.

Let's say you are struggling with a coding concept. If you have been paying attention, you can probably find a situation in your real life that will give you a living, breathing metaphor for the concept you want to learn. I can give you an example of this. Let's say you are struggling to define what an algorithm is and you are working as a cashier at a supermarket. Your day job has a perfect example of what an algorithm is, and you are actually a part of it.

The shopping cart that the customer brings to your register is one of the inputs to the system. In this case, it contains a collection of items the customer wants to buy, which is a data structure.
You start scanning the items, and each one is added to the receipt, and increments the total of the transaction. The receipt then is an output, in the form of another data structure. The total that the register calculates and increments is a variable.
You represent the loop in this algorithm. You loop through the items in the cart, scanning each one. You are "iterating" over the cart (input data structure) to create a receipt (output data structure) and calculate a total (variable that is mutated as a side effect). At the end of the transaction, you have transformed the cart input into a receipt output and a total the the customer needs to pay you.

You might think this is strange, but if you look hard, you will see similar examples everywhere! And there is power in this, because this allows you to build an internal library of real world examples to allow you to grasp concepts at a more fundamental level. This is not only helpful, but necessary to allow you to think faster, learn faster, and progress faster. I'll get to why in a bit.

Learning how to learn is now the most critical skill

We now accept the fact that learning is a lifelong process of keeping abreast of change. And the most pressing task is to teach people how to learn.

Peter Drucker

In the world we live in now, things change faster than at any time in human history. Just 40 short years ago the internet was just a novelty and few people could even grasp the concept of email. There weren't smartphones, or even cell phones, save for a few cumbersome units used by the elite. Whole office buildings were dedicated to rows upon rows of cubicles, with people doing "data processing" jobs that were considered strong middle class positions. Those jobs have all been replaced by computers, and at a reduction in cost and increase in throughput that wouldn't be believable in the 1980's.

Imagine being in the generation impacted by this change. People who started their careers in the 80's saw their jobs under threat in the 90's as the internet revolution and increases in automation started taking shape, and saw many of the manual information processing positions go extinct by the mid 2000's. This came as a shock, and one that these people weren't prepared for. Their parents didn't have this much change to deal with, nor did any of the generations that came before. Automation allowed for increases in production scale that weren't possible before. This was a tipping point that shifted the paradigm of knowledge work the world over, and then bled in to other industries like manufacturing, agriculture, logistics, etc.

The big multiplier here was the effect that computers, automation, and eventually big data and machine learning was having on everyday life. Suddenly people found themselves in a world where paradigm shifts occurred not from one generation to the next, but from one year to the next. Jobs that never could have been conceived of 5 years earlier were popping up as other jobs were automated away. This led to an interesting situation:

The only constant was change, and the change was accelerating.

What this means for you and I is that the greatest skill we can posses is knowing how to learn, and do it quickly. This breeds adaptability, meaning you can flex with changes, flex your thinking with new information, and allow yourself to grow to meet the challenges presented, rather than stagnating. The faster you can assimilate new information, the more valuable you can be to yourself and the world around you.

Learning at a conceptual level is important

didnt know what was important and what was trivial. They couldnt remember what mattered. Without a conceptual framework in which to embed what they were learning, they were effectively amnesics.

Joshua Foer

There is a key point that differentiates between people that can learn things and retain a good deal of them, and people that can learn A LOT of things an retain nearly all of them. It is subtle in nature but mighty in impact, and is one of the biggest indicators of outcome when trying to learn something new. And it's surprisingly simple.

Do you understand Why?

Imagine yourself in a classroom learning something new, with a variety of other students closeby. Some are picking up the new material quickly, and it seems natural to them. Others are struggling to retain it, and it quickly fades away in their minds. Depending on what the subject is, you could be part of either group.

Imagine again that you are a teacher, and you have a group of students learning a new idea. Some of them pick it up quick, and others struggle. How would you view the students that picked it up quickly versus the students that struggled?

Hold on to these scenarios in your mind for a minute. I'll come back to them.

Learning something at a conceptual level is less about learning how, and more about learning why. It's about finding the underlying pattern of something that ties it to a logical or intuitive representation in your mind. (and in some cases, both). It is about creating an abstraction to represent the idea behind it, so you can base interpretations and decisions on something that makes sense to you.

A great example of this is learning to cook rice. If you just learn the steps - measure rice and water, put it in a pot, heat for x number of minutes, rest, serve - it's still just steps. But if you take the time to learn the underlying concept, it becomes much more useful. For example, if you understand why the rice and water need to be at a certain ratio, and what you are doing is simultaneously re-hydrating and cooking the rice, and you need to keep the lid on so you don't lose cooking liquid, it solidifies a concept into your mind. This concept then works for other things, like cooking quinoa. By learning the concept once, you can change some variables on the input side and come out with something else, and know what is happening in between.

Programming is the same. Walk through the steps of a semi-complex programming task without understanding the key concepts and you can probably get it to work, but the next time you do something similar you are starting from scratch again. This is the fallacy of tutorials that hold your hand too much. It's easy for you when all the steps are spelled out, but once you take the training wheels off and try something on your own it suddenly doesn't make sense.

The alternative is to take the time to consider things like SOLID principles, what the right data structure might be for an input or an output, time complexity of your algorithms (Big O), and possibly a design pattern that can help you out. In a learning setting, look for teachers that take the time to go through these things and give you concepts to go with the code. The result is a much better conceptual understanding of the problem, leading to a cleaner and more elegant solution and a greater understanding of how to solve similar problems in the future.

Refer back to the teaching examples above. Can you think of times that you've been in the fast group and times you've been in the slow group? Can you imagine being the teacher and seeing some student thrive and other struggle? I would bet the difference is conceptual learning vs learning by memorization. The better students get the concept.

You always gain by learning, regardless of what you are learning

"Be passionate and bold. Always keep learning. You stop doing useful things if you don't learn."

Satya Nadella

"I never lose. I either win, or learn."

Nelson Mandela

Did you know that learning to be a better communicator helps you write better code? It's true! The better you can communicate to others, the easier it is to write code that will communicate it's intent to the person that reads it next. That person might be you in a few months or a few years, so it's worthwhile to make sure it makes sense.

Did you also know that learning to write code in modular, cohesive units helps you in everyday life? This has more to do with the concept behind learning to divide code up into units: you are learning how to divide problems up into logical sections, which allows you to think more clearly and deeply on each section. You can also better understand the boundaries between different concepts, and how they compose into the greater whole.

Sound interesting? It should.

Everything you can learn, from the very basics of tying your shoes, to the esoteric heights of theoretical physics, can have an impact on everything else. As you learn, you develop more refined and complete mental models of ... well.. everything! Life is much more intertwined than you think. Your mood can affect the outcome of your day and vice versa. Random things you learned years ago can suddenly apply. As an example, I learned the Pythagorean theorem 20 years ago and never used it - until just a few days ago when I wanted to calculate a CSS offset for a clip path and make it look right at an angle. Useless for 20 years, and then suddenly I wasn't getting that CSS done without it.

So the point is that whatever you learn, it has value and can be applied elsewhere. Sometimes it's obvious. Sometimes it's just as metaphors for other things, or something you can use it to contrast your current thinking and challenge yourself. So take every day and every activity as a learning experience, from classes in school to a boring job, to coding bootcamps and courses. Find connections to other things. Find differences. Find patterns. And don't ever be afraid to learn something new. You never know when it might become useful.

Skills get work done. Soft skills generate opportunities.

Take advantage of every opportunity to practice your communication skills so that when important occasions arise, you will have the gift, the style, the sharpness, the clarity, and the emotions to affect other people.

Jim Rohn

I think this is an important distinction that needs to be made. You can be the most skilled person in the world at any difficult craft (of which programming is one), but what does that get you if you can't work with others? Nobody wants to work with a jerk, or someone who isn't willing to stand up for themselves, or someone who talks in circles and never gets their ideas out. You can have the skills to kick out work very quickly and at high quality, but it would actually be less important than a few simple soft skills. And every soft skill in one way or another, comes back to the basic but critical skill of communication.

To start with, keep in mind that people generally want to help each other, and especially people they have things in common with. This is the basis of communities and tribes. By working cooperatively, groups are better able to find and manage resources, protect each other, and achieve things together that aren't possible for a single person to do. So where you fit into this is actually pretty simple: Be the kind of person that will help others, and develop your communication skills to be the kind of person that people would want in their communities, and people will help you.

What surprises me though, is how many people get this wrong. You see it all the time as the infamous internet troll and the grouchy person on the street. It's not that these people don't want to be part of communities. In the case of the internet troll they probably very much do want to take part, otherwise they wouldn't be posting anything. It's more that they haven't found effective ways to communicate what they want and need to say. The result is that they use negative language and approaches, mostly as a way to make themselves feel better. This is unfortunately at the expense of everyone else around them.

The contrast is the people that get it right. They are easy to spot because they are easy to talk to. They are approachable. You come to trust them. (As long as they are trustworthy) These are the people that become the cornerstones of communities, and as a result, when they are in need, those same communities will move mountains to help out. If you become one of these people, you will find yourself in a position where opportunities are abundant and you have the resources to capitalize on them, because people will want to help you.

So which do you want to be? I think the answer is obvious.

Managing your perspective improves outcomes

"If you change the way you look at things, the things you look at change."

Wayne Dyer

Most people don't think about how they see the world and how their perception can alter the world around them. It seems almost magical and beyond the realm of reality to even think about. But there is a surprising amount of science and logic to support this.

To start, your brain's first and largest job is actually to be a filter. And for very good reason. You have over 7 trillion nerve cells in your body. That is beyond a lot. That is an unthinkable number. And on your skin alone, you have over 1000 nerve endings per square inch. Each of these is constantly reporting information back to the rest of those 7 trillion nerves about things like hot, cold, pain, pressure, and myriad other things.

Do you notice all of those? All some odd million sensory inputs per second? Of course not.

This is because your brain is filtering them out. Only what you need to know for your immediate survival and higher operation comes to the attention of your consciousness. The rest is analyzed for importance, and mostly discarded by lower portions of your nervous system before ever getting near to any real thought process. And this is good, otherwise you would instantly become completely overwhelmed by all the nerve signals, and promptly go completely insane.

But this isn't even the full extent of it. There are parts of your mind that are thinking without you actively doing the thinking. This is your subconscious. And believe it or not, most of the decisions that you make through the course of your day and many of the larger decisions you make in life are made at this level. Some estimates put this at upwards of 90% of all of your decisions. That means it's possible that 90% of your life choices are made without you even being consciously aware. Believe it or not, this is still a good thing. If you had to make all of those decisions, you would still go insane.

Your brain has been designed through eons of evolution to surface only the most important things, and handle as much as possible without using any of the higher order thought cycles of conscious thought. This means that you can learn to walk, or ride a bike, or drive a car, and once you have it down you can do it without thinking about it. There is a part of your brain that is thinking about it, but you can move on to bigger ideas. This is the nature of habits and biases, and by design these things can help you in the long term to instinctively protect yourself and those around you, be aware of things without focusing on them, and ultimately survive.

This then begs the question:

What important things are being filtered out by your subconscious? And what habits and biases are you perpetuating without even realizing it?

The true reality is that we live in an abundant world. There are constant opportunities around us to improve our situation, move closer to our goals, or move the other way by chasing quick fixes, fast money, and the easy way out. Some people see the opportunities and some don't, and this is largely a result of how our perception has been trained.

So you can start training your perception to be different right now. It will take practice and it will take time, but the payoff is there at the end. And most of this process is as simple in theory as adjusting your perspective, which will then lead you the direction you want to go. In practice, it will be a challenge, because you are asking your brain to work differently. It will resist at first, but ultimately will play along if you stick with it.

And as for the example of a job being an algorithm above, this is how you find more of the examples I was talking about. You learn to see them. Once you start, you see them everywhere. You start to see the world as connected systems and processes, and you start to understand the higher level concepts surrounding everything with greater speed and clarity.

Understand that any change will be a process

"The good life is a process, not a state of being. It is a direction not a destination."

Carl Rogers

In a world of on-demand video, fast food, and everything you could ever need just a few clicks away, it's easy to get accustomed to everything being this way. But it you want to change your life, you need to get comfortable with a different pace, and manage your expectations accordingly. Things won't happen overnight. They might not happen on the first try. Failures will allow you to learn, which makes the next attempt more likely to succeed.

It's easy to say "I was that and now I'm this", but that's not how it works. Even if you decide to make an abrupt change, you have to actively curate that change until it becomes part of your habit patterns and subconscious mind. Nothing in this realm will be quick. What I suggest then is to adopt the attitude of guiding the process, and make it open ended. Don't set goals. Set milestones instead. This allows you to keep moving and keep growing, and keep learning and adapting. Ultimately this will let you reach far greater heights than you imagined.

So what about the question that started this post?

"What if you are new? Like started coding 1 month ago? 0 experience. Trying to learn the basics of web dev currently. You don't have any job currently, and already started to burn through your savings. Any advice?"

Random person on the internet

The quote that started this post came from a person that wanted a change and took action to make the change. They are not alone. The situation can be scary, and people can become discouraged quickly.

My response to this person would be this:

Find every opportunity you can to think about things in programming terms
Focus on building your learning ability as priority one
Learning concepts over content will get you farther
Learning is never truly wasted, even if you think you were going on the wrong direction
Soft skills, especially communication, will be key to reaching your goals
Learn to shift your perspective for better opportunities and better results
Understand the process and embrace it

By following these guidelines, I am confident that person will find success. Not just in programming, but in anything they want to do. I hope to see them in the future in the tech community as an active, positive member.

Until then, I'll keep following this advice myself and keep on growing.

Photo Credit to [Sigmund}(https://unsplash.com/@sigmund) on Unsplash.

Exploring The Guild's incredible GraphQL tools

Nik F P — Wed, 15 Jun 2022 16:48:31 +0000

Early on in my journey with GraphQL I was faced with a number of options for implementation. Sure, the ideas behind GraphQL are simple enough, and the official webpage does a very good job of explaining them. However, the implementation was another matter, especially in the Javascript ecosystem. You can start with the basic Express implementation, or jump in to any number of tools like Apollo or Hasura.

The more I dug into it though, the more I wanted to find a modular, cohesive solution that would allow me to build things flexibly. Hasura is linked direct to a data source, so the 1-1 mapping looked like it would cause issues in the way I wanted to store data vs the way I wanted to present the data. Apollo on the other hand, allowed more flexibility in how I designed data transforms in the resolvers, and it seemed that the majority of blog posts and tutorials I came across were using it. But Apollo is heavier in file size and runtime overhead, and also tries to steer you toward a paid offering. So I kept looking.

And then I found The Guild.

Who is "The Guild?"

The Guild is a collective of open source developers that are working together to construct a unified, modular approach to GraphQL API development. On their "about us" page, they outline how they view open source and the work that they do, and their willingness to help and to grow the community.

As of the date of this post, their ecosystem lists 20 different projects under their care. And today, I would like to highlight just a few of them that I have found useful over the past year of exploration.

A quick disclaimer: I am not a member of The Guild, and as of the time of this article I have joined in on some discussion on one project, but that is it. My hope in the next few months is to jump in and help them with anything I can. Their offerings have been a huge help to me and I'm looking for ways to give back.

Let's look at some of their tools, shall we?

GraphQL Code Generator

Official docs here

This was one of the first tools I came across, because I was looking for a way to get Typescript typings for a GraphQL Schema. And this tool does this and much, much more.

The premise behind this one is simple: Feed a GraphQL schema into it, and it will spit out code that you can use in your codebase. And it does this very well. This is achieved through a plugin architecture that allows you to pick and choose what you need outputs for, and then configure them to further tailor the experience. They also maintain a plugin hub of the most common plugins used in the ecosystem, so solutions are easy to locate.

But what if your schema is distributed across several sources? You can still use it, and the generator can be configured to pick it up. Made a mistake in your schema definition? The generator validates the schema before generating the output. If something is wrong, it generates and error and in most cases, even points right to the error to help you fix it.

There is quite a bit more to it though. Starting with the Javascript and Typescript ecosystem, there is a massive list of configuration options you can use to do all manner of amazing things. You can include a type you already have in the generated output using Type Mapping. You can use the "Add" plugin to inject things like comments, imports, and es-lint modifiers right into your generated code. They even have a VSCode extension to run the generator when you save GraphQL files.

The plugin hub has plugins to help you generate code for all sorts of things, from backend stuff like Typescript types and MongoDB ORM schemas, to frontend stuff like integrations for React, Vue, Urql, and even Apollo.

Then, there are also generators for Java and C# classes from your schema, saving users of either language from the hassle of having to keep code aligned between codebases.

And if you can't find quite the right plugin for your needs, they also have documentation on how you can write your own.

GraphQL-Tools

Official docs here

The landing page for GraphQL-Tools calls this "A set of utilities for faster development of GraphQL Schemas". I think this is accurate, but also a bit incomplete. I think that they should also mention that the Tools offering is also the starting point that many of their other tools are built from.

GraphQL-Tools is actually many things that aid in development, but the overall idea is to get you from defining your schema to getting working, executable code as fast as possible. This isn't a full featured server. This is just the pieces that do the GraphQL work. What this gives you is an "Executable schema" that you can then build in to any data or HTTP pipeline to start using GraphQL.

There are a few niceties that the tools provide. The first that I really like is the ability to load schemas from a variety of sources and in a variety of formats. These can be local files, URLS, or even schema fragments plucked out of Javascript files.

The next one I really appreciate is the ability to automatically map scalar types that a data source provides, as long as they have the same name (key). They call this "default resolvers", and this feature saves a mountain of time and upkeep as you build out your resolver maps.

GraphQL-Tools gives you what you need to get the logic portion of a GraphQL endpoint up and running with minimal fuss. But what if you want to take advantage of a more modular architecture, especially as your application grows?

They have something for that also.

GraphQL-Modules

Official docs here

The idea is simple enough: What if you could build your schema and resolvers in small vertical "slices" that would allow you to isolate each piece? This is what you get with Modules. You also get a tool set for testing and mocking, allowing you to build out portions of the schema and related functionality in isolation, test it, and then merge it in with the greater whole.

The basics alone are enough of a reason to start using it, but it's also got support for middleware and Dependency Injection, allowing for multiple setups to test and deploy your endpoint. This means you can start off simple, and then grow into more complex patterns as needed, like utilizing dependency injection to decouple providers from the places they are used, and composing providers as needed to architect more complex operations. All while maintaining testability.

Modules has one more trick up it's sleeve though: It works with the Code Generator mentioned above.

In Modules, you can define your schema using tagged template literals, so your schema slices look like this:

const schema = gql`
  type Query {
    hello: string!
  }
`;

You can set up the generator to use your modules source code as input files, and it will pull out the tagged template schemas, stitch them together into one overall schema, validate the overall schema, and then generate any outputs you need. In the case of Modules, there is a dedicated Generator plugin designed to output just the types you need for the module you are working on. These types can then be used for autocompletion and catching bugs during development time, right in the module they are needed.

So what do you do if you need other functionality in your GraphQL endpoint? You could build it all yourself. OR.... you could reach for a solution built for the job. And The Guild has that for you also.

Envelop

Official docs here

This one is really cool. Envelop is based on a community supported plugin architecture and allows you to compose elements together to get exactly the GraphQL execution layer that you need. What's more, many of the plugins available are maintained by the same teams that offer the tools to begin with, like Auth0, Sentry, and New Relic just to name a few.

What this means is that if you want to add something like auth, there is a plugin for that. (actually many!) If you want rate limiting, add the plugin and configure. You get the point.

Now here is where it gets really interesting. Do you want to add .... GraphQL-Modules, as I just described above? Surprise surprise, there is a plugin for that as well. Now you can write small modules for schema execution, compose them together using the plugin, compose the plugin with other plugins to extend functionality, and get one unified execution layer for GraphQL.

And to this point the whole setup is still framework agnostic, meaning no HTTP server, no preferred data sources, and no opinions on how to use those. We are still just building the execution layer for GraphQL, and you can use whatever server you like. (I like fastify ;), You can use whatever data provider you like including calls to other servers or a database. (or Prisma!) Envelop doesn't care. It just does it's job and makes it easy.

And remember, so far we're built on top of the last several tools mentioned, to make it easy to build, type check, and validate schemas and the execution layer. But maybe you just want a simple to use GraphQL server and don't want to worry about any of the config?

Wouldn't you know it, they have something for that as well.

Yoga

Official docs here

Yoga is where The Guild ties everything together into a simple to use, feature rich, and performant HTTP server. It is opinionated by design, and even then only far enough to get you going in the right direction. All the tools mentioned earlier still work with Yoga, including the full Envelop ecosystem. (Yoga is actually built on top of Envelop) This means that you can get a server going in no time at all. In fact, the quick start in the docs has a server running in 3 lines of code. Three!

Not that the simple server is doing very much. You still need to add your own functionality to it. But since it uses Envelop, this is very easy to do. Build schemas in module files, use the generator to output types, use the types to guide you in building resolver maps, plug the modules into the Envelop plugin, add the plugin to Yoga. A dash of auth, a bit of reporting and metrics, you're looking pretty good in just an afternoon!

What else does The Guild offer?

Well, to start, they have some other very handy things to help you build your GraphQL services. Here are a few examples:

Instead of building the logic out for your own custom scalars, try out GraphQL-Scalars and work with ready made scalar types such as Date, Latitude and Longitude, and IPv4, just to name a few.
Need to merge together data from a variety of sources into one common GraphQL endpoint? GraphQL-Mesh has you covered.
Need some linting for your GraphQL files and schema objects? GraphQL-Eslint plugs right in to EsLint and gets you running.

Then, if you need some help, you can reach out to The Guild on chat and they will jump in and see how to get you taken care of. The people I have connected with have all been extremely kind, helpful, and genuine. And if you need even more help at an organizational level, you can hire them as consultants for training, engineering, mentorship, and code reviews.

Conclusion

The Guild has become my one stop shop for all things GraphQL, and with good reason. The projects they are offering are all precise in scope and work well. The ecosystem fits together nicely. The maintainers are all good people. But perhaps most of all, the options they make available give you a range of choices, from an easy to work with tool set in GraphQL-Tools to the full featured server experience in Yoga. If you are interested in getting started with GraphQL, or if you already have with another tool set, I encourage you to give The Guild a try. You might be surprised at how easy GraphQL can be.

Special thanks to the team at The Guild for allowing me to use their logo as the image in this post. They were very kind in allowing someone who is unaffiliated to use a trademark, and very welcoming when I asked. I strongly encourage everyone to check with the owner before using any image, trademark, or other intellectual property, and to respect their wishes and limitations on use.

Soft Skills checkup: The many phases of Managing

Nik F P — Tue, 24 May 2022 18:25:07 +0000

Oh, to be young again. I remember a time where going to work was simple. My expectations were laid out before me, I was given my tasks to complete, and I completed them to the best of my ability. I punched in, I punched out, I went home at the end of the day and didn't think about work again until I got back the next morning.

How simple things were, and how naive I was. But things would change...

The first phase of management - General Adulting

This is the first management skill anyone really needs to pick up - how to be an adult in general. This means the ability to keep your temper and your excitement under control, recognize when you need to sleep, when you need to eat, when you need to stop eating, generally taking care of yourself, etc. In short, being a functioning human in society. This one is so common that it's not ever really discussed, but it's surprising how many people are missing facets of this. (Present company included). Regardless, this is where you start, but I won't go into this in much detail because civilization in general kinda walks us through this.

The second phase - Managing yourself at work

Sooner or later in everyone's life, they encounter circumstances where they are expected to provide for themselves. This is that four letter word we all like to hate on: WORK. But the first stage is usually pretty easy to get through. You are just starting, so others don't expect you to know much. You are given tasks, you are given resources to complete those tasks, you try to complete those tasks. If you are successful, you get a paycheck and more tasks. If you aren't successful, you get a final check and are forced to search for other work.

This might be as far as you want to go, and that is perfectly fine. Skilled workers can do amazing things, and the best way to get really skilled at something is to practice, and practice a lot. I've seen skilled craftspeople do things that can only be described as high art. In fact, most full time artists fall into this category. By avoiding the distractions of the next management phases, you can grow into the top of your field and far exceed your earliest limitations.

At some point however, you will be faced with a decision - and sometimes even pushed into it - between staying the course at the skilled worker level and just managing yourself, and taking the plunge and moving into the next phase of management -

The third phase - Managing other people - The managing part

This is where things start to get murky. Managing other people is hard. Doing it well is even harder. Becoming a good leader is harder still - and there is a BIG difference between a somewhat capable manager and a good leader. But we'll get to that in a minute.

The first thing you have to know about managing other people is that it takes an entirely different skill set versus just managing yourself. Your responsibilities shift from just accomplishing your tasks to coordinating others and making sure they accomplish their tasks, and still making sure you accomplish yours. Suddenly some of the variables you are working with to accomplish your goals - your staff - have motives and opinions and strengths and shortcomings that you have to work around. You have to find ways to motivate them, train them, and give them the support they need - without alienating them in the process. You have to find ways of getting people to do things they don't necessarily want to do at the time.

The main issue you have to overcome when you get to this point is as follows: People that step up into management are generally considered good at getting things done. But the skills in doing the work are very different than the skills in managing the same work. People often have different opinions and workflows to get the same results, and you have to learn to be tolerant of that. People will surprise you with alternating moments of profound brilliance and moments of downright frustrating behavior. You have to be able to roll with it. People on your team will have internal issues occasionally. You have to be ready for it. All of these are different skills from the last phase when you were just managing yourself.

This is where I have personally seen many people fall on their face. I fell on my face here the first time I was put in a management role. Usually it is a combination of inflexibility when working with a team and personal ego that gets in the way. Taking the attitude of "I'm the boss and I know what's best" will almost always backfire. So there are a few things you can do to get over this hurdle gracefully.

Live by the mindset that management is a service position to the people you are managing. Your role is quite literally to orchestrate the work your staff is doing and to remove any obstacles that are preventing them from working effectively. Your role is to enable them to do their part.
Understand that if your staff has a problem, it's your problem too. You need to be involved in solving it, and you need to take steps to make sure it doesn't come back.
Stay humble. You don't know everything and you never will. Your staff won't do things exactly the way you would do them, but if they get results, this is fine. They will also appreciate NOT being micromanaged. The exception to this one is anything safety or compliance related. Make sure everyone gets home safe and the lawyers don't come calling! Beyond that, learn to live with different work styles and let people get good in their own way.

The fourth phase - Managing other people - The leadership part

Now that you've gotten yourself into a management position and gotten your feet wet, it's time to look at how you shift from just managing people to actually leading people. Things here start to get more conceptual, and will require more words for me to express, so bear with me.

Remember how I said there was a big difference between a capable manager and a good leader? The vast majority of that difference boils down to 3 key concepts: Trust, Communication, and Respect. Everything else that can be considered a hallmark of good leadership will lead back to these concepts. So let's take a look at them.

The first on the list is Trust. This seems pretty straightforward on the surface but it's more complex than you might think. There are a few ideas that fall into this line of thinking that you need to be aware of, including;

Integrity - Do what you say you're going to do. Be honest with people about expectations, and own it when you make mistakes. (And you will!) And be honest with people, first and foremost, or they WILL find out eventually and you won't be trusted again.
Delegation - Passing tasks off to your staff and allowing them to do the work. This isn't just calling out a simple task to do and that's it - that would just be managing - but instead giving giving people meaningful projects and letting them manage the projects on their own.
Self Awareness - Knowing where you are strong and where you aren't. Finding ways to get the sort of feedback that can be much needed reality checks on how your staff sees you vs how you see yourself. Making sure your staff knows that this is important to you and making yourself approachable on this issue.

The second on the list is Communication. This means maintaining a level connection between you and those you lead, and is closely tied to Trust. Some of the ideas that fall under this concept are;

Transparency - Showing the people you are leading that you are working toward the same goals as they are and that you have their best interests at heart. Being honest and frequent with any updates that might affect your staff members.
Empathy - Listening to your staff and showing that you recognize where they are and how they feel. Connecting with them on a level that shows them that they are heard, their input is valuable, and you will keep their input in mind when making future decisions.
Gratitude - Showing honest appreciation for the work that people are putting in, both in getting their own work done and in soft skills like interpersonal communication.

The third on the list is Respect. This one ties in closely to trust and communication, but needs it's own section. Some ideas here are;

Cultural and religious sensitivity - Being aware of the beliefs and customs of others and making sure you don't hinder them. Allowing people to be 100% themselves without fear of reprisal of any kind - as long as they are being respectful to others
Courage - Thinking highly enough of people to have hard conversations with them, and trying to do so in the most delicate way you can. Also standing up for your team to others - especially your own bosses.
Differences of opinion - Understanding that people are different and being aware of how this can be challenging, but also very beneficial. Listening to all sides of an argument before deciding on a course of action.

All of these ideas converge into a set of principles that you can take with you to establish yourself as a leader.

Accountability - You are accountable for the welfare, success, and failure of your staff. You know this and you own this, and you take it seriously. You keep yourself accountable to them to constantly do better, communicate better, and lead better.
Mentoring - You readily become the "blueprint" for a leader to the people you are leading. You show them how to do it right, and quickly and fully admit when you do it wrong. You show strength in humility and constantly work to assist your team in their own learning journey. You strive to help them get better than you are, and challenge them to be excellent leaders in their own right. You provide advice on how to make difficult decisions and handle tricky situations - not by telling people what to do - but by advising on how to think it through on their own and come to their own resolutions.
Coaching - Different than mentoring, and also different than training. Training is a management practice. Coaching is bigger, harder, and more expansive. Coaching begins where training leaves off. Coaching is the set of activities surrounding helping people to take initiative on their own, grow past their limitations, and work around their own shortcomings. It is challenging and inspiring people to push themselves to be better, independent of your input or anyone else's. It's how you make the best even better.
Community - Creating a sense of culture in the team. Helping people to find common ground and celebrate differences. Helping people to learn from each other and want to learn from each other. Helping to foster a sense of shared ownership.
Mission - Creating an atmosphere and a set of expectations that leads to a culture that moves in the same direction. Creating common goals and a roadmap that your team can use to steer their decisions and create their own metrics. Having a clear mission allows team members to create a sense of autonomy, and the more clear the mission is, the more autonomous they can be since they will know if they are going the right way or not. This give people a sense of agency in their own work and makes them feel that they are part of something larger than themselves.
Vision - Being able to see beyond what is "now" and imagine what is next. Finding the possible in sometimes impossible things, and then bringing those things into the mission of the team. Anticipating change and being proactive rather than reactive.

There are also some gotchas that you should be aware of when in any leadership role.

You don't need to be friends with everyone on your team. But you DO need to be their ally. They need to know you have their back and that you would never intentionally do anything not in their best interest. Fail to stand up for your team and you erode trust and integrity and convey mixed messaging on priority. You can be closer to some than others on a personal level, but be aware of the next point.
Consistency in how you deal with your staff is critical. You can't have favorites. If one person is getting more of your time and attention than others, or being favored for choice assignments, you aren't doing it right. Fairness needs to be maintained at all levels, so that your staff as a whole knows that they can expect fair treatment in good times and bad. On this same point, preferring certain team members for certain things based on ability is acceptable, as long as you aren't leaving others behind and are still providing support team wide.
You need a succession and contingency plan. Even if you don't think you do. What does this mean? Ask yourself these questions:
- If you were suddenly required to leave for 2 weeks, and couldn't work at all, what would happen? Would your staff's work grind to halt? If so, this is an indicator that you have just been managing and not leading. If they could continue producing quality work in your absence, chances are you've been leading them, at least to some degree. If they could do so with zero outside instruction from your boss or leaders of other teams, chances are you have been leading them well.
- If you were suddenly required to leave for 2 months and couldn't work at all, what would happen? This should be harder for the staff to manage on their own, but if you have led them well, they should be independent enough to continue until you can get back to work.
- If you were to leave permanently, what would happen to your staff? How long could they continue on? Would any person in particular be the expected next leader? Would total chaos ensue? How do you prepare your staff for this scenario?

If you can do a decent job of handling all this, you will see your staff flourish and do amazing things. You will also probably eventually get pushed into the next phase, ready or not. Which brings us to....

The fifth phase - Leading leaders

Welcome to the world of organizational leadership. This will take exceptional skill in creating a sense of shared purpose, mission, and drive. This will take influence at a strategic level. This will take everything you've got!

Actually it's not that bad. But it does require a foundational shift in thinking about the way you approach the work. At this stage, you are aware of the work being done, but typically not engaged in the work being done. You are steering the ship, so to speak. You are identifying opportunities for the entire organization, and then positioning to take advantage of those opportunities. You are leveraging the leadership skills of others to get things done at a high level.

What this represents at it's core is taking everything you would have learned in the earlier phases of management and scaling them up, and making them an official requirement of your job in the process. If you weren't an effective leader before, you won't be at this level either, and the effects will multiply with the scale of what you are doing. However, if you did well in earlier leadership positions, this is where you can really soar.

To help you out in this front there are a few questions you can seek answers for to help you make decisions and lead effectively.

What is the core, essential purpose of the organization? In other words, what are you trying to accomplish to complete organizational goals? I'll give you an example: Starbucks. You might think their core purpose is to sell coffee, but it's not. Their core purpose is to provide a consistent, pleasant experience every time you visit, no matter where you visit. Other places sell coffee for cheaper, others have better coffee, but Starbucks uses coffee sales as a part of a greater experience, and by shifting their thinking they became the largest coffee shop chain in the world.
What opportunities can you uncover and how can you align the organization to capitalize on them? Another example: Amazon Web Services. They were the first to identify that their extra compute, database, and storage resources could potentially turned into services that could be sold as on demand, scalable cloud infrastructure. that realization led to a portion of Amazon that accounts for $70 billion in annual revenue. But it took a large amount of work in decoupling the services to be able to sell and scale as needed, and leaders with the vision to see the opportunity to begin with, and then see it through to something that now runs the majority of the internet.
How do you align the vision and mission of the leaders you lead to match your own vision and the direction of the organization? This one comes down to personal style more than anything else. You have to find your own brand, and find a way to create a positive connection between your teams and the core mission of the organization. It's the culmination of all the other skills mentioned so far, blended with your own brand of delivery. If mastered, you can be among the best of the best and lead the best teams around.

Conclusion

I hope you have enjoyed my long winded tour through management. Whether you are just beginning or a seasoned pro, it helps to see the process at a high level, from the beginning to the end. And remember, these are skills that can be learned and they take time, so don't get discouraged and don't give up. Learning to manage and lead will help in all aspects of your life and give you a greater appreciation of the good managers and leaders you have worked with. And as always, drop a comment below with anything you wish to add.

GraphQL as a powerful abstraction layer

Nik F P — Mon, 02 May 2022 19:38:06 +0000

By now I'm sure you've heard of GraphQL. There is a good chance you are even using it in something, or at least you have in the past. There are lots of tutorials, conference talks, blog posts, and even books about it. And yet, in everything I have come across, one of the biggest benefits that GraphQL provides is often overlooked. So I thought I would talk about it today.

A brief recap of the obvious benefits of GraphQL

Let's start with a quick recap what GraphQL gives you that you commonly see around the internet. If you would like to know more, please visit the official GraphQL page here

Defined schema - This is beneficial in that you have clear line of communication between the server and the client. Types of data for inputs and outputs are defined through a set of base primitives that can be built up to represent complex objects and relationships. The schema can also be stepped through interactively with tools like GraphiQL, which also allow markdown style notation on fields and queries, so schemas become self documenting.
Clients can shape data as needed to speed development - Since the GraphQL paradigm allows clients to request data in the shape that they need, only what is needed is sent in the response. This leads to lighter payloads over the network on each request, which in turn provides quicker API responses.
Solves the n+1 problem - Related data can be grouped in a single request and response, meaning the "waterfall" problem of requesting connected data through a series of requests is no longer an issue.

These are all huge benefits to be sure, but there is one thing that could be added to this list that might help people to better understand and adopt this technology:

GraphQL is a powerful boundary between layers of abstraction

This is the way I see GraphQL in my head: the GraphQL schema is a wall with defined ports. On one side of the wall, you have your server or other API functionality. On the other, you have your client. This wall happens to align perfectly with the network between server and client. (Not getting into the low level details of running a server - receiving HTTP request and sending responses, CORS, etc.) So the schema you design for GraphQL represents the border between 2 distinct contexts at 2 distinct layers of abstraction. It also provides the interface, the protocol, between these layers that will allow them to communicate.

Now, to be clear, you could possibly achieve something similar with other protocols, and there have been quite a few attempts to so this in various ways. gRPC from google and their protobuf files is one such attempt, as is OpenAPI. Each of these has their merits - and weaknesses - that must be considered before use. In my opinion, neither of these really hit the mark though. You still have the problem of too much or too little data on each request, leading to multiple requests. Furthermore, especially in the case of gRPC, the more detailed you make a back end service and it's related endpoint, the more a client knows about the server implementation, which as we all know is best avoided in accordance with best practices.

GraphQL give us a more elegant solution and a clear dividing line between front end and back end.

GraphQL enforces separation of concerns at a high level

With GraphQL as the wall between the server and client side, neither side needs to be concerned with what the other is doing. Client concerns stop at the GraphQL schema. Server concerns likewise stop at the same schema. So you have effectively split the two by both layer of abstraction and implementation details.

Now the front end is only concerned about the UI portion and anything related to displaying information from the server. What the server does to generate data or save it in the event of a mutation isn't relevant - it can't be relevant, because the client's ability to interact with the data stops at the GraphQL schema.

Similarly, the server can't know what the client is doing with the data that the server send out, or how the client is collecting data for mutations that are submitted. Again, it's all on the other side of the wall and is no longer relevant. As long as the server is fulfilling it's duty to respond to the schema, it's work is done regardless of what the client is up to.

This gives the people working on each side of the wall Autonomy. Once something is defined in the schema, each side can begin work without thinking about the other, and can work on things in whatever order they see fit at whatever pace they see fit. The only requirement still in place is that the GraphQL implementation on the back end be functional by the time the front end deploys with queries to the schema. That's it.

Further, adding to the schema is as simple as adding a type to shape the data, possibly some queries and mutations for said type, and connections to other types if applicable. The schema is still backward-compatible with existing client code as long as nothing is deleted, so running production systems can adopt an asynchronous approach between front end and back end teams. Change management becomes much easier as a result.

GraphQL discourages coupling between server and client

The separation of concerns and related autonomy mentioned above has another added benefit: Once the server and client have a strong separation of concerns they are inherently less coupled to each other. In fact, the client could be completely rewritten in a different framework and the server wouldn't need to change a thing. Likewise, the server could be rewritten in another programming language or divided into microservices, and the client would never know. This is loose coupling in action. Since the schema becomes the known standard that all sides are working toward, nobody needs to know what's on the other side of the wall for the system to function.

GraphQL increases testability

Yet another benefit of high abstraction is that code is easier to test. On the client side, since the schema of the data from the server is known, it is very easy to mock inbound data to run tests independent of the server. Failure states can also be mocked because it becomes clear what those states look like. When it comes time to go to production, as long as the GraphQL API is running, the client just needs to point to it and the rest should work as expected.

On the server side, the schema defines all known entry points to the data and all known methods of combining data in a request, so again it's easier to mock test inputs to get outputs and a running client is not required. (I should say relatively easier - testing these kinds of systems is not easy any way you slice it) Error states are defined, possible null values are defined, so the whole thing becomes easier to understand and reason about. As a result, it's easier to build out tests and verify the behavior of the server, no client required.

I hope you find my take on Graphql as an abstraction useful. Thinking about it this way has helped me to better understand and adopt the technology and to build more flexible codebases as a result. If you have anything to add, please drop a comment below.

Learning to code isn't just for developers

Nik F P — Fri, 22 Apr 2022 03:45:30 +0000

First, a confession

I don't get paid to write code. I have been involved in tech for about 7 years now as a hobby, with my interest building more each year. I don't work in a tech related sector. My day job is challenging and rewarding and I have enjoyed it, but I see myself migrating to software development at some point in the future regardless, because I enjoy software more.

So I'm not a professional dev. That is OK. I can still engage with the tech community, I can still learn and grow, and you can too! This is the point of this post. I want to help people that are new on their journey or just curious about tech to feel more comfortable getting involved, regardless of how serious they are. With that in mind, I've compiled a list of things that I wish someone had told me when I started my journey that would have helped me to feel more open and confident, and ultimately learn faster and contribute more. So here we go.

You don't have to be a pro to be a part of the tech community

This is the first point I want to make because I feel it's the most important. It also addresses a misconception that I had when I got started. Through a mix of misinformation and imposter syndrome, I felt like I couldn't measure up for a long time because I hadn't learned enough, hadn't gone to school or a bootcamp for a tech role, and was just learning on my own as a passion project. I have since come to realize that I was wrong, but it took longer than it could have and I think I missed some of the enjoyment I could have gotten by letting go of my insecurities sooner.

So let's clarify: Not everyone involved in tech is doing it for money. Many people aren't involved full time. Most have other interests that are at least as important and relevant as their involvement in tech. Most of them are quite nice and very helpful. Not only is this a good thing, but it's critical to the long term success of tech culture. At the core of it, technology is used to solve problems, so people bringing in thoughts and knowledge from other aspects of daily life is important to recognize and work on the problems tech is solving. And by helping each other, we can all gain from each other's experience and solve these problems faster.

This leads me to my next point:

Everyone got here on their own path, including you

This might seem self explanatory, but it's often overlooked in the beginning. It is important to remember though, because this means there is a huge diversity in background knowledge, experience, and education in the tech community, which is a very good thing! Some people have tech as a direction in their lives from a very early age, some people decided to make a career change and started studying for a tech job, and others (like me) got into tech almost by accident, or as a side effect of something else.

I've heard stories of people in university programs for other sciences that were using simple programming processes to do calculations and help with their work, and realizing that they liked writing the code more than the work they were doing. I heard a story of someone who needed to learn a bit of code to program home automation systems for work, and once they started writing code they never looked back. For me, I was frustrated with trying to automate a process for data management at my day job, which led me to experiment with MS Access, which led me to scripting with Visual Basic for applications. I very quickly learned that I really liked writing the code, so off I went, learning to code.

The point here is to remember that how you got here doesn't really matter. The important thing is that you are here, you are welcome, and you are part of a community where your input is just as valid as everyone else's. So don't be afraid to engage, learn, and ask questions. and if you have an answer to a question someone else asked, help them out.

Which leads me to my third point:

It's OK not to know something!

When you are first starting out in tech, most of what you see and hear will be foreign to you. You will probably feel very overwhelmed, make lists of buzzwords and jargon that you come across, try to research all the things when you can, and end up feeling more overwhelmed as a result. If tech isn't your primary focus, this feeling can be stronger and you can start to feel like there is no way to keep up, and you should give up instead.

My advice is to slow down!

Start with what you are most interested in and just learn the fundamentals of that one thing. Ignore the buzzwords flying around as much as you can. If you are missing some knowledge or resources critical to that topic, usually what you are missing will make itself apparent pretty quickly. You can then dig deeper on the missing parts to flesh out your knowledge as you go. This will keep you focused as close to the task at hand as you can get. At first it will seem slow, but you will be practicing the concept you are working on and practicing how to get information and make sense of it in a more efficient and effective manner. As you practice this, your ability to learn and find solutions for yourself will get stronger, and you will start to gain more confidence. AND as a bonus, any skills you pick up tend to translate to other things, so the more you learn, the faster you can pick things up. But more on that later.

Let me give you an example. Let's say that you wanted to get started in tech and you heard React is a good thing to know to position yourself for a job and future growth. So you start looking into react. It looks cool, and you want to keep learning and growing. Great! However, with no prior tech knowledge you will probably hit a wall with the basics of Node for the development environment, HTML for the markup syntax, and Javascript for the creation of React components and understanding how things work. If you then dig deeper, you will find that Node also relies on Javascript. The result is that by deciding on a React path, you will be led to learning Javascript fundamentals as well as some HTML and CSS as prerequisites to understanding React. So Javascript, HTML, and CSS are where you start, and then you use what you have learned to dive in to React, Node, and beyond.

And if you are still feeling like you can't keep up, this next point will help:

Remember that you can't know everything!

Seriously, you can't just "know tech". Tech has become too big, with way to many paths out there, and it's no longer possible for any one person to wrap their head around all of it. And even if they did, things move so fast that by the time that person stuffed it all into their head, the vast majority of the information would be outdated. Trying to keep up with everything is a great recipe for burnout. So I recommend you employ this simple set of rules:

If you hear about it once, make a mental note and move on.
If you hear about it all the time, but don't know you need it, look into it briefly in your spare time. If you don't need it, move on.
If you hear about it all the time, look into it, and find out you need it, go down the rabbit hole and learn it.

What this will do is force you to filter out all but the most relevant topics to the path you are on and your current place on that path, even though many more things have been mentioned.

Here's an example. Through the course of a day of listing to a podcast episode, reading a few blog articles on my lunch break, and watching one video on YouTube, I've come across the following buzzwords that I can remember just off the top of my head:

vue, react, javascript, typescript, svelte, markdown, css, docker, github actions, Heroku, Vercel, discord, Prisma, Postgres, Nodejs, Go, Rust, Vite, Google cloud Storage, Lerna, Husky, Yarn, PNPM, Nextjs, Sveltekit

That is 25 things in the periphery of my exposure and I'm sure I'm missing some things. How many of these are relevant to the stuff I like to work on? Actually most of them. But how many are relevant to the things I'm working on right now? Only 8, and I'm working on a full stack application with database access, separated server and client, and a common package for validation. If I was doing something strictly on the front end, like say a Minesweeper clone, it would be down to maybe 3 or so.

So by restricting what I let myself dive into using the above rule set, I keep from getting overwhelmed, I keep learning, and I am actually more productive overall when I have a chance to work on something tech related.

With this in mind though, you should also consider the next point:

It's OK to jump around a bit, especially in the beginning

The reality is that deciding where you want to put your time and energy can take some trial and error to figure out. Different languages have different strengths and quirks, different frameworks are optimized to different mindsets and to achieve different goals, and sometimes what you are doing just doesn't make you happy. So try something else. I haven't come across a language or framework in the last 5 years that doesn't have decent free resources and tooling to get you started. In the case of Svelte, the official website is even downright amazing. Your limits really are just your time and energy, and if something doesn't give you a sense of joy and accomplishment, you can cut your losses and start on something else. As long as you are learning something, you are still learning. AND it's helpful to see how different technologies approach the same problems, which gives you a greater depth of experience to work from.

Also, most of the core concepts also translate, so you'll never really be starting from zero again. As a quick example, assigning a variable in Python vs C# might be different in syntax, but at the core you are doing the same thing: storing information for later use. All programming languages will have that in common with possible variations in how you use it, but understanding what you are doing and why means you are already ahead of any true beginners. In short, there is no learning that is truly wasted.

Here is an example from my own experience. When I started seriously learning to write code, I started with C#. (I know I mentioned Visual Basic above, but I figured out quickly that VB was not ideal). I wanted to learn an "enterprise" language and at the time, Java and Oracle were having a feud and Java's future was in question, and Microsoft had chosen to open source just about everything in .NET. All things considered, C# won the coin toss. Off I went, learning all kinds of things, and doing so in the Object Oriented way that C# is designed for. I got really far with this and learned a lot of great concepts, but when I started trying to build out my first substantial application, I always felt like I was swimming upstream.

Then I decided I should try Javascript, mostly because it was everywhere, so I figured something good must be going on. I learned basic Javascript and realized that the basics of programming such as variable assignment, control flow, etc. all loosely followed the same concepts as C# even if the syntax was a bit different. Then on to React and Node, and I was able to get some things done, but the dynamic typing in Javascript always bothered me. I did like the more functional paradigm though, and the idea of creating flows for data through an application and passing functions around really held my attention.

Then I decided to give Typescript a shot. And it clicked. I had found something that felt like a great fit. I had type information and compile time errors unlike plain Javascript, but also had the ability to use a more functional style which wasn't a strong point in C#. A lot of the work that I do with types was informed by my initial work with C#, so getting into more advanced concepts in Typescript like Generics and conditional types was easier to pick up than if I had started at zero. As a result, I got more confident and productive, and now I feel much better taking things from an idea to something that works.

And lastly, I learned React with Typescript and was productive, but to me it seemed like there was a lot of boilerplate to get things done. Enter Svelte. I tried it, the learning resources were great, the development experience was great (Especially with Vite!!), it worked well with typescript, and it's now my preferred front end framework.

Your journey will be different, but you can see my point - no learning path is the wrong path, and your path will likely wander.

You will get the most reward from solving problems that affect you

This is where the title of this post comes into play the most. When you find problems that you can solve by writing code, and then you solve them, you get an awesome feeling of accomplishment. It's even better when you are solving something that at first seems unrelated to tech. For me, there are 3 things I put together that I really enjoyed and were very helpful.

The first was to solve a problem our office was having of needing to fill in fields on PDF forms and print the forms out for our field staff every day. On big days, this process could take a couple hours for one staff member, it was error prone, and everyone hated doing it. So after getting fed up with the process enough times I decided to see if I could find something more efficient. About a week later, working on the problem in my spare time, I was able to get a working demo going of an electron app that could fill out the forms for us. It wasn't pretty, but it was stable and easy to use. So we started using it, and until we changed our process it was very useful and saved us a ton of time. And I had fun making it.

The second was a simple Node application to consolidate and merge some data from our company cell phone plan. We had one employee that was using the bulk of the data and most of the calls and texts were to their phone, so we wanted to see who they were talking to so much. The files from the cell phone carrier were in csv format and were kind of a mess, so spreadsheet applications weren't working well. So I wrote something that could take each row of the csv, figure out which one of four record types it was, parse the data and store the record in the appropriate array, and then at the end output a new csv file with all the data standardized. After that, the new file worked with Excel and allowed us to sort and filter our way to an explanation: Our employee was talking to their significant other at a 2:1 ratio over all other calls, texts, and emails combined. This could have been done other ways, but I wanted to write the code, interact with the file system, and see what I could come up with. And it worked, it only took me about an hour and a half making it faster than trying to read through all the records manually, and I had fun.

The third was another simple Node application to rename files. I had a large number files that had metadata embedded in the filenames, and only some of that metadata was useful. The rest was extremely dense and hard to work around. The names were consistent, so I made something that read in all the file names as strings, parsed out the data I needed, used the data to create a new file name, constructed an object that had the old file name and the new file name, and added it to an array. Then I looped through the object array and used the old and new file names to rename each file to something we could all make sense of and search through. Again, there are other ways to do this, but it worked and was much faster than manually renaming files, and I had fun.

You can see the theme here: What I was doing was fun for me, because it challenged me and allowed me to solve problems that I was having. This in turn kept me motivated.

So go out and make cool stuff!

Do what give you joy. Make gizmos that do stuff with Arduinos, or beautiful user interfaces, or services to process real time high volume data streams, or Machine Learning models to predict the price of eggs in China. Maybe build a game or a joke generator. Clone Instagram in an obscure programming language. Whatever gets you excited. Have fun. Keep learning. Apply it to your life even if your life isn't based in tech. And most of all, remember that code isn't just for developers. So learn to code, even if you aren't a developer!

And if you feel inspired, drop a comment below on your experience. I'd love to hear what you are making with code!

Thank you to:

Unsplash, for providing great free stock photos. Link to the picture used at the top of this post can be found here