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, and I’m finding ways to build tools and incorporate programming into my day job.
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.
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 questions, 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
