<![CDATA[ Life lessons - freeCodeCamp.org ]]> https://www.freecodecamp.org/news/ https://cdn.freecodecamp.org/universal/favicons/favicon.png <![CDATA[ Life lessons - freeCodeCamp.org ]]> https://www.freecodecamp.org/news/ Eleventy Sun, 10 May 2026 22:20:23 +0000 60 <![CDATA[ Here Are 850+ Ivy League Courses You Can Take Right Now for Free ]]> https://www.freecodecamp.org/news/ivy-league-free-online-courses-a0d7ae675869/ 66d45eb473634435aafcef96 Tue, 14 Jan 2025 06:00:00 +0000 By Dhawal Shah

The 8 Ivy League schools - Harvard, Yale, Princeton, Columbia, Cornell, Dartmouth, Brown, and the University of Pennsylvania - are among the most prestigious universities in the world. In 2025, all 8 Ivy League schools are ranked in the top-20 of the U.S. News & World Report national university ranking. While these institutions are highly selective and difficult to get into, they offer many of their courses online for free.

Using Class Central's database, I've compiled these courses for you. In total, Ivy League schools currently offer over 1,850 courses that have attracted 60 million enrollments and 1.7 million bookmarks. Looking at the data:

  • Brown University (81 courses)

  • Columbia University (56 courses)

  • Cornell University (14 courses)

  • Dartmouth College (231 courses)

  • Harvard University (357 courses)

  • Wharton School of the University of Pennsylvania (3 courses)

  • University of Pennsylvania (21 courses)

  • Princeton University (8 courses)

  • Yale University (1096 courses)

25a4660a-3947-437a-8781-c7932f6f2c86

The Class Central database has over 250,000 online courses.

For those interested in staying updated on new Ivy League course offerings, you can "Follow" our dedicated collection on Class Central.

Note that figuring out how to audit a course for free on platforms such as Coursera can be a bit confusing. So my colleague Pat and I have written a dedicated guide: How to Sign up for Coursera Courses for Free.

In this guide, Harvard's CS50 courses clearly stands out - the first CS50 course has attracted over 6 million learners on edX alone. For that reason, we created a dedicated guide: Harvard CS50 Guide: How to Pick the Right Course (with Free Certificate) where my colleague Manoel reviews the complete lineup of 14 courses, including 10 that offer free certificates of completion.

Also, recently we published a free developer certificates article with thousand of courses, including several from freeCodeCamp, Google, Microsoft, and Harvard.

More Free Certificates

free-certificates-banner

If you don’t find what you need here, browse Class Central’s catalog of over 250K courses or visit our thematic collections:

Without further ado, here are all the free online courses offered by Ivy League institutions.

Brown University (81 courses)

Columbia University (56 courses)

Cornell University (14 courses)

Dartmouth College (231 courses)

Harvard University (357 courses)

Wharton School of the University of Pennsylvania (3 courses)

University of Pennsylvania (21 courses)

Princeton University (8 courses)

Yale University (1096 courses)

]]> <![CDATA[ How to Excel as a New Developer and Beat the Dunning-Kruger Trap ]]> https://www.freecodecamp.org/news/the-dunning-kruger-effect/ 66ba119b7282cc17abcf0c6c Mon, 23 Oct 2023 21:00:12 +0000 What is the Dunning-Kruger Effect?

Hey there, fellow developers! Imagine this. You've just landed your first tech job or maybe you're fresh out of a coding boot camp/university. You're pumped, excited, and ready to show the world with everything you've got.

But wait a minute—ever heard of the Dunning-Kruger Effect?

No, it's not the name of a cool Unicorn company or a secret programming language. It's actually a psychological phenomenon where people think they know more than they actually do. And trust me, it's super easy to fall into this trap when you're new and eager to impress.

Why should you care? Well, this mindset can actually hold you back from truly excelling in your new role.

But fear not, we're going to dive into how you can navigate this tricky terrain and come out the other side not just confident, but truly capable of being an awesome developer.

The Excitement of the First Job

Remember the moment you saw that "Congratulations" email? Your adrenaline kicked in, your heart races, your palms got a little sweaty, and you probably did a mini happy dance (at least I did).

You felt like you had just won the lottery, and in a way, you did! You've spent a tremendous amount of effort to reach that position and finally, you're now part of the tech world.

Moving into that first week on the job, you walked into the office (or logged into that Zoom call) with your best "I'm a serious coder" face. Your new workspace is all set up – imagine your own standing desk, complete with dual monitors and a mechanical keyboard that makes the most satisfying click-clack sound.

You're given your first project or task, and you think, "Pssh, I've got this. How hard can it be?"

You're filled with excitement and ready to tackle anything that comes your way. Debugging errors? Bring it on. Complex algorithms? No problemo. You feel invincible, like a coding wizard.

But here's the thing—this is exactly where the Dunning-Kruger Effect starts to creep in. You feel like you can conquer any coding challenges thrown your way. But is that really the case? Let's find out.

Sponsored by Google Chromebooks _Photo by [Unsplash](https://unsplash.com/@brookecagle?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Brooke Cagle / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

The Reality Check

A couple of weeks into your job, something starts to feel... different🫤. That initial rush of "I can do anything!" starts to fade as you dive deeper into your projects.

You encounter coding problems that your bootcamp or university courses didn't expose you to. You find yourself Googling terms you've never heard of and staring at error messages that might as well be written in a completely unfamiliar language.

Remember that "simple" task you were so confident about? Well, it's not looking so simple anymore. You start to realize that the codebase is a labyrinth, and you're just a tiny mouse trying to find the cheese. You're attending meetings where people casually throw around acronyms and jargon. You nod along, but inside, you're thinking, "What are they even talking about?"

This is the moment—the reality check. It hits you like a ton of bricks: "I have so much more to learn." And let's be honest, it's a humbling experience. You might even feel a bit discouraged or overwhelmed. That coding wizard wand you were holding seems a little too weak for you now.

But hey, don't beat yourself up. Many developers face this problem including myself. It's the universe's way of saying, "Welcome to the real world of tech. It's time to level up." And guess what? This is where the real growth begins.

Why the Dunning-Kruger Effect is Actually a Good Thing

Well well well, so you've hit that reality check. You're feeling a bit down, maybe even doubting if you're cut out for this tech life.

But here's the twist: that uncomfortable feeling, that realization that you're not a coding wizard (yet), is actually a good thing. Yep, you heard me right. It's good, and here's why.

The Dunning-Kruger Effect isn't just some fancy term psychologists use to make you feel bad about yourself. It's a natural part of the learning journey. Think of it as your brain's way of saying, "Hey, slow down, buddy. There's more to see here."

When you're at the peak of "Mount Stupid" early on in your career, as shown in the image above, you don't know what you don't know. But the moment you start to doubt, the moment you feel that discomfort, is when you become aware of your limitations.

You see, the Dunning-Kruger Effect can be your wake-up call, your catalyst for genuine growth. It's like a checkpoint in a video game that says, "Are you sure you're ready for the next level?" If you are, you'll need to gear up, learn some new moves, and maybe even team up with others who can help you on your quest.

So, instead of seeing this psychological effect as a pitfall, view it as a springboard. It's a chance for you to pivot. It's your opportunity to identify the gaps in your knowledge and skills, and then hustle to fill them.

You'll start asking questions, seeking feedback, and practicing like never before. Before you know it, you'll be climbing up the slope of "enlightenment," where you not only gain expertise but also the wisdom to recognize there's always more to learn.

In a nutshell, the Dunning-Kruger Effect is not your enemy. It's more like your brutally honest friend who tells things like they are and keeps you in check, so you can become the best version of yourself.

And let's be real, we could all use a friend like that, especially when we're just starting to explore the tech world.

Image _Photo by [Unsplash](https://unsplash.com/@grzegorzwalczak?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Grzegorz Walczak / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Practical Tips to Overcome Overconfidence

Now you've established that the Dunning-Kruger Effect can be your ally. But how do you move from that awkward phase of overconfidence to actually getting better? Here are some down-to-earth, no-nonsense tips to help you get there.

Self-Assessment: Know Yourself

First things first, take a step back and honestly evaluate your skills. People always say that awareness is the first step to self-improvement. No sugar-coating, no inflating your abilities. Use online quizzes, coding challenges from websites like Leetcode or HackerRank, or even old-fashioned pen and paper to jot down what you know and what you don't. This will give you a clear picture of where you stand.

scrabble, scrabble pieces, lettering, letters, wood, scrabble tiles, white background, words, quote, letters, type, typography, design, layout, focus, bokeh, blur, photography, images, image, self-image, self-awareness, mediate, identity, identity crisis, self help, find yourself, finding yourself, understanding, therapy, mindfulness, roots, personality, authenticity, honesty, principles, id, ego, psychiatry, philosophy, _Photo by [Unsplash](https://unsplash.com/@brett_jordan?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Brett Jordan / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Seek Feedback: The Mirror Doesn't Lie, But It Doesn't Tell the Whole Truth

Your own assessment is a good start, but it's not enough. You need external perspectives to get a fuller picture.

Don't be shy—ask for feedback from your colleagues, mentors, or even your local online communities. Listen carefully, keep an open mind, and don't get defensive.

Remember, feedback is a gift, even when it stings a little. Ensure to only take feedback that are directed at your skills rather than being personal in nature.

Image _Photo by [Unsplash](https://unsplash.com/@wocintechchat?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Christina @ wocintechchat.com / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Set SMART Goals: You Can't Improve What You Don't Track

You've probably heard of SMART goals: Specific, Measurable, Achievable, Relevant, and Time-bound. (Source: Kat Boogard) Use this framework to set targets for yourself.

Instead of vague goals like "I want to get better at JavaScript," aim for something more concrete like, "I will complete a JavaScript project that involves API calls within two weeks." or "I will learn how to integrate with Stripe API by building an e-commerce website within this month."

You can use roadmap.sh to track your progress and get a general roadmap, too.

Ideas waiting to be had _Photo by [Unsplash](https://unsplash.com/@kellysikkema?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Kelly Sikkema / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Break It Down: One Step at a Time

Big goals can be overwhelming, especially when you are learning something from scratch. Break them down into smaller manageable tasks that you can tackle daily (preferably) or weekly.

Each small win will not only boost your confidence and motivation to stay consistent but also give you a clearer path forward.

Image _Photo by [Unsplash](https://unsplash.com/@bruno_nascimento?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Bruno Nascimento / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Keep Learning: The River Never Stops Flowing

The tech world is always evolving, and so should you. Make learning a habit. Whether it's reading articles, watching tutorials, taking up new courses, or building new projects, keep that brain of yours hungry for more knowledge.

Just make sure that you show up consistently:

Reflect and Adjust: Rinse and Repeat

Every now and then, take some time to reflect on your progress. Celebrate your wins, no matter how small, and learn from your setbacks. Adjust your goals and strategies as needed and keep going. Be strict for yourself but do not beat yourself down too hard when a target is not met. Progress is progress no matter the context.

Overcoming overconfidence isn't about downplaying your abilities. It's about fine-tuning them. It's about turning that initial spark of enthusiasm into a steady flame that lights your way through the ever-changing landscape of tech. And trust me, once you get the hang of it, there's no stopping you.

Check out more photos from my time in Yangshuo at www.morethanjust.photos/yangshuo _Photo by [Unsplash](https://unsplash.com/@joshuaearle?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Joshua Earle / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

The Path to Becoming Outstanding

So, what's the endgame here? Well, overcoming the Dunning-Kruger Effect isn't just about avoiding embarrassment or getting through the day without a hiccup. It's about long-term growth. It's about becoming the developer who not only knows their stuff but also knows what they don't know.

That's a powerful combo, my fellow friends. It makes you more competent, more hirable, and let's be honest, a lot more fun to work with.

Two middle age business workers smiling happy and confident. Working together with smile on face hand giving high five at the office _Photo by [Unsplash](https://unsplash.com/@krakenimages?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">krakenimages / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Conclusion

Alright, let's wrap this up. The Dunning-Kruger Effect is like that awkward puberty phase we all go through. It's uncomfortable, a bit embarrassing, but also completely natural.

Just like Neo in "The Matrix," you have a choice. You can take the blue pill, stay in your comfort zone, and believe whatever you want to believe. Or you can take the red pill and embrace the awkwardness, the bumps, and the steep learning curves.

Taking the red pill means acknowledging that there's a whole world of programming wisdom you've yet to discover. It's a commitment to learn, grow, and become not just a better developer, but an outstanding one.

And guess what? You've got what it takes 🫵🏻, so let's commit to excellence, one repo at a time! 📦

Image _Photo by [Unsplash](https://unsplash.com/@jdavydko?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Roman Davydko / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

To end on a quote:

"Don't get set into one form, adapt it and build your own, and let it grow, be like water" — Bruce Lee

Additional Resources

If you're keen on diving deeper into this topic and leveling up your skills, here are some resources that can help you on your journey:

Books 📚

  1. "Mindset: The New Psychology of Success" by Carol S. Dweck - Understand the power of a growth mindset.
  2. "Deep Work: Rules for Focused Success in a Distracted World" by Cal Newport - Learn how to focus and produce high-quality work.
  3. "The Pragmatic Programmer" by Andrew Hunt and David Thomas - A must-read for every new developer.

Articles 📝

  1. Understanding the Dunning-Kruger Effect - A Psychology Today article that breaks down the psychology.
  2. How to Overcome Imposter Syndrome - A Medium article that provides actionable tips.
  3. The Developer’s Edge: How To Become A Senior Developer - Hackernoon article focusing on the path to seniority.

Online Courses 🖥️

  1. The Science of Well-Being by Yale University - Coursera course that can help you understand happiness and productivity.
  2. Learning How to Learn - Another Coursera gem that teaches you the most efficient ways to learn new topics.

Feel free to explore these resources and take what resonates with you. Happy learning! 🌟

]]> <![CDATA[ Where Hot Trends Go to Die – What We Can Learn from Failed Tech Products ]]> https://www.freecodecamp.org/news/where-hot-tech-trends-go-to-die/ 66b9967077e922646120d738 Mon, 30 Jan 2023 17:17:50 +0000 If you're interested in technology, you may also have an active interest in learning about hot technology trends.

But you don't want to take every last one of these gadgets and business fads too seriously: some are bound to disappoint.

(Although don't think you can hold me personally responsible for any of my predictions: by the time this article hits the internet, I expect to be living on a sun-drenched tropical island under the witness protection plan.)

To get a sense of how fragile the innovation business is, keep in mind the popular wisdom that teaches us how nine out of ten startups will fail.

Now multiply that by the particularly speculative nature of the technology industry in particular and you'll appreciate how easily things can often go spectacularly wrong.

This article was taken from the book, Keeping Up: Backgrounders to All the Big Technology Trends You Can't Afford to Ignore. If you'd prefer to watch this chapter as a video, feel free to follow along here:

That's not to say that the folks who dreamed up all the doomed businesses we'll soon discuss were fools or frauds. It's easy for us, enjoying the benefits of historical hindsight, to judge their efforts. But we should be sensitive to how different things must have looked in the heat of the moment.

Still, bearing that in mind, there's value to be had from trying to at least understand what went wrong.

So here are some particularly impressive examples from the junkyard of tech history. It can be loads of fun to relive some of the biggest business disasters in history, but there are also important lessons we can apply when assessing this year's crop of "can't-fail" devices.

Lesson #1: Marketing Isn't Everything

In the beginning, there were comments from tech insiders about how this would be the biggest thing since ever. Then came an unauthorized book leaking intriguing information, some ambitious public claims, and a product launch.

In the end, there was Segway: a personal transportation device that was too big and fast for sidewalks, too big and slow for roads, and too expensive for most customers. And using it in the rain or snow wasn't much fun at all.

Today you'd probably have to look pretty hard to find a living, breathing Segway anywhere close to your neighborhood. They're sometimes used for police street patrols and touring, but they haven't eliminated the car or revolutionized urban development.

Nor, as far as I can see, did they make the company's investors fantastically wealthy. In fact, the company's manufacturing plant in Bedford, New Hampshire ceased operations in the summer of 2020.

What went wrong? Well, perhaps the hype was a bit over the top. Ok, make that way over the top. It's never a good thing to pump up expectations to the point they can't possibly be met.

There was also the failure to match the tool to an appropriate environment. Where, after all, was it supposed to be used? But, to be really successful, a new product has to be built on more than clever engineering. It also has to solve a real and pressing problem.

Lesson #2: Too Much Power Isn't a Good Thing

Back in 2013, Google introduced a new consumer compute product they called Glass. This was a sleek headset that could be worn as an attachment to a pair of designer prescription glasses.

When powered on, Glass could accept voice and touch commands to record video of everything the wearer sees, and display data – often with full "awareness" of the wearer's current physical location.

Glass was a single device intended to replace much of the function currently served by smart phones, laptops, and media players.

For the task of integrating our physical world with the endless data that describes it, this was going to be perfect. And then it wasn't.

As more details about Glass became known, questions were raised in the broader tech world. Was it appropriate – or even legal – to silently record videos of other people? Should face recognition software be applied to random pedestrians walking past on the sidewalk without their consent? Was it safe to drive while wearing Glass?

Potential customers had their own questions. Is the product affordable (they started at $1,500)? Is it necessary? Does it fit the vision I have for my public image?

The longer those questions floated around the internet, the more answers came back. Answers, by and large, consisting of a single word: "No." Google Glass, as a consumer product, slowly faded away and eventually disappeared altogether. The massive media promotion campaign had come up empty.

Which is not to say that the product itself failed. As it turns out, Glass has found considerable success in medical environments where, for instance, it could be used to permit remote surgical experiences.

It's also found a home in industrial settings, where front line workers often need instant, hands-free access to relevant schematics and directions.

But it was a long while before all that goodness happened. Perhaps someone should have slowed things down at some point, saying: Even if it's possible to engineer all of those features into a consumer product, is it necessarily a good idea?

Lesson #3: Sometimes the Pieces Don't All Fall Where They're Supposed to Fall

Sometimes measuring success and failure isn't so easy. Take WebTV as a case in point.

Who doesn't own a TV? (Besides me, I mean.) Wouldn't it make sense to create an inexpensive and easy-to-use product that leverages billions of existing home TVs for non-standard but popular uses? How about a device that can turn the TV you already own into a web browser and email portal?

If that doesn't sound so exciting today, back in the mid-90's the idea behind WebTV had its definite charms.

Just imagine the secondary revenue streams this could generate. Wouldn't advertisers climb over each other to pay big bucks to have their products pitched to all those TVs?

Had WebTV managed to deliver on the "easy-to-use" angle, things might have gone differently. But it turned out that the primary demographic for the device was heavily skewed to older people who needed a lot of (expensive) customer support coaching through the setup process.

Their inability to keep up with the fast-changing internet browsing standards also made it tough to provide a consistently optimal browsing experience – especially for users sitting ten feet away from the screen on their couches.

How did things actually play out? On the one hand, within two years of their launch, the company was purchased by Microsoft for more than 400 million dollars, who rebranded the service "MSN TV." In one form or another, they stuck around until long past the death of dial up internet access. So that's a good thing.

But, arguably, they failed to capture nearly as much interest and adoption as they could have. The real prize was in becoming a dominant portal for internet access.

Because the platform was proprietary, the company could effectively have controlled the entire internet experience of hundreds of millions of users. The potential scope of the product would have dwarfed the modest revenues they actually achieved. So that's not a good thing.

Were they too far ahead of their time? Did they miscalculate by insisting on a closed, proprietary platform? Did they fail to see the monstrous growth in the standalone personal computer (PC) industry coming?

Either way, it wasn't exactly a fairy tale ending.

Lesson #4: Timing is Almost Everything

The tech industry moves fast. I'm sure that little nugget of wisdom won't leave any of you wrapped in stunned silence. But when you think about how much work is needed before you can convert a fresh, new idea into a ready-to-ship product, it's remarkable anything innovative ever gets off the ground.

Bad timing, then, is a risk faced by the people behind pretty much any new technology as it makes its way to market.

By way of example, the existence of strong competition from companies like Nintendo and Sony's PlayStation were probably largely to blame for the premature death of Apple's Bandai Pippin gaming console back in the mid nineties.

Although, the fact that, at peak, there were never more than 25 game titles that would run on the device and that, like all Apple products, it was priced much higher than the competition, couldn't have helped.

All wasn't dark and foreboding for Apple in those years. Looking back with what we now know, the strong presence of their iPod digital music player platform was probably what doomed Microsoft's Zune.

On that one, Microsoft had the bad luck (or lack of foresight) to get stuck between an iPod device made dominant by its simplicity, and the looming age of the smartphone (where standalone portable music players become irrelevant).

Clearly, as Shakespeare would have it, "ripeness is all."

But there's another thing about timing: eventually, you'll need to deliver the goods. There's a limit to how long we'll wait for that bright new technology that's been on everyone's "must-have" list for too long without making an actual, real-world appearance. Beware empty promises.

You should also keep a critical eye out for good, old fashioned bad business practices – the kind that never seem to go out of style. I'm thinking about unrealistic business plans, unfamiliarity with a business' core, underlying fundamentals, and unreasonable, greedy start up costs.

Actually, I'm thinking about the catastrophic disaster that characterized the dot-com boom and subsequent bust around the start of the 21st Century. The take-any-business-model-and-build-it-a-website paradigm looked good, but it was applied far too broadly and often ignored the obvious context in the process.

Here's the long and the short of it: don't blindly trust popular trends and buzz phrases.

YouTube videos of all ten chapters from this book are available here. Lots more tech goodness - in the form of books, courses, and articles - can be had here. And consider taking my AWS, security, and container technology courses here.

]]> <![CDATA[ My Developer Journey – How I Learned to Code with Dyslexia and ADHD ]]> https://www.freecodecamp.org/news/developer-journey/ 66d45f31182810487e0ce1a4 Fri, 14 Oct 2022 16:01:31 +0000 By Jalmari Ikävalko

Hi everyone, I'm Jalmari Ikävalko, a software developer in my early 30s. In this article, I’ll share my whole journey from my first contact with code to becoming the professional developer I am today.

I'll start from my childhood when I first got interested in programming.

My Introduction to Programming

I was around 12 years old – give or take a year – when an unexpected summer storm was keeping us stuck indoors in the otherwise sunny Costa del Sol of southern Spain. It was the only time I was properly abroad as a kid, as the financial situation of my family wouldn’t typically allow a vacation beyond the confines of our home country.

My cousins and I were in our grandfather’s tiny apartment – as his operated-on lungs did not agree with the Finnish winter – and there he had a computer. The computer had no internet access, but at the time Microsoft Word happened to include a Visual Basic editor and compiler.

Then it was that my cousin, older by a year or two, showed me some basics of programming, in Visual Basic.

Image A screenshot of Microsoft Visual Basic editor

As far back as I can remember, I’ve been interested in computers and enjoyed spending my time on them.

At my mom’s place, where I lived most of the time, we didn’t have all that many video games, and the computers tended to be a few generations behind the current crest of the wave. Still, I could spend a lot of time just exploring what the computer was able to do. Trying out DOS commands, going through random files I found, and so forth.

So when I realized that anyone could program these machines and create new applications on them, I was of course immediately intrigued.

How I Started Learning to Code as a Kid

My journey started off pretty bumpy. At the time, I had no idea where a little kid with poor English skills could find usable resources for learning to code. I bugged my dad, who had done some websites and had some general understanding of programming as a phenomenon, and he showed me some HTML, CSS, and JavaScript.

JavaScript, at the time, was relatively new and hadn’t yet properly established itself as the de-facto language of the web. In fact, most websites avoided relying on it.

I went through the books in our small local library, but most of them were completely unintelligible to me (the librarians there were awesome, though. They’d suggest books to me while I hung there after school and there was a computer available with good Internet access).

I got my mom to buy me a book on C++ and I trudged through it, mostly not understanding what I was reading.

Challenges of Dyslexia and ADHD

In those first years of learning to program, I didn’t really focus on learning very consistently and wasn’t really able to finish any projects – not even the tiniest of projects.

I would often feel very frustrated when I was trying to make something work and just couldn’t understand why it didn’t work like I imagined it should.

At the same time, school was not going very well. I was diagnosed with dyslexia in the first years of elementary school and was in remedial education for English. I also struggled with motivation – and bullying – and ended up only barely getting through without having to repeat a grade.

When I was around 15, I discovered IRC (a text-based chat system) and a Finnish programming community with its own website and an IRC channel. At the time we finally had gotten a broadband internet connection, which let me spend most of my days online. Having people to talk to and having resources in my native language accelerated my learning process.

I also got interested in demoscene – a scene of computer artists revolving around what is known as demos. These are programs that programmatically generate video and audio at runtime, without the video and audio being pre-recorded and stored inside the program. I got interested in creating visual effects programmatically.

Still, I was struggling with understanding graphics programming and how more advanced visual effects were created. I was stuck creating some pretty simple ones, like a basic tree fractal.

Image A simple tree fractal

Meanwhile, I had some peers, not necessarily any older than I was, who were doing complex 3D effects, full-duration demos, fully playable games, and more.

I often felt pretty dumb in comparison, as I wasn’t nearly as quick a learner as they were, and I struggled with making sense of complex code.

In retrospect, it’s not too surprising – my dyslexia and the ADHD I was later diagnosed with definitely affected, and continue to affect, my ability to discern symbols from each other. They also make it difficult to make sense of long lines of text, whether the text is in a human or a programming language.

Even still I get mentally exhausted from reading text with sentences that are too long. The first ten or so pages of Dostoevsky’s Crime and Punishment, to me, felt like reading a full book on advanced algebraic geometry.

Still, I pushed on, motivated by the thought that one day I would be able to create visual effects, games, physic simulations, and so on.

My First Job

I did some small demos and some physics demonstrations, nothing very special, and overall they were pretty crude, but somehow they still managed to land me a trainee job in a small local company working on a 3D engine for phones.

This was in 2008 or so when I was 18. At the time I didn’t even own a smartphone. The first iPhone had just come out a year earlier and I’ve always been a bit behind with the latest tech.

I was pretty sure that a 3D engine for a phone made no sense – who would want to be looking at 3D content from that tiny screen? And I was, of course, completely right! Well, okay, I wasn’t, but worse though – and somewhat to my horror – I was completely out of my depth.

I had managed to fake some sort of an impression of skill in the interview, but in truth, I had no idea about how to properly program shaders or improve and optimize a rendering engine.

I wasn’t able to do the job and my contract wasn’t continued – I felt embarrassed enough to never have included that short stint in my future job applications.

Getting Involved in Open Source

Around that time, I also made some small contributions to a couple of open source games and 3D engines. It wasn't anything very special, or mathy, or bleeding edge – just adding minor features like copy-pasting constant values to a list from some specification or adding a feature for picking up multiple items at the same time instead of just one item. Stuff like that.

I was still learning quite slowly and wasn’t able to finish complex tasks on my own. This was frustrating, since I'd been aware of programming for around six years and had more actively practiced it for two years. The people involved were very helpful though, and I did learn a lot of small things from everyone helping me.

My University Experience

The year I turned 19 I applied to university. I did not have the formal prerequisites for enrolling in a Finnish university, as I hadn’t completed the Finnish matriculation exams (roughly comparable to SAT in the USA and the A-levels in the UK).

Still, I wrote them a letter asking for special permission to participate in the exams for computer science. I was granted permission and scored high enough in the exams to enroll.

Unfortunately, I still wasn’t a very good student. On one hand, I was a bit too proud and felt the beginner courses were somehow too menial for me. On the other hand, if a course got hard, I quickly lost the motivation to study.

After a few years of finishing only a few courses and without having learned much of anything, I got kicked out.

I was around 21, out of school, jobless, and back to living at my mom’s place. I still kept to programming as a hobby. Writing minor features for open source software, trying out a few short gigs (and failing them all). Then I noticed someone on one of my IRC channels looking for help with their startup. I volunteered and ended up getting hired.

Working at a Startup

I remotely knew the person, as they were partially involved in the same communities as I, though we hadn’t directly talked before I joined his company.

It was a bit of an unusual setup. We shared an apartment, which was kind of unofficially part of the pay, and my salary was something like half of what the company I now work in would pay for trainees and juniors in their first job.

I would generally not recommend these sorts of contracts to people, but in my case, it didn’t work out too badly. I was finally able to be somewhat useful, could live on my own, and was making at least a little bit of money – not that any of it was ever left at the end of the month.

I still wasn’t very good at finishing tasks on my own and the quality of my code was rather bad. But with that pay level, my friend’s startup didn’t truly have all that many options. Mostly, I was doing minor feature improvements, fixing bugs, and adding some new functionality to the software.

A year or two later I met my then-future wife. We moved together, I changed cities, and left that startup behind.

Junior Game Developer

I then applied to another startup, with a slightly better salary, and with more than 2-3 people working for them. My assignment for the technical interview was to add a mirror effect to a 3D scene with a skater on ice.

Typically, you do reflections by placing a virtual camera on where the reflection is and then render the scene from the perspective of that camera. I had never done that, though, and ended up using another hack that I had done previously.

I simply rendered the scene again, just flipped on the X-axis. It’s an imperfect technique but was commonly used in older games and works well enough for flat surfaces that are underneath the camera by a sufficient distance.

The job was a bit all over the place, in regard to the skills needed. The fact that I had contributed – even if insignificantly – to a large bunch of diverse projects finally paid dividends.

Over the same day, I might be coding shaders for graphics effects. I might be fixing up a web backend, configuring installers, or maintaining servers (having run Linux through much of my teens was worth it! Though it had never made me as popular in school as I was told it would).

From Junior Dev to CTO

When I started, I was a junior game developer by title. Over time we got more and more projects, the work got more challenging, and then one day our CTO left. With no one else to replace him, I became the replacement.

At roughly the same time, good ol’ Adobe Flash was dying and its support was ending, and our products happened to be mostly in Flash. So I ended up leading a major rewrite of our main products from Flash to the Unity game engine.

At the same time, we expanded our repertoire of web products, and I led the development for those, too – sometimes more successfully, sometimes less. I still wonder how exactly I managed to keep up with it all and not crumble under the stress, but I suppose that when you give someone responsibility, they just might rise to the occasion.

Image A noise meter & crowd camera product of a startup I worked for (from Uplause promotional materials)

I ended up working at that company for six years. But at some point, I started to feel that my chances for professional development were exhausted. We had trainees and juniors coming by, staying half a year to a year, and a lot of the time I was the only experienced full-time developer.

I also didn’t feel very invested in the projects anymore. They were fun enough to do, but I didn’t own any of the company and my salary wasn’t at the level where it would have been elsewhere.

At the time, I wasn’t very well aware of the wider Finnish IT scene. I mostly knew about our biggest game companies – which weren’t and still aren’t that many – but I didn’t really know what the big consulting or product companies were.

So, I ended up applying for a new job by simply googling for job openings and finding a company with a stated mission and values that seemed like a good fit for me.

I didn’t know it at the time, but that company had actually won a bunch of awards for being one of the best places to work at. And it was, in a sense, somewhat prestigious to work at.

I arrived at the interview woefully underprepared, but the cultural fit was good and my technical skills were deemed decent enough to proceed through the interview rounds and I ended up getting hired.

From Startups to Software Consulting

So, around three years ago, I moved away from the startup world to become a software consultant.

When I joined my current company, I was quite self-assured in my skills and considered myself to have grown into a very good and clever programmer. I wasn’t completely wrong, but it did turn out that I went from being the large fish in a small pond to being, at best, an average fish in a much larger pond.

My old enemies, concentration and focus (or the lack of them) were again orchestrating quite the discord to deal with. I doubt I’ll ever be fully free from having to regularly repeat the struggle of finding motivation and keeping my discipline up.

There were also parts of my technical skillset that I had badly overlooked. In the first year and a half, I ended up significantly improving my functional coding skills and my ability to write easily testable code.

I also needed to modernize a lot of my knowledge. Getting used to newer continuous integration tools, cloud services testing tools, and libraries, was quite the process. (At the small barely-getting-by type startups, we typically used virtual private servers since they were cheaper and cloud services weren’t yet quite as mature as they are right now.)

Practical work is one of the best ways to improve, though, and improve I did – and at a pretty decent pace, in my opinion.

Today, our company isn’t much for titles and we sometimes use purposefully inflated titles just for the cheap laughs. But if I have to give a title to a client, I’m typically a senior software consultant. It’s a descriptive enough title.

And after an arduously long journey to become a developer who can kickstart projects, lead feature development, participate in all stages of software development, and whose help and feedback others can rely on, I think I’ve finally matured enough to check all the boxes for what’s expected from a senior developer.

I’m still constantly learning new things. Lately, I’ve started to feel like I would like to try out working on data engineering, data analysis, and machine learning tasks.

Since I mostly ended up skipping school, I’ve been taking statistics courses at the open university of Helsinki to better understand the terminology and methodologies that data analysts are using.

On the other side, I’ve also started to study for key cloud certificates, like data administrator and data engineer certificates, to further up my credentials in client offerings.

And, funnily enough, after finally having had some success in studying through difficult courses, I’ve also started to feel that maybe a Bachelor's Degree wouldn’t be impossible for me either. Though I am not sure if after all this time I still want it in Computer Science!

"Luck is What Happens When Preparation Meets Opportunity"

So that was my journey, from the first time I saw code to what I am doing today. It was at times a frustrating and bumpy road, and I know many people have had an easier time learning to program than I had. Still, I consider myself pretty lucky overall.

One ex-coworker used to have a quote by the Roman philosopher Seneca as their signature, “Luck is what happens when preparation meets opportunity”. But there’s a lot more to it than just that. Your childhood environment affects your preparation and the opportunities you get are down to statistical chance.

I consider myself lucky for having had so many opportunities despite also failing them due to lacking preparation.

And I consider myself lucky for having had supportive parents and a smart, programming-aware cousin to show me stuff.

Today I am lucky for having some pretty amazing, extremely skilled co-workers and a work environment where neurodivergence is accepted.

Yet, there is a bit of truth to the quote. If preparation is what you get as a product of hard work, I did put in the work even when the work was mostly hitting my head against the wall.

The truth is that if you have a disadvantage like dyslexia or ADHD, things can take a lot longer for you to learn than for someone else. But that doesn’t mean it’s impossible to learn. The end result just might be all the sweeter, too. The skills you end up with will be hard-earned, a testament to your ability to overcome difficulties.

Today, it is absolutely awesome how much better resources fresh learners have available to them. When I was younger, the quality of free resources – when they were available at all – was often dubious at best, and many tutorials didn’t teach things well, if even correctly at all.

We have the likes of the University of Helsinki’s MOOC.fi available for everyone, for free. And we of course have freeCodeCamp. There are many learning communities spread over Reddit, Discord, and so on.

Make good use of these services and, one day, after having made it, perhaps look back and see how you could contribute to them in turn.

One last piece of advice I’d like to give to people new to programming: Programming is at its best when it’s fun. If you’re bored with your current courses and don’t feel like you’re enjoying your time, try out something different.

Generate sine waves and combine them into chords. Create some fractals programmatically. Try making the most annoying website possible, with flashing lights and sound effects when clicking buttons.

Make programming fun. You’ll also learn surprisingly much while doing it.

In addition to the freeCodeCamp editorial team, I'd like to credit Liisa Toivonen for helping out with proofreading and some suggestions.

Thanks for reading!

]]> <![CDATA[ Why I Turned Down a Six-Figure Salary in Big Tech to Stay at a Five-Person Startup ]]> https://www.freecodecamp.org/news/why-i-turned-down-a-six-figure-salary-in-big-tech-to-stay-at-a-five-person-startup/ 66d45d98680e33282da25e08 Thu, 06 Jan 2022 18:13:50 +0000 By Annie Liew 🦄⚡️

Two years out of coding bootcamp and I had an incredible offer from one of the world’s most highly-regarded tech companies…and I declined it.

On paper, it was the dream job. Heck, it would have been the most “adult” job I’d ever had in my life so far. Stocks, bonuses, incredible benefits, prestige, and an incredible all-remote team.

It would absolutely sky-rocket my career. The name on my résumé would open doors, opportunities, and a path to further success. I would never have to worry about how to pay my bills again.

It took me six interviews and a take-home project to get this offer. So why did I decline it?

To turn down a role like this was no small decision, especially considering the financial implications. Personal anecdotes from others helped me to make my decision and I wanted to share my story and process, too.

How it all started

Who am I?

Hi, I’m Annie. I’m an Australian multi-disciplinary designer who graduated from a Canadian front-end development bootcamp in July 2019. I was also an English instructor in Japan, among a variety of other random jobs.

My first developer job out of bootcamp was at a small WordPress VIP agency, where I worked for a little over a year. I then moved to a B2B SaaS startup, Pastel, as their first hire in October 2020. (I’m currently the Front-end Engineering Lead here.) In July 2021, I got an offer from one of the world’s biggest and loved tech firms.

It’s been a wild journey.

That email

It’s May 2021. I’ve just received an email from the manager of a large tech company, asking if I was interested in a developer advocacy position on their growing team.

I instantly think they’ve made a mistake.

Clearly, they didn’t mean to email me. After the initial shock, I realise they’ve taken the time to fill out the form on my website. Slowly it dawned on me that yes, they did mean me.

Email to Annie from someone whose name is blanked out. It is asking her if she would be interested in developer advocacy and they would be available to answer any questions.

At this point, I barely knew what developer advocacy was, but I was curious about it. They had found me through Twitter and the role sounded like it would involve a lot of the things I was already doing on the side. I mean, who wouldn’t want to get paid for the things they do in their free time, right?

However, I was really happy in my new job and was initially going to turn down the chance to interview. I shared the news with a good friend, an experienced senior engineer I trusted. Long story short, he yelled at me in all-caps and reminded me to, “Always be interviewing”.

And that’s how it started.

A Slack conversation on May 11th, 2021 between Annie and someone whose name is blacked out. Gist of the conversation is Annie likes her current job and isn’t sure whether to interview, especially since she doesn’t feel like a ‘proper good dev’, let alone a developer advocate. Her friend advised her to ‘always be interviewing’.

Deep-diving into Developer Advocacy

Over the next couple of months, I did my due diligence researching everything I could on developer advocacy/relations. I was keen to understand the role and what it would involve. I read many articles, including this very helpful Q&A with Angie Jones, a Senior Director of Developer Relations.

I was extremely fortunate to be able to reach out to current developer advocates through Twitter and my wider connections. I sought opinions from people with years of experience in the role. On calls and through messages, they shared growth ladders, salaries, experiences, expectations and the pros and cons of the position.

I scribbled notes on random pieces of paper and soaked it all in, trying to build an all-round picture of what my day to day might look like, both in the role itself and at the particular company in question.

The interview process

The first thing I did after talking to my friend was to schedule a casual call with the manager who had reached out. I got a good impression of what the team was trying to achieve and felt this was someone I could work well with.

I decided to proceed to the first formal step, which was speaking with the hiring manager. Here, I was given a high-level overview of the team and their current initiatives. It was a chance for me to ask more questions and get a feel for the people I’d be potentially working with. Afterwards, I had to sign an NDA before progressing any further, so I won’t be going into any detailed specifics.

The next stage was a take-home project. I was given two weeks to put together a presentation for the company’s Dev Rel team. I chose a couple of technologies and concepts, merged them together and added my own unique spin to teach and advocate for the platform.

I learned a lot for this presentation, as one of the platform’s technologies I chose was completely new to me. To understand it better, I had to deep dive into several other concepts. Not someone to do things in half measures, I poured hours into this outside my full-time job — researching, content creation and presentation practice — and it paid off.

The presentation itself went amazing and was well-received. Surprisingly, I felt confident and had a lot of fun with it! I don’t have much experience with public speaking, so this had been a concern of mine.

At this stage, I could choose to drop out of the rest of the interview process if I felt the role wouldn’t be a good fit. However, it was at this point where it hit me — I really could do this developer advocate thing!

I decided to go all-in, and my final four interviews were scheduled for the beginning of July.

The offer

It took just over two months from when the manager first reached out on May 11, 2021, to when I got the formal written offer on July 14th, 2021. Suddenly, the decision was brought into sharp focus, and I had two weeks to sign or decline.

Email of an offer letter from DocuSign with company identifying information blacked out

How I made my decision

Trust that either choice is a win-win

It was quite stressful to be in a situation where the choice I made would have a huge impact on my life over the next few years. I lost sleep and my appetite was non-existent for a couple of weeks while I agonised over it.

However, at the end of the day, I realised there really wasn’t a bad choice. It all came down to which experiences I wanted to have.

When faced with tough choices, I always ask myself the question, “What would I regret less at the end of my life?” It might seem a bit extreme, but honestly, this question gives me big-picture clarity to decide what I want to do with the limited time I have on Earth. What meaningful experiences do I want to cultivate during this time?

If I chose to stay, I’d be able to dive deeper into software engineering, help grow and shape a small company, and learn about and get involved in business and product growth decisions.

For a while now, my professional goal has been to become exceptional at front-end development, while building knowledge in the back-end and dev ops to supplement this. I was very excited about Pastel’s company vision and direction, and I knew how I wanted to contribute to it.

In a startup, things move fast. With my CTO, we had long planned out my growth trajectory there — the kind of responsibilities I would have, the things I would do, and what that would look like.

If I chose to leave, I had the opportunity to be more visible in the community as someone from a non-traditional background, a person of colour and a woman. It would send a powerful message to others to know that this Big Tech company hires bootcamp grads and self-learners.

I would increase my breadth of skill as I learn about various tooling to share them with the wider community. Building my network and helping others get better at what they do would be part of my job. I would get better at presenting and be doing things similar to what I’d already been doing in my free time, but now with the support and formal backing of a large company behind me.

Know your values

Who do you want to be in a few years and what do you want to be doing? After the presentation, I knew I could do the developer advocacy role and do it well.

Years of design work, teaching/mentoring experience, and diverse overseas living would give me some particularly unique advantages here. Plus, as an extrovert, spending time with people is energizing for me and I love connecting with people and seeing them succeed.

Yet, when I thought deeply about my personal values, job stability, status, and a desire for prestige isn’t among them. These were some of the top benefits the new company offered. I crave novelty, I’m not risk-averse, and at heart, I’ve always been a creator. I want to build cool sh*t with cool people and have fun along the way.

In a startup — especially one pretty early on — the things you do from one year to the next change. There is novelty here. It’s easy to be swayed by big numbers but money itself has never been a singularly motivating factor for me throughout my life. I view it as a side effect of creating value.

That’s not to say I don’t negotiate salaries or seek to improve my financial situation — I just see it as one factor in a larger holistic list of considerations.

Coming back to my core values helped me make my decision.

Content creation and creative work aren’t new to me — I’ve had practice as a designer working on multiple projects. On the other hand, engineering is out of my comfort zone and doesn’t come naturally. In life, choosing the harder things are often the most rewarding for your growth.

I also figured the offer wasn’t enough to offset the loss of my engineering career capital. By switching into developer advocacy now, I would lose whatever momentum I was gaining by being in the trenches and repeatedly doing development work. At this stage, I wanted to focus on building depth of skill, as opposed to more breadth.

I also thought about impact and legacy. In a big company, you make a smaller impact on a greater number of people. In a small company, you make a greater impact on a smaller number of people. Neither one is better than the other — just different. The viable level of impact I’m able to have in a startup felt pretty meaningful to me.

For me, it ultimately came down to being a practitioner who occasionally teaches, versus a teacher who occasionally practices.

Side note: Shortly after I turned down the role, Kelly Vaughn tweeted this and it strongly resonated, making me feel like I’d made the right decision.

It's taken me a long time to learn how to say no to potential opportunities that could be good for me career-wise but are not something I am truly interested in doing. The further into my career I go, the more I value my time.

Don’t let social clout cloud your decision-making

Having an online audience brings opportunities, but there’s a cost to being in the public eye.

The developer advocate role is a fairly visible one, potentially requiring me to be more active on social media. I had not sought to “grow my Twitter following” when I first became more active on the platform and had concerns it might become difficult for me to untangle my sense of worth and value from the vanity metrics of social media.

Not only that, I’m aware of the distractive impact of social media on deep work — something I value in my quest to get good at my craft.

At one point, when I seriously thought I was going to take the role, I had already imagined what sharing the news on Twitter would be like. Someone I knew had started a job at the company around this time and their profile had absolutely blown up as a result.

More than anything, something that played in my mind over and over again was sharing proof that big tech companies do hire bootcamp graduates and self-learners like myself. It felt like such an incredibly powerful message to get out into the world. It could change someone’s life.

But at the end of the day, I had to do what felt right for me.

The grass isn’t always greener on the other side

In conversation with a senior developer who worked at another big tech company, I realised what I had was rare and valuable.

At our startup, we barely had any company politics. With a lean team of only five people, Pastel currently has a very flat company hierarchy.

In a bigger company, many are vying for the kind of responsibility I currently have and struggling to be noticed by higher-ups. In another company, big decisions are made, signed off and passed down to be executed.

Here, I’m an integral part of all roadmap plannings and product direction meetings. I have full freedom to handle and execute on the UI, UX, and improve accessibility on the app. My voice and opinions are trusted and valued.

Second, to find a mentor who’s deeply invested in your professional growth as an engineer, actively providing you with autonomy and responsibility, alongside a product you personally resonate with, isn’t something you find every day.

My CTO, as my professional mentor, has been coding since he was eight. He breezed through his computer science classes and turned down interviews with Google, Facebook, and others to work on his own thing.

True, in a few years, I could easily join another startup if I decided to move away from developer advocacy… but right now, I’m working on a product that lies at the intersection of design and development, much like my experiences as a designer/developer. Pastel speaks to me. It’s a product I can get behind and it personally solves a pain point I’ve experienced myself.

Do your homework

As mentioned earlier, while trying to make up my mind, I reached out and spoke to a lot of people. Being in the middle of this seemingly momentous career decision, I knew there would be blind spots and biases I wasn’t aware of. I wanted to make sure I had as much information as possible to make an informed decision that was right for me.

I spoke to numerous developer advocates to ask about their work and day-to-day. I spoke to people who worked at the company who made the offer. I spoke to people who had been in similar situations and asked how they came to their various decisions. I researched the new role heavily and, by the end, I knew a lot about a path that had not previously been on my radar.

A notable point came out from one particular conversation with a very senior engineer, who had been a developer advocate for a while. While in that role, he would give talks at conferences and there would be people doubting his experience because he didn’t have “engineer” in his current title.

To give context, he’s a white male who was fairly senior at that point. It gave me pause as to what people would think of me — female and without years of technical experience or a Computer Science degree.

Developer Advocacy is still a fairly new role in tech, and one of its hiccups is unfortunately people sometimes think advocates aren’t as technically able as full-time developers or engineers.

This is not correct. Those who do this work need to have technical ability, plus a range of other skillsets beyond that. Over time, I’m hopeful this mindset will gradually change.

Risk mitigation

As with everything in life, whether you do one thing or another, there’s some form of risk. These were factors I considered that reduced my risk of staying at a startup.

Counter Offer

Before you think crazy numbers, it must be stated that location plays a factor and I live in Canada, not America. There’s universal health care here and salaries are lower than the American numbers you often see flaunted all over the internet.

American tech companies have location-based salaries. To be transparent, while my offer was six figures in Canadian dollars, when converted to American, it would be five. Such is life.

If I was only making ~$55k CAD a year (the median salary of graduates from my bootcamp), leaving would have been a no-brainer. As it was, Pastel made a compelling counter-offer (which I negotiated) and this decreased the compensation gap between the two options. Hey, I’m all for building financial security in your life.

Many startups rely on investor funding without a market-proven product. Pastel is bootstrapped, runs on a subscription model, was profitable before I started, and is growing. This decreased the financial risk of the company going bankrupt and me losing my job.

Additionally, while my title is still that of a developer, I negotiated the ability to dedicate 30% of my time doing developer advocacy work, should I choose to. I felt this was an interesting and calculated way to dip my toes into this world, beyond my side projects.

Long Term Game

If this was a straight choice between doing engineering at Company A vs Company B, the decision might have been easier. However, this wasn’t a simple corporate vs startup decision. It was also a decision of the type of career path I wanted: Software Development vs Developer Advocacy.

You can absolutely build an incredible career through advocacy work. I know this through my research and those I see in the field.

But this is also true for Engineering. Given that, when I compared the two career paths, truthfully I felt more excited about building depth in development than I did about organising and giving talks on it.

In his book, “So Good They Can’t Ignore You: Why Skills Trump Passion in the Quest for Work You Love”, Cal Newport shared an interesting idea: Control is one of the most powerful traits you can acquire when creating work you love. In order to keep that, sometimes you might have to say no to a raise.

What is the end goal here? To find work you love? Or to get a company name on your résumé?

I also mentioned this briefly before, but it’s worth restating: Beyond engineering, I want to learn about building and managing a business. At a startup, I’m on the ground shaping company culture, advocating for better product decisions, and possibly doing future hiring. I have greater say on how the company can make an impact in the world.

The learnings I’m acquiring in this process are no small thing and are worth a lot to me. I’ll be able to take these skills, lessons, and knowledge into my next role.

Professional Network

It’s not a myth that people often get jobs through their network. Be it through a friend’s friend, a referral or something else, many a job has been secured via a connection. Had I felt less confident about this aspect of my life, the company name on my résumé would hold much greater sway over my decision.

As it is, over the past two years, I’ve slowly cultivated authentic industry connections I trust and value. Not for the purpose of getting work, but simply because I’m curious about who they are and the myriad of interesting things they’re doing in the world.

And yes, some of these good people work at FAANG and other big tech companies that shape much of our world.

When the time is right and if I’m no longer professionally challenged in my role, I’ll think about my next move. Who knows, maybe full developer advocacy will be on the books.

Listen to everyone’s advice… and ignore most of it

At the end of the day, your journey is your own. Oftentimes, you have a more nuanced picture of your particular situation than others.

Do your due diligence but follow your gut and decide how your life plays out. Your values, needs, and desires are different from others'. Own your journey, and don’t let others tell you what you should do.

About 90% of people I spoke to advised me to take the position— it wasn’t easy to go against the grain and do the opposite.

Yet, only you can decide who you want to be.

Image _Photo by [Unsplash](https://unsplash.com/@socialcut?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener">S O C I A L . C U T on <a href="https://unsplash.com/s/photos/inspirational-words?utm_source=unsplash&utm_medium=referral&utmcontent=creditCopyText" rel="noopener)

Final thoughts

Ultimately, this was an incredible opportunity. But it just wasn’t my opportunity. At least not right now. A no now doesn’t mean a no forever. Through this whole process of trying to figure out whether to stay or go, when I finally made my decision, it felt right for me. It was a very intentional decision.

I very clearly understood what I was giving up by declining the offer. In many ways, it gave me a stronger sense of purpose, confidence, and energy with the current path I’d chosen.

Do I feel sad about turning it down? Of course! It’s hard not to. The people I met throughout the process were all extremely kind and welcoming. I could imagine how much fun it would be to work with them. I’m grateful to have had this experience and the learnings I took away from it.

It’s not easy, but I’m excited about getting better at engineering. At Pastel, things are still tough right now, but the deep work I’d be doing over the next year or so to consolidate the skills I’m struggling with, are going to compound.

In a year or more, I’ll have greater breadth and depth of knowledge to build, grow and shape a company and product. This is incredibly energizing for me.

Watch this space.

I want to personally say the biggest thank you to everyone who was there throughout this journey with me. Thank you for your support, for taking the time to listen, weigh-in and consider options with me. I am beyond grateful you made time for me. You know who you are and I deeply appreciate you.

]]> <![CDATA[ From the Slums of Mumbai to a Rented Apartment – My 30-Year Developer Journey ]]> https://www.freecodecamp.org/news/my-journey-into-tech-from-slums-of-mumbai-to-my-own-apartment/ 66d460f0a326133d12440a78 Wed, 09 Jun 2021 21:55:16 +0000 By Santosh Yadav

Last year I tweeted about how I was moving from a Slum where I lived for 29 years to a multi-story rented apartment.

The tech community on Twitter responded with nothing but love. Dan Wahlin posted that he would love to hear more about my story. It's not going to be easy to write about my struggle over the years, but I will try my best.

Early Days

I was born in Mumbai and lived in a slum as long as I can remember. It was a typical slum which you see in movies – there were good people and a lot of bad people, too. I was lucky not to hang out with those bad people for long.

I was more of a lazy person, and cricket was my first love. I performed very poorly on my 10th exams. I was expecting to get better grades, but they were all below my expectations.

I was not sure what I was going to do next, so I thought I would try to get admitted in science but my marks weren't good enough.

Getting Into Computer Science

I would say it was my luck or destiny. One of my dad's friends informed us about some Diploma courses. I applied for it and luckily I got in.

I had to choose from multiple courses, and I chose computer science without thinking twice. But it was not going to be easy.

How I struggled with language

English is not my native language. I studied in a school where Hindi was my first language and I had accent issues as well (coming from the north, we have a different accent). I remember crying in a class because I couldn't understand a thing, and I was scared to fail again like I failed my expectations in 10th Standard.

I did really bad in our internal exams, but giving up was not an option this time. I never told my parents that I was struggling with my studies. I pulled myself back, started studying hard, stopped playing cricket, and isolated myself from friends.

The only thing I wanted to achieve was somehow not to fail in the first year of the 3-year program. In the upcoming exams, I did ok and got around 50% in the first year.

I was not happy, but that was the best I could do.

When I moved into the second year I was a better version of myself. I was more confident and scored better on my exams. And by my final year, I scored more than 60%.

I learned that if you decide to achieve something, you can and will do it. Never give up, because you can always learn if you are serious about it. For example, I remember when one of my classmates made fun of my accent – I took it as a challenge and improved it.

Dealing with a Setback

Once I passed my final exams, I was more interested in studying to get a CS degree. That was another 4-year program (3 years for me as I had gotten the 3-year diploma).

I intended to continue my studies, but when I was in my second year, my dad lost his job. I was not aware of it for a long time, then one day my dad gave bad news to me. He asked me to start looking for a job as he could not afford to pay the fee for my CS degree which was around 42k (550 USD) per year.

I was crying the entire night and couldn't sleep. The next day my mom, who noticed me crying, spoke to my dad – she said "Do whatever you want to do, but my son is going to continue his studies."

My dad agreed, and with the help of my uncle (my dad's big brother) I was able to continue.

Getting into a CS Degree Program

I scored well enough on my exams to get into the CS degree program. I was admitted into the 2nd year and to one of the colleges which had just opened in 2004. So it wasn't a Tier-1 college, but it was from Mumbai University and I was happy to get in.

The same year we had heavy floods in Mumbai so the entire admission process was postponed. Within 2 months we had our exams, and I was lucky I didn't fail any subjects.

When I went into my 3rd year, I started borrowing books from the library to study because I had no money to buy those books. A few of my professors used to borrow them for me, so I could use them to study during exams and return them afterward.

By the time I was ready to complete my 3rd year, my family's finances had gotten worse. I thought of dropping out this time, but one of my friends with whom I shared this news said: 'You don't worry about it, I will do something'.

I almost cried. But during vacation, my dad told me that he managed to save up the money for the final year.

I was happy and I did well in my final year. In my final exam, I scored close to 70%. I thought that this bad phase was gone since I finally had a degree. But there was something happening that I didn't know about.

The Recession of 2008

The Great Recession happened, and not many companies were hiring that year. I was not sure of what I wanted to do next.

My friends said I was good at coding, so I should get into it. I realized I really enjoyed coding, and I fell in love with C#.

I waited for three or four months before I could get my first job. At that job, I could study new things and get paid too – my salary was 5k INR, or around $68 USD per month.

After 8 months I decided to leave that job and was jobless for a month. I got some support work for the next 4 months, which required some knowledge of SQL queries, so I brushed up on that knowledge.

Finally, in January 2010, I got a job where I could write some code. It was a Windows application using C#. I gave my best, but the salary was still very low.

I was getting paid 12k ($163 USD) per month, and there was not enough work. I spoke to my manager about this and he told me to take this as an opportunity to learn something new.

I started reading more C# and another colleague of mine who was a DBA helped me with SQL (creating Stored Procedures, functions, and writing queries). Within 10 months I got an offer with a 100% raise. A giant step! I worked on this new job for another 8 months.

Joining the Startup

I joined a startup in August 2011, and went on to work there for the next 5 years. The pay was good, and I got more than a 50% raise when I joined. And I finally had insurance provided by the company and PF too.

I gave my best when I started, and I used to deliver things really fast because I wanted more work. Within a few months, I had built up a good relationship with the team and everyone including my CEO appreciated my work.

I realized that not everyone gets a kick start to their career, but don't give up – keep giving it your best wherever you work, and one day you will get your dream job.

It's never a smooth ride

I thought now, everything will be fine – I have a more settled job, and a good salary, but you never know what can go wrong.

My wife was pregnant, and suddenly around the 6th month she had some complications. The doctor told us we had to do urgent surgery and said that they weren't sure if they could save the baby.

He asked us if we could move the baby to one of the hospitals which was known to handle cases like these. There was a chance she could survive, but it would cost us more than my entire year's salary.

And I said that I would do anything to save her.

I hardly had any savings as I was supporting my family and taking care of all our daily expenses.

The entire hospital bill including my wife's surgery was 8L ($11K USD) and insurance covered only 5%. I took some personal loans from the bank and my friends helped me with some money.

Also, I spoke to my manager to see if I could get an extra raise that year, which was around 40% more than I was getting. To my surprise, my manager and my CEO agreed and I got the raise.

I used to go to the hospital daily to see my daughter, then go to work. This was my schedule for three months. She was born with a weight of 845 g and was around 1.5 kg once she came home.

I continued working hard and paid all my friends back, but the personal loan was where I was paying most of my salary. My wife sold her all jewelry so we could finishing paying it back and repay some of my friends, too.

I was finally able to buy her a ring and some more gold jewelry last month – I don't have to tell you how happy she was.

Life is not easy for anyone. You need to stand up to any challenge, you will have tough times, but if you face it head on it will make you stronger.

In search of a better life

I had started focusing more on my career so I could make more money and pay off my loans. But I missed spending time with my daughter and wife.

I had left my parent's house to start my own family, with no savings of my own. One of my friends rented me a house, where I lived for a year and we had no bed to sleep in. We built our home from nothing.

I lived there for a year and bought some mattresses to sleep on eventually and purchased a laptop to practice programming (yes – I had no laptop of my own until 2015).

Not everyone knows you struggle sometimes – even your family. Don't give up, though. Not everyone is going to support you when you are at low points of your life. But if you're lucky, you'll have good friends who support you and help you out when others can't or won't.

What kept me strong

Between 2012-2015 there were many times when I really wanted to give up. But I also wanted to fight for my daughter and wife and give them a better life, and I wanted to be my best at my job.

If you are reading this, please spend time with family. You don't get paid to work more than 8 hours, anything above that is the free work for your employer.

After 2015 I was asked to work more than 8 hours only once and my answer was no because that's how it starts. Work for yourself instead, learn something new, practice, and build something. It will help you in the future.

Moving to Pune

Around 2016 I left the startup because my manager was pretty toxic. When I left, all my co-workers clapped for me, it was a very emotional moment.

I moved to Pune to work with one of the MNC. I started giving more time to my family, worked no more than 8 hours a day, and I didn't work on weekends. During this time, I realized I wanted to write blogs, so I even wrote few blogs on .Net, AngularJS, and Angular.

I started taking training for Angular and made some money. I purchased a bed, got my daughter admitted into a good school, and also paid off some loans. 2017 was a good year for me and my family.

The extra income was really helping us. I remember the old mattress was really in bad condition and it started impacting our health. My wife had a very bad backache because of it, and the extra money helped me invest in a good high-quality mattress.

Never get stuck in your comfort zone. If work is not challenging enough or you are not enjoying it, leave that job if you're able.

Also, family is important. One of the reasons we moved to new city was that I was missing all my family time. I was investing more time at work rather than in family, and travel was making it worse.

Another Bad Phase

2018 started off a little rough. I spent four months recording a course for one person and he didn't pay me. I had some conflict with the organization I used to conduct training with, so I left them.

I was earning money, but my learning had stopped and I was not doing anything for the community. I was earning money because of OSS.

But then my daughter was diagnosed with TB. I was scared and demotivated again, and I had joined Deutsche bank at the end of 2017. So work was good, there wasn't much pressure, and pay was also good.

I didn't have time in 2018 to do much for the community, but I performed well in my project where I was working full-time on Angular.

A Resurrection and My Journey to GDE

After a bad 2018, I had something different in mind for 2019. I really wanted to contribute to the community, but I didn't know how to do it.

I decided to attend an Angular conference (my first conference ever) where I met Vikram from the Angular Team and asked him for some tips.

After coming home from the conference, I wanted to start contributing, and Angular was the framework I was in love with.

But couldn't find any issues which I could work on, so I decided to go to NgRx. I found one issue and raised my first PR on 28th Feb, and started contributing more.

Around mid-March I found an Issue in the Angular repo I could take on, and started working on it and finally raised my first PR there.

In March I learned about something called the GDE Program for Angular. I decided to go ahead and check it out, and learned you get invited based on your contributions. It's true – before that, I was not aware of the GDE program.

I figured out that I was too far away from the GDE and anyways it wasn't my motivation to start contributing.

It doesn't matter when you start contributing to open source. I get this question a lot, but I had never worked on OSS my whole life. My advice is that it's never too late to start. I started contributing to OSS after turning 32, working for 1o years in tech jobs, and it was the best decision I ever made.

Writing for inDepth.dev

I had stopped writing for a long time. I remember while working on one PR for NgRx where the NgRx team motivated me to write an article and even helped me with the review.

The article was published and I was excited, as I loved inDepth.dev for its quality content. I never thought that one day I would write on that platform.

My first open source project

Around June 2019 I started to work on a personal project. I learned about Angular Builders, and Minko gave a nice example on how to deploy your app on GitHub pages. I was inspired by it, so I decided to create one for Netlify for myself and published it on NPM.

It became popular and now is used by more than 200+ projects on GitHub. And it also became part of the Angular Docs.

https://github.com/ngx-builders/netlify-builder

My First Conference Talk

Sajeetharan, the organizer of NgSrilanka, posted on Twitter they were looking for speakers for the conference. So I decided to send him an email. Within a week I was confirmed as a speaker.

It was my first talk in the front of 300 developers. I was scared, but I learned something: No one is going to be amazing when they give their first talk. I watched the recording and I improved myself, and I read blogs on how to improve as speaker.

Getting Invited to the Google Developer Expert Program

In August, I got a message on LinkedIn from Siddhant Agarwal from Google asking if I would be interested in applying for the Google Developer Expert program. In September 2019 my application was accepted and my interview was scheduled.

And on November 13th, which is my birthday, I was announced as a GDE.

A few months ago, I thought I could never become one – but sometimes, when you work hard enough, you don't need to ask for anything.

Again, never give up. I never thought I would be a GDE one day. I only wanted to give my best to the community. Don't expect anything return, just keep giving your best and you will get more back than you could ever imagine.

Support from my New Employer

Unfortunately, in late 2019, I had to leave my job at Deutsche Bank. It wasn't a pleasant experience, but I got through it.

My new employer supported me in this situation, and the HR department always reassured me that they had my back and that I would be joining the team.

Not all organizations are bad – many do care about their employees. I would love to see a day where all organizations care about OSS and encourage more employees to contribute to the community.

Post-Feb 2020

Life after Feb 2020 has been good so far. I have been able to speak at conferences without worrying about my employer, as they don't have any issues with it. And I started contributing to OSS again, and started a Talk Show called "Tech Talks with Santosh" which you can check out here: https://www.youtube.com/TechTalksWithSantosh

Becoming India's First GitHub Star

In March 2020, GitHub came up with the GitHub Star program. This is different from other programs, as you cannot nominate yourself – instead, you need to be nominated by other developers in the community.

I posted about this program, and asked my fellow developers to nominate someone who deserved to be there. I was not expecting many developers to nominate me! But then I got the email to submit my profile.

I was shocked and scared, but I submitted my profile. Then in November I was announced as a GitHub Star. I was the first one from India.

More than anything I was happy to see the the Indian flag on the GitHub Star profile.

Image GitHub Star Logo

What's Next

Like all developers out there, I do have a dream. Below are a few things I want to achieve:

  • Contribute more towards Open Source.
  • Inspire more developers to contribute to Open Source.
  • Work hard on my Show "Tech Talks with Santosh" to share my knowledge with the community.
  • Work towards my dream job as a Developer Advocate, because that's what I love to do – helping developers succeed.

Conclusion

This isn't really a conclusion, as my story is still in progress. I believe everyone has a story worth telling, and this is my story so far.

To end, here are a few important question which I ask myself:

Is my struggle over?
I don't know.
Will everything will be alright?
I don't know.
Am I going to stop fighting?
To quit is not an option.

Thanks for reading!

]]> <![CDATA[ How to Recover from Deployment Hell – What I Learned After My Discord Bot Crashed on a 1,000+ User Server ]]> https://www.freecodecamp.org/news/recovering-from-deployment-hell-what-i-learned-from-deploying-my-discord-bot-to-a-1000-user-server/ 66d46025264384a65d5a9594 Fri, 04 Jun 2021 20:41:29 +0000 I built a Discord AI Chatbot in my last blog post and then, to challenge myself, proceeded to stress-test it on a Discord server with 1,000+ users.

In the first hour, Deployment Hell struck and I had to take the bot down for maintenance. Another hour passed and I managed to patch up my bot and send it back.

Now my bot is up and running and more resilient than ever. As for me, I survived and even thrived in Deployment Hell 🔥. In this deployment postmortem, I'm going to show you how.

I sent my AI chatbot into the server at 2 pm on June 2nd, and hype started gathering around it. The chat went on for a while and all was nice and smooth.

At 3:20 pm, everything started falling apart: My free-tier API key reached its hourly request limit, and I had no choice but to take down the bot and the server for maintenance.

Image

Never mind the typos in my message 😅 This incident caught me totally unprepared

Despite being struck by Deployment Hell in the first hour on the first day of my project debut, I knew I need to sit down, take a deep breath, and recover from this incident.

What Went Well with Deployment

As a first step, I didn't forget to congratulate myself on what went well despite this mishap. Clearly, people were enthusiastic about chatting with my chatbot, to the extent that we went over rate limit.

Moreover, in the brief hour when I observed people interact with my bot in real time, I discovered several good design choices that I've consciously, unconsciously, or subconsciously made.

Avoid Feature Creep At All Costs During Development

I originally developed my code for a tutorial, so I kept my code as simple and readable as possible, without complicated features that won't serve my bot's main use case: chatting.

That said, I marked down TODOs and stretch goals in my code, hoping to get back to those if necessary. For example:

 # TODO: cache chat history in DB and load
 # TODO: after each user input and bot input,
 # append them to conversation history for the next query
 ...
 # FIXME: better make this try-except block more fine-grained

As I observed users interacting with the bot, I'm actually relieved that I didn't implement the memory cache feature. Several users were talking with the bot at once, each along their different conversation thread. If I were to keep track of the conversation history, I would have to create a unique log for each user, further complicating database operations.

Abide by the Principle of Least Privilege

One thing I learned in my Computer Security class is the Principle of Least Privilege (PoLP) – granting an application the minimum amount of access it needs to do its job.

My chatbot only needs two low-level security permissions: View Channel for reading users' messages, and Send Text Messages for replying to users.

Of course I could have given it more fancy permissions like those shown below in the image, just in case it needs any. But that would have violated PoLP and who knows whether my malfunctioning bot will bring down anything else with it when it fails?

Image

Permission settings for Discord bots

Other Observations from Deploying My Bot

Despite its ephemeral lifespan, my bot offered me an opportunity to conduct user research in the real world. This is a server with 1000+ users, not my cozy dev server where my friends and I hang out and take turns to politely exchange lines with the bot.

Here, I observed several interesting user behaviors:

  • People tend to ask the bot open-ended questions instead of factual ones. Because I built my bot based off a video game character, when developing the AI model, I was keen on making sure the model learns the canon information about the character, like name, age, and role in the game. I was relieved when I saw that people are much more curious about the bot character's preference for ice cream flavor than their factual place of birth.

  • People use a lot of emoticons :), emojis 😃 and GIFs as they text. However, these will most likely be treated as <UNKNOWN> tokens in the AI model's tokenizer, which means I should sanitize user inputs.

I was also very fortunate to receive direct feedback from friendly people on the server. One feature request that I got was to make the bot attach its response to a user's message thread, instead of just dumping its response in the channel.

Buzzing with excitement from people's enthusiasm and armed with insights from user research, I was ready to patch up my bot and send it back as soon as possible.

What I Needed to Fix

As a good development habit, I kept my code well-organized and modularized, so switching from the production bot back to my development bot requires no more than copy-pasting the dev bot's API key.

Once I was running on my dev server, I sat down to identify the types of problems I needed to tackle.

Fatal Crashes

The fatal bug that caused me to take down my bot was that I hit an hourly API rate limit. I took the obvious approach of keeping redundancy in my system: Keep an alternative API key, and once the primary one runs out, switch over to the alternative, and then switch back at the turn of the hour.

Workaround aside, I noted that this is a short-term solution. If I need to properly scale up my system, I should make an estimate of the number of requests per hour, as I'll discuss at the end of this section.

New Features for Usability

I decided on several new features that will make my bot more user-friendly. Some highlights are:

  • As some server people suggested, I re-programmed the bot so that instead of dumping responses to different user messages into the channel, it directly responds to each user message in the message's thread.

  • I sanitized user inputs by removing Unicode emojis and Discord-specific <:some_hilarious_gif> tags. This will limit <UNKNOWN> tokens that my AI model will receive and help it generate better responses.

  • I implemented a magic command $ignore [message] that allow users to send a message to the channel without triggering a bot response. This feature comes from my observation that, whenever the bot says something funny or smart (or both!), users will remark on that by sending a text intended for their friends (and not the bot) to the channel. It'd be annoying to still receive a bot response on a remark intended for a friend. Hence, I hope that this magic command will address this user pain point.

  • I implemented magic commands for the server moderators to interface with my bot (stopping or rebooting) so that they can keep the bot under control without having to access my Repl.it server. This makes both my job and theirs easier.

Future-proof Logging

In my cozy dev server, there is little complexity, whereas on this 1000+ user server where 40% of users are online at any given moment, complexity explodes.

There are multiple channels besides the chat channel dedicated to my bot, multiple user roles and permission levels, multiple users typing at the same time, and so on.

While I certainly cannot prevent all possible failure scenarios, what I could do is to protect the important part of my code with a try-except block and log out all information that might reveal the cause of a failure. Since real-time system bugs are subtle and difficult to reproduce, logging will save me lots of headaches down the road.

except Exception as e:
            print(e, 'Offending channel', message.channel, 
            'Offending message', message.content, 
            'Offending bot response', bot_response, 
            sep='\n', end='\n\n')

Scalability

Estimating under some system constraints is where basic statistics and heuristics come in. Hugging Face's model Inference API imposes two limits on the scalability of my system:

  1. A 10k tokens (characters) per hour rate limit, which is about 300 queries.

  2. A 30k tokens per month quota for free-tier accounts, which is about 900 queries.

Wonder how I get the numbers? Fun fact: 1) 10k characters is between 1430 and 2500 words. We will take 2100 since Discord messages usually use simple, short words. 2) The average length of a text message is 7 words. 2100 / 7 = 300 messages

After processing these numbers, the fact that I hit the per-hour rate limit during the first hour of my bot debut is quite a remarkable feat. People are clearly hyped about my witty chatbot. 🥳

Suppose the hype recedes and life goes on, consider now a hypothetical scenario where 20 users (2% of the 1000+ on the server) regularly chat with my bot, each for 25 lines, in the two hours following dinner. This produces a total of 500 queries in two hours (or 250 per hour), meaning that my bot is safe from the per-hour rate limit of 300.

However, in a month, 500 * 30 = 15,000 queries, 15 times more than my quota of 900. If my bot is indeed this popular, I would need to switch to a higher-tier subscription plan to ensure that it remains available.

From Tutorial Code to Production Code

Compared to my tutorial code which strives to be simple, readable, and educative, my production code is longer, more complicated, but also more robust.

What Makes a Great Side Project

Having emerged from Deployment Hell, like my bot, I'm more resilient than ever and have gained new insights about the principles and challenges in real-world software engineering.

As a final takeaway, I reflect on what makes my Discord AI chatbot this popular. (On June 3rd, a day when it's up 24 hours, it had already busted the monthly 30k quota on both my account and one I borrowed from a friend, totaling 2,000+ messages. 🤓)

I have completed and polished various side projects that received positive feedback, but none of them were as half popular as this one. In retrospect, it's not too hard to see why.

Among projects that I'm most proud of, I built a chess engine and a rhythm game engine for the Ren'Py Visual Novel (VN) game development engine. Both are rated 5-star on itch.io, a popular platform for publishing indie games.

These projects, however, are open-source engines intended for developers to integrate into their VN games more than standalone playables that can entertain players for hours.

In comparison, my Discord AI chatbot manages to capture each of the following elements that distinguishes a great side project from a good one:

  • Audience: I'm fortunate to have this friendly server with 1000+ users who are open to experimenting with the bot and provide me with helpful feedback.

  • Accessibility: For people to enjoy my chabot, there is nothing special they need to add to their routine - not even opening up a new web app - they just log into Discord as usual, and voilà, the bot is here to chat!

  • Interactivity: Without interactive components, even the most visually-astonishing game will fail to retain players' attention. Nothing to worry about for my chatbot though: Like a loyal friend, it always has something to quip about whenever you need a good chat.

If you'd like to learn more about my methodology for working on side projects, check out my previous blog post:

https://www.freecodecamp.org/news/how-i-built-my-one-person-open-source-project/

Also check out my chatbot tutorial!

https://www.freecodecamp.org/news/discord-ai-chatbot/

You can also try this out in JavaScript:

]]> <![CDATA[ How a Czech DJ Built a 3D Printing Empire ]]> https://www.freecodecamp.org/news/how-prusa3d-became-one-of-the-fastest-growing-startups-in-the-world/ 66d45f333a8352b6c5a2aa65 Wed, 31 Mar 2021 20:57:40 +0000 By Jaime Arredondo

In 2012, a young Czech DJ hobbyist was frustrated with the knobs and faders on his music controllers, so went looking for ways to improve them. That’s when he came across 3D printing, and one of the fastest-growing 3D printing companies in the world was born.

Today, I’m going to show you exactly how Prusa3D became one of the fastest-growing hardware manufacturers in Europe. Then you can take inspiration from their exact strategy to grow a hardware company and create a community of contributors who will help you develop and promote your project with close to no resources.

Some background on Prusa

Josef Prusa, Prusa Research’s founder, is a superstar in the 3D printers industry.

You might have already heard about him but if you haven’t…

  • Prusa Research was founded as a one-man startup in 2012 by Josef Prusa.
  • His goal with Prusa Research was to create a kind of Thermomix, Europe's favourite all-in-one, easy-to-use kitchen appliance, for 3D printing. He wanted to make a 3D printer that was easy enough that anyone could use it, with guidance on steps and materials.
  • In 2018 Prusa Research became the fastest-growing tech company in Central Europe (Deloitte Fast 50 2018) after growing 17,118% between 2014 and 2018
  • Prusa Research has grown from humble beginnings to selling 100,000 printers, employing over 410 employees, and setting up a factory in Prague with 9 floors and a hackerspace on the ground floor
  • The company brought the Maker Faire to Prague for the first time
  • Prusa’s website has over one million unique visitors per month, its YouTube Channel has more than 144,000 subscribers, and its forum has over 143,000 members

Josef Prusa was lucky, but also did a lot of things well that we can all learn from.

How? Let’s dive in.

How to solve a problem of your own, give back, and build trust in growing communities

Before the roller coaster started, Josef enrolled in an economics degree to make his parents proud. This resulted in a lot of spare time, so he and his brother began DJing and building their music controllers.

Image

Josef (above), rocking his DJ skills. Little did he know how his life was about to change.

He was looking to make his own knobs and faders, but found the search into it too long and challenging. He then found the RepRap project and Mendel 3D printer.

Image

As you may know, RepRap is a community project started by Doctor Adrian Bowyer at the University of Bath and it kickstarted the desktop 3D printing craze.

The basic idea is that a 3D printer can print as many parts as possible for another 3D printer and as a result, decreases its cost.

But when Josef was building his Mendel Printer, he was finding it too complex. It required many different screw sizes, there were no slots for nuts, and very few parts were push-to-fit.

So he improved the Mendel by making a simpler version; the Simplified Mendel [sic], and shared the designs on GitHub with the rest of the RepRap community.

The community caught up with his simplified model and started using it over the original, and that’s when people started noticing him.

Takeaways:

  • If you’re a student, have spare time, and/or have no dependents, enjoy this time to experiment and try new things. What are you curious about building?
  • Identify and solve a problem of your own. What tools are you using? What’s currently frustrating you about them?
  • Fix or simplify what’s not working. If you don’t know how, what skills would help you? Learn those.
  • Share your solution in a community that’s active and that has the same problem. You’ll benefit from exposure and feedback to make your solutions better. This way you’ll start building trust among a like-minded audience and you’ll be in touch with what people want.

How to create your first prototype

When Josef was trying to solve his problem, printers were still missing one key component to have the ABS plastic print successful: a heated bed. Without it, prints warped and deformed away from the bed.

Image

To tackle this problem, he came up with a rudimentary prototype (shown above) which consisted of a resistance wire stuck between two sheets of acrylic. It didn’t last very long.

Image

Without letting the setbacks defeat him, he went on to create a second version. This one used a tile instead of acrylics, which was an improvement. But still, it only reached about 90 degrees Celsius, which wasn’t enough either.

Image

After nearly six months of persistent work, the PCB Heatbed MK1 (above) was complete. It was the first real product he created.

This new heatbed could reach 110ºC, more than enough for ABS and other high-temperature plastics.

But many parts of the heatbed were either too expensive or difficult to get, so he redid many on his own.

He soon started receiving requests to print his Prusa Mendel’s parts. He also organized a few local build events, where everybody could build their own parts.

There was so much demand that it was time for Josef to officially start Prusa 3D with his brother Michal.

What’s interesting is that he didn’t start with the company name, the logo, and so on – rather, he started with a problem he had himself, and then he shared publicly, both his problem and his solutions, with others.

By sharing what he was doing with others, people who had the same problem could order his solution. And there were many people who shared his problem, which translated into many orders.

It’s also important to appreciate the persistence and patience it takes to continue iterating for six months in order to create a product that works and one that people want to use.

Josef and his brother began selling their first parts without an e-shop and instead sold them through email and a phone number on a webpage. They also hadn’t perfectly optimized their packaging yet. In the beginning, they packed their heatbeds in a pizza box and shipped them off to their clients.

Josef and Michal didn’t let the lack of a perfect tech solution get in their way. They simply found a way that was good enough to get their idea out the door and then made it better as they went along.

They were also proactive in creating awareness and trust with their audience. In the early days, they kickstarted the community by organizing presentations and going to events to educate people about the possibilities of this new 3D printing idea.

Josef also embodied honesty in his sales. If people came to him but were looking for something he didn’t sell or was a poor fit, he just told them which technology they should use instead.

This earned him a community of loyal users who trusted him and regularly came back to share prints and hacks on the new Prusa Printer's online hub. Whenever Prusa was criticized in their Youtube comment section, a flock of fans spoke up in their defense.

Takeaways:

  • Start simple before having everything figured out.
  • Let go of perfectionism or trying to look like established companies. What is good enough for the stage you’re at to satisfy the needs of the people you can serve? If it’s packaging your products in a pizza box instead of providing a delightful unboxing experience, so be it. If it’s not having an e-shop but just an email and a phone number on a simple website, so be it.
  • Focus on creating a solution that solves the problem for good. It might take some time, but if it hasn’t been solved yet, there’s a good chance it’s because it’s hard to solve. Being persistent and patient requires you to commit and invest at the beginning, but once you get through the other side of the problem, you’ll have something people will flock to. It took Josef Prusa six months before he found a proper solution for his heatbed.
  • Be radically honest and defend the best interests of your customers. If there is someone else who can serve them better, redirect them there. This builds trust, as people will remember how you treated them with respect.

Should you do everything yourself, or delegate certain tasks?

When we start something and it gets some traction, or even if we just anticipate the traction it can get, thinking about everything that we have to deal with can become overwhelming.

There might be barcode visualization, trademark registration, label design, building walls, building websites, accounting, invoicing, digging drains, dealing with bankers, installing equipment, video-editing, dealing with customer support, and more.

Most of the time we’re not even remotely competent at more than one or two of those things.

So this is the time when we hit a fork in the road. Do we hire or outsource to delegate, or do we do it ourselves?

Prusa’s beginnings are an interesting example of how to go through this period and build for the long term. Below, Josef explains how they went about preparing to scale:

“We never had resellers so we were always in direct contact with the customers in the community and this proved very important for us because you have instant feedback from the people.

If you are just a manufacturer and somebody else is doing the selling for you, you don’t always get all the information back.

In the beginning, it was much tougher for us to do it this way because we not only needed to learn how to make the printers at scale but we also needed to learn how to run a big webshop and how to do the customer support for all these people. It was more difficult but now it’s paying off that we have this direct contact and know how to run every part of the business on our own.”

It wasn’t until October 2013, three years after finishing the initial prototype, that they hired their first employee, Hanka.

How do you get the cash flow to hire people? Well, you sell in advance and produce after. In the beginning, Prusa always had a two week lead time for customers to get a printer.

As they continued to grow, they also hired a Foxconn engineer to deal with quality and a couple more software engineers to lead the engineering team.

They could have spent months or years trying to raise funding through VC or Kickstarter in order to hire people, outsource production and grow much faster.

But they decided instead to invest in the slower and more demanding path of figuring it out on their own, and keeping contact with the customers and their needs. This path has proven to be a much better strategy in the long run.

In 2014, Prusa Research had a revenue of 149.000€, which then grew to 70 million €, employing over 250 employees in 2019 just by bootstrapping the business.

If you aim to change the system, you need to be able to exist independently of it.

Takeaways:

  • Embrace DIY and learn to do the critical parts of the business yourself. What skills do you need to learn? Where can you learn them?
  • Once you can no longer do it yourself, understand what needs to be done, and when you have enough cash flow, hire people to do the work with you.

What Prusa stands for

Prusa has exploded because it does a few things very well by always putting their customers' needs first without compromising their values or their price. This in turn helps them build a strong virtuous cycle for their development.

Prusa has a long-term vision

Josef knows what he wants Prusa to become. He wants his printers to be able to print any object with any material and through guided steps, much like a Thermomix for 3D printing. And he wants the least tech-savvy person to be able to operate it.

Having this clarity helps him and everyone in the company align their efforts towards a common goal.

They have amazing customer support

The company also keeps investing in the way it cares for its customers.

They go to great lengths to test every single part of their printers to ensure quality but even that isn’t enough to cover everything – so that’s why they have support.

Almost 20% of their employees work in customer support. They have 12,000 live chats per month in nine languages and deal with over 11,000 emails each month.

Prusa provides high quality products

Investing in making the designs of their 3D printers more functional, simple, and of high quality allows them to avoid competing with the nicer-looking but more expensive 3D printers.

They make an affordable printer

This means that they are not too expensive for everyday consumers, and not too cheap for companies.

They’ve also made their 3D printer upgradable because it saves money for their customers and it builds their clients’ autonomy by helping them learn about the construction of the printer’s hardware.

All Prusa's work is open source

Prusa’s clients are “normal Joes” as Josef describes them, and most don’t care much about open source. But the company does.

Those who care about open source provide valuable contributions that can be added back into the products. Some people will make improvements, some will fill in new code, and all of it helps make the printers better.

The open-source approach is also good for users. Those who want to do modifications find it much simpler because they have the original sources for the printer parts, the firmware, and the electronics.

Josef even has a tattoo of the OHSWA logo to keep himself accountable and honest to the open source vision.

Image Source: 3D printing Industry

Open source makes it easy for the idea to spread and upskill people who can find new use cases to increase the company’s pace of innovation, and it makes it more affordable to its clients.

They partner with distributors and support their clients even though it decreases their margins

Another counterintuitive thing Prusa does for its clients is that it supports the customers serviced by other distributors.

Many companies would forfeit this channel because it demands high margins and the distributors don’t do support. But they do these distribution partnerships anyway to make it easier for the people they serve to discover and access their printers.

And even if they make no extra money through these channels, they still give them the same level of support as those who buy from their website.

Why? Because caring for their customers is what makes it safe for them to then recommend Prusa to their friends and family, driving more business by word of mouth.

Takeaways:

  • What is the long term vision of what you’re doing? What happens as you keep developing your organization? What results are you helping people achieve?
  • How can you invest in better supporting your customers?
  • What parts of your project can you give away for people to build and learn with you?
  • What partnerships can you build to distribute your project in places where people need it?

How Prusa Builds and Invests in the Community

We’ve already spoken a lot about how much they invest in customer support, but Prusa also invests heavily in their community.

This does two things: it builds proof of what their product does in the world, and it helps scale even further what their customer support service can do.

To gather their community they do a few things.

The first thing Prusa does is offer two options to customers: They can either buy printers as kits or assembled. 80% of clients buy the printers in kits. Besides saving time in production, this allows the clients to learn how to build their printers and understand how they work.

This approach is raising a generation of makers who can create and fix instead of throw away, building a lot of goodwill for the Prusa brand.

To keep in touch with the community, in the early days Josef Prusa tried to go to as many shows as possible so that he could talk to fans face to face and hear about the awesome projects that could come to life with the help of their printers. He went to Maker Faires and to DIY or 3D-printing events.

Now that the company has grown so much, he can’t go to as many events. But before the pandemic started, there was a team of three to ten people traveling around the world two to four times a month. And they were also organizing their Maker Faire in the Czech Republic.

Takeaways:

  • Where are your community members hanging out? What blogs or magazines do they read? What podcasts do they listen to? What events do they go to? What youtube channels do they watch? What newsletters do they subscribe to? Who do they follow on Twitter, Facebook, or Linkedin? What forums or groups do they participate in?
  • What resources do they need to get started that you can facilitate? How can you give them the tools to create what you do?
  • How can you invite users to participate in the development of your product? Can you open your files and designs for them? How can you invite them to give back and showcase their work or the skills they’re building thanks to you? Where could you use this as proof that your product works?

How to Engage the Community

Many people understand the value of giving free stuff away online to attract a crowd. But I feel that many entrepreneurs haven’t embraced the opportunity and the value of connecting the people in their community with each other.

This is a very powerful idea that can go a long way in building trust and reciprocity with your brand and in getting the community members to spread the word and interact with stories of what you do.

One more powerful thing that Prusa is doing is figuring out how to connect the isolated Maker tribe, and at scale.

Once they gather their community by giving away their designs and connecting with them at events, the next challenge is getting these people to engage. And Prusa does a remarkable job at that.

They’ve created a series of resources that make it easy for people to learn the skills and tools they need to become active members of the community.

In their online hub, they share resources for learning and practice, such as a library of 3D printing models with files, and free guides on how to start 3D printing.

Once people are on their website to grab these resources, they can connect with each other locally or online through a map or in the forums to reach out for support or to go for a beer.

As a quick overview, Prusa provides the resources needed to learn the tools and the skills required to set up and hack a 3D printer. There are manuals, such as a free ebook to teach the basics of 3D printing, assembly instructions in video and ebook form, troubleshooting guides, and of course the downloadable drivers and firmware.

Once people have what they need to learn the basics, they can jump into the Forum to talk about their printer model, stay up to date with General Announcements and releases, find those community members in the Hall of Fame, and discuss the software.

Takeaways:

  • What resources does your audience need to develop the skills required to use your product and to participate in the community in order to help each other?
  • Once they trust you, how can you connect them to find support among their peers? What exchanges can you facilitate or what spaces can you create for them to gather and talk about their questions?

In Summary

Prusa’s approach helped them grow over 17,000% without a sales team, only through word of mouth.

It helps that they serve the fast-growing 3D printing market, but still.

Prusa has become a big player and a beloved brand in their industry, proving that you don’t need a huge marketing team or budget to get similar results. You just need a smart and intentional plan.

Here are the key takeaways you can borrow, modify, and adapt for your own business based on Prusa’s real-life marketing tactics:

Takeaway #1: Build a skill to solve a problem of your own

What tool are you using that is not working as you wish it did? Learn the skills to fix or simplify what’s not working.

Takeaway #2: Share your solution in public

Once you create your first working solution, share it with communities who already use these tools and have the same problem as you do.

This builds trust, reciprocity, and if people want to buy your solution or they have other problems you can build on, they can tell you.

Takeaway #3: If it’s your first time, be patient

When we first start, we don’t have all the skills we need to find a solution to a problem. Be patient and persistent and embrace failure and rejection. It’s by getting into action that you’ll figure out what’s not working or missing, and what needs adjusting.

Takeaway #4: Start simple, even if you don’t have everything figured out

Let go of perfectionism or trying to look like an established company. What is good enough at the stage you’re at to satisfy the needs of the people you can serve? What is good enough for now to solve other people's problems, build your product, and ship it?

Takeaway #5: Learn to do everything yourself and become autonomous

Don’t delegate too soon. If your goal is to change the system, you’ll have to learn to be autonomous early on and stay in close contact with your customers.

When the time comes to delegate, you’ll know what needs to be done and hire the right people for it.

Takeaway #6: Be radically honest and defend the interests of your customers

If there is a competitor who can serve them better, redirect them there. It will build trust as people will remember how you treated them with respect.

Takeaway #7: Be clear on what you stand for

What is the long term vision of your project? If money and growth is a means to an end, what is that end meant to achieve? What can you do to accelerate or scale this?

For Prusa, it was investing in outstanding customer support and sharing their work in open source to create both a delightful experience and to involve outside experts in their innovation.

Takeaway #8: Find and gather your community

Go meet your community where they hang out to stay in touch with their needs and to connect with them. What forums or groups do they participate in? What events do they go to?

Once you’ve found them, create spaces for them to gather and connect. Josef Prusa started by participating in the RepRap forums and by going to Maker events. Later on, they started organizing their Maker Faire in the Czech Republic.

Takeaway #9: Engage the community

Give them the resources and tools they need to get started. Then invite them to participate in the development of your product by opening your designs.

For those who contribute, you can showcase their work and skills to show your gratitude, and use these contributions also as proof that your product and community work.

Thanks for reading. Inspiration for this article came from The Road to 100,000 Original Prusa 3D printers. You can watch it here:

]]> <![CDATA[ How to Beat Coder's Block – Five Tips to Help You Stay Productive ]]> https://www.freecodecamp.org/news/how-to-beat-coders-block-and-stay-productive/ 66d45d9f246e57ac83a2c6fd Tue, 23 Mar 2021 19:08:01 +0000 By Andrej Kovacevic

As programmers, we all share a certain number of universal experiences.

One is an enduring hatred of semicolons, brackets, and parentheses (who hasn't wasted hours looking for the one of these they misplaced or omitted?).

And another is learning to use compile-time for a convenient break when we don't feel like getting anything done (I won't tell if you don't).

But the most universal programming experience of them all is what is now known as coder's block. That's when you end up unable to produce any usable code for no discernible reason.

Like writer's block, it can afflict programmers suddenly and can be near-impossible to overcome. I know, because it used to happen to me. A lot. So often, in fact, that I developed a self-defeating habit of taking career quizzes because I thought for sure I was in the wrong line of work.

Fortunately, I've picked up several ways to deal with coder's block that have kept me working smoothly ever since. And I think that they'd work for anyone prone to running into coding roadblocks.

Here are the five best tactics you can use every day to stay productive and free from coder's block.

1. Start Every Project on Paper

Almost every time I've run into trouble while working on a coding project, I've been able to trace it back to one specific cause. It's that I tried to approach the project by wrapping my head around the totality of what needed to be done.

When you do that, it's easy to get overwhelmed by the sheer enormity of even a run-of-the-mill coding project. Plus, starting to write code without a concrete idea of where you need to take it is always a recipe for disaster.

Instead, make it a point to sketch out the rough outlines of your project on paper first. It's something that old-school programmers do by habit, but that younger programmers tend to skip over.

All you have to do is to write out the purpose of the program you're trying to create, followed by a list of sub-functions that you think will make everything work.

This simple act helps you to break the project down into smaller logical chunks that don't seem as daunting. Also, it gives you a chance to pre-discover obvious issues that might slow you down later.

Once you've done this, you can translate your work outline into the online calendar solution of your choice. That will help you visualize all of the small mini-tasks that make up your project.

In my case, just seeing the timeline of a project from beginning to end makes it far easier for me to focus on one logical chunk of the work at a time.

Maybe it's because it takes away the overwhelming sense of scale of a project, or maybe it relieves the perception of time pressure to get each portion done. Either way, it's a far less anxiety-ridden way to work.

2. Play in a Sandbox

Sometimes the best way to overcome coder's block is to build something – anything – that works. So, if I run into a rough patch where it feels like I'm getting nowhere fast, I'll head over to a sandbox platform and try to build something fun.

Because I tend to deal with web front ends, my go-to sites are CodeSandbox and CodePen, but there are others that might suit your needs a little better.

For example, Replit will let you live code in over 50 languages, and you can even turn to their built-in community to ask for help if you get stuck on something.

Sometimes throwing ideas back and forth with another programmer will be enough to help you break the mental logjam that's keeping you from moving forward with your work.

3. Maintain a Task Backlog

One thing that contributes to my own coder's block is not having a list of simple tasks that I can turn to when I want to keep making forward progress on a project.

In other words, when you're working on something particularly challenging and you get stuck, you don't want the alternative to that challenging thing to be nothing at all. That's how you end up banging your head against intractable problems and getting nowhere fast.

To avoid that, you should always maintain a running task backlog list for the duration of every project. I use one similar to a standard Scrum product backlog (even when I'm not working with a team).

Fill it with things like code refactoring and cosmetic changes – in other words, simple low-priority tasks. Then, when you get stuck, you can tackle those simple things as a means of continuing to move forward with your project.

Sometimes, completing even the simplest task will be enough to get you back on track and churning out meaningful code again.

4. Use Breaks Strategically

Image Image: Monstar Studio / Adobe Stock

If you take a moment to look up coder's block on your favorite search engine, every article you see will recommend taking breaks to get your mind off of a difficult programming challenge.

Well, that advice is a double-edged sword if there ever was one. It's a slippery slope from taking a break to perpetual procrastination. And if you aren't careful, your breaks will become another part of a much larger problem.

I recognized this when I first went looking for tips on overcoming coder's block. At first, I was pretty responsible with my breaks – just a five-minute walk or a trip to the coffee machine when I wanted to clear my head.

But soon, I found myself looking for reasons to stay distracted from whatever I was stuck on. Like when I went hunting for the best VPNs for Netflix because I wanted to know what other foreign-language series' like Dark they were hiding over in Europe. Or when I spent half of a day scouring the internet for a reasonably-priced PCIe video card that didn't require getting on a waiting list (thanks, cryptocurrencies).

The point is, taking breaks is a reasonable way to try and break through coder's block, but only if you use them strategically.

I eventually found that using time-limited, computer-free breaks works well as the final step in a deliberate reset process for my brain. When I get stuck, my process looks like this:

  • Spend 15 minutes working on the problem
  • Take 5 minutes to review things from the top
  • Spend another 15 minutes working on the problem
  • Walk away for at least 10 minutes to do something unrelated to coding
  • Start again from the top

Almost every time, I'll find the answer I was looking for after taking that 10-minute break. But that's why it has to be a short break followed immediately by getting back at it. Any longer and you risk getting so distracted that you'll have forgotten where you left off, logic-wise.

And if you're lucky, you won't have to repeat the above process all that often. That way, you can stay focused and avoid wasting too much time on unproductive tasks.

Be careful, though, not to skip out on breaks entirely. You do need to step away from your work now and then just to stay sane.

In my case, I ended up making up for taking fewer breaks by building some time into my morning schedule to follow along with exercise channels I've subscribed to on YouTube. It helps me burn off some energy so I don't feel like getting up and breaking my focus while I'm working. Plus, it offsets the toll that sitting at my computer all day would otherwise take on my health and well-being.

5. Always Leave a Breadcrumb Trail

When it comes to coder's block, the old saying that an ounce of prevention is worth a pound of cure couldn't be truer. That's why I've picked up the habit of controlling when and how I leave off my work in the middle of a coding project.

I do this because I found that getting interrupted and failing to complete whatever I was in the middle of caused nothing but headaches when I tried to pick up where I left off.

Instead, if I need to stop working on something, I'll leave specific and detailed notes telling me what I was about to work on next. Even if I'm in a hurry, I leave that trail of breadcrumbs so I don't have to backtrack my work when I return.

First, it saves me the trouble involved in getting back into 'programming mode' because I don't have to think too hard to pick up where I left off. And it also means I won't fall down the rabbit-hole of overanalyzing code that's already complete while I look to find my place.

Both issues can slow you down and contribute to you falling into a case of coder's block. And once I started making a point of leaving myself a trail of breadcrumbs to follow, I never had either problem happen again.

Become an Unstoppable Coder

Image Image: deagreez / Adobe Stock

I can't promise you that these five tactics will keep you from ever suffering from coder's block. But what I can tell you is that they will help you stay away from some of the common situations that lead to it.

Since I made them a part of my coding routine, I haven't managed to stay stuck on anything for more than an hour or two here or there. And that's coming from someone that came close to giving up and finding a new career on more than one occasion.

And if they work even half as well for you – you'll be unstoppable! Just make sure to take a vacation every now and then so there will be some work left for the rest of us.

Featured image: DragonImages / Adobe Stock

]]> <![CDATA[ Do You Need a Computer Science Degree to Get a Job in Tech? ]]> https://www.freecodecamp.org/news/do-you-need-a-computer-science-degree-to-work-in-tech/ 66d45e05f855545810e9341b Wed, 27 Jan 2021 23:54:56 +0000 By Dave Gray

If you want to get into tech, you might have heard that you need a computer science degree. Well, maybe not...

I teach web development courses at a state university.

I am also a full-time developer. I am adjunct (part-time) faculty for a couple of web development courses per semester.

You may be conditioned to think a college degree is an essential part of a good career. Your parents or the world in general may have drilled these thoughts into you.

And a degree CAN be the beginning of a good career, but I do not think a degree is the only path to success.

I'll explain...

There is nothing wrong with being a self-taught developer.

Let me repeat that: There is nothing wrong with being a self-taught developer.

There are more resources freely available than ever before. If you have the focus and discipline to plan out your own learning path and the determination to stick to it, you can succeed.

In fact, I believe the developer community is very supportive and many enjoy sharing their knowledge on sites like freeCodeCamp, Twitter, and Youtube. The process of teaching helps all of us learn.

I started my own YouTube channel featuring Web Development and Programming Tutorials with this goal in mind.

What to Know if You Are Considering a CS Degree

You should be focused on what you want to do. Have a plan and turn that into a degree plan if you attend a university.

If you aren't focused on what you want to do, you may waste money and time (which is even more valuable) attending classes you aren't interested in and going into debt. What do you want to do? Do you know?

I'm not asking what your parents think you should do.

I attended college immediately after high school because my parents insisted. I ended up changing majors multiple times over 4 and a half years because I was lost. I wanted to be a musician on the road with a band and not a student. My parents needed to let me find myself.

Self-discovery has value

Likewise, I think going to college to discover yourself and your interests through trial and error is not affordable for most. Ask those you know who have completed a degree if they were focused or changed majors one or more times. Ask them what they would do differently now.

To the dismay of my parents, I quit college and went on as a full-time musician. Within 3 months, I knew I wanted to go back to school. This time it was different. It was my decision. My grades improved. Now I had the desire to learn.

Ownership of your own path has value

If you are focused and know you want to be a web developer or software engineer, a traditional education may still not be right for you.

How focused and disciplined are you?

A traditional education provides a learning path for you as well as a strict schedule. Some students need this accountability to stay on track. Some struggle more with remote learning than others, too.

It is really about identifying what helps you learn and succeed as a student.

My oldest son is a full-time developer. He quit college in his first year. He did not like the general education courses required for a traditional degree. He focused on learning to code and is self-taught.

His skill and expertise have kept him consistently employed. He realized what worked best for him and followed that learning path.

Will a degree open some doors and position considerations? Yes.

Is it mandatory to work in the field? No.

What to Know if You Are Changing Careers

I did not major in computer science. A web development major didn't exist when I was earning my graduate degree. I learned the skills I now teach after - not while - completing a graduate degree. I am self-taught.

I am qualified to teach university courses due to significant experience in the field and earning a higher degree. I have continued to learn every year. I am now working on a PhD in Information Systems which leads me to an important point:

You must be a life-long learner.

The days of keeping one job for your entire career are mostly gone. Developers are constantly learning new skills - especially in computer science and web development - to keep up with the pace of the industry.

The tech I teach now didn't even exist at the time I graduated.

What I still hold with me to this day from my time on campus are the friendships I made and the discovery of a world view that was outside of my own little bubble.

These are the things I still value the most as an instructor. I have made friends with colleagues that are from opposite sides of the world. I have taught students from all over the world that have gone on to their own careers. I now value their friendship and contacts as well.

Get out of your comfort zone and constantly grow your network.

Do I regret earning a degree?

Not at all! In fact, I'm still a student working part-time towards a PhD in Information Systems. For me, "this is the way".

So what should you do?

That's really up to you! The ancient Greek maxim is "Know Thyself".

Today, we just say "You do you".

If you have the focus, discipline, and desire to be a software engineer or developer, you will succeed no matter the path you choose.

I wish you the best!

I'll leave you with a video tutorial I made about starting your coding journey:

]]> <![CDATA[ What I Wish I Knew Before I Started Learning to Code ]]> https://www.freecodecamp.org/news/what-i-wish-i-knew-before-i-started-learning-to-code/ 66d46042246e57ac83a2c79e Tue, 15 Dec 2020 16:11:26 +0000 By Nick Bull

Hi, I am Nick. I wrote my first line of code 9 years ago.

Like everyone else who started programming, the only thing I cared about was writing code.

For me coding was some kind of magic, you type something on the keyboard and the computer instantly shows you the result of your work on the screen.

But...

This magic started to come to the end when I met the real world and got my first job as a full-stack developer 6 years ago.

During these years I have faced the good, the bad, and the ugly side of a programming job. And I've learned 4 essential things about coding and having a coding career that could have easily helped me achieve 297% more over these years if I knew them when I started.

Coding Is Not About the Coding

What do you think programming is about?

Writing code?

Writing good code?

No.

That's just a part of the whole.

Programming is not about coding, programming is about solving problems with coding.

End customers don’t care what technologies, languages, frameworks, or methodologies you use. They care only about one thing: whether your product solves their problem or not.

That’s why relatively few people care what technologies Google search uses under the hood. As long as people can find relevant information with it, they will use it.

This is the number one thing I wish I knew when I started programming.

I would spend less time writing the “best code” and more time solving the customer’s problems in the quickest and best way I could.

Don’t write code just to write code. Solve your customer’s problems with the code.

Communication Skills Are More Important than Coding Skills

When I just started my career as a programmer, my lack of social skills was not my main problem. But when I moved higher, to a middle, senior, and then leadership position, my weak soft skills became my Achilles heel.

When you work on a product with a group of different people (engineers, designers, managers, and so on), communication is the only thing that makes you a “team” and helps you effectively develop the product.

A lack of good communication or social skills does the opposite. It increases your product development time and decreases overall productivity.

Here is a real situation you might face:

The leadership team tells your product manager that they want to create a new product feature and put it in the next product release. It’s not urgent, they just want to release it as soon as possible (as always).

The product manager calls you on Zoom, tells you what you need to build, and asks, “How much time do you need to build it?”

You do a rough calculation and tell them, “I need 20 hours.”

The Product Manager is not satisfied with your answer. They want to release it as soon as possible and show the management that they can deliver results fast (this is a very common situation).

So they ask you, “Can you build it in 10 hours? We really need this feature in the next product release!”

And you know that you can if you cut the corners (no tests, messy code) but then you will need to refactor it, and it will take an additional 30 hours. Because other engineers will work with your messy code when you release it. And after refactoring, you will need to integrate their code with yours.

So here’s what will happen next. If you have bad social skills, you will not convince the Product Manager that you actually need 20 hours to build this feature.

Why?

Product Managers often have good social skills, from my experience. So if you can’t convince them that refactoring later is worse than spending 20 hours right now, they will easily argue with you and convince you that “refactoring later is okay.”

And then the whole team will lose that additional 30 hours while you're doing this refactoring (I'm not counting the time it might take to fix unpredictable bugs, either).

But if you have good communication skills you will more easily be able to convince you PM of the opposite.

So improve your social skills as well as coding skills (send memes in the group chats on Slack or something :) ).

And remember one simple truth:

People work with people, not machines.

Programming Is a Lot Easier if You Know How to Learn

When I started to learn JavaScript, it was hard. Because I learned the wrong way.

Read a lot of theory without the practice, no routine, no end goal. Chaos.

I thought it was normal to learn like this. Until I discovered deliberate practice.

It’s a purposeful and systematic type of practice (learning).

The difference between normal practice and deliberate is that to engage in deliberate practice, you need to really focus. And you have to have the specific goal of getting better and improving your performance.

After I applied a deliberate practice, I began to notice how fast I was progressing with learning JavaScript. My knowledge started to stick for a long time, not just for 5 minutes after tutorials. I created my end goal, articulated why I was learning JavaScript, and understood what I needed to learn, and what I didn't.

So here is what you need to perform deliberate practice on your own:

  1. Find a teacher: provides practice activities designed to help you improve performance.
  2. Try to perform at maximum effort: constantly being taken out of your comfort zone.
  3. Have well-defined and specific goals: not just “overall improvement.”
  4. Make sure you focus: give your full attention, no distractions.
  5. Complete deliberate actions: no autopilot.
  6. Respond to feedback right away and modify your strategy.

When you start learning a new language, technology, framework, or whatever, stick to these rules to get big results as quickly as possible.

10X Engineers Don’t Exist

At the beginning of my career, I thought that a great programmer is a person who knows tons of programming languages, frameworks, and methodologies.

I was wrong.

Such a mindset only gave birth to my impostor syndrome. I thought that I didn't deserve my current position, my salary, that I was a “fraud.”

So I started to follow every popular developer on Twitter, read every technical publication, and pour over thousands of developer blogs just to convince myself that I deserved what I had and to feel closer to the title “great developer.”

This was not a healthy behavior.

But it helped me to discover that a lot of people I followed (who I thought were 10X engineers) actually didn’t know a lot of things.

They might have known how to do some complex tasks that required deep knowledge in a couple of fields, but at the same time they didn't know some basic things. Like they knew how to design highly scalable database architectures, but they didn't know how vertical-align an element with CSS.

Big thanks to those developers, like Dan Abramov (creator of Redux) for creating resources like this article. They helped cure my imposter syndrome and showed me that it is okay not to know something.

In the end...

If you like this article, share it with your friends and follow me on Twitter.

Quick note: I’m creating a JavaScript course where I’m using deliberate practice to combine modern and practical JavaScript theory with a lot of real-world practice to teach you how to become a skilled JavaScript developer with knowledge of modern language features. Join here.

Also, every week I send out a "3–2–1" newsletter with 3 tech news, 2 articles, and 1 piece of advice for you.

Know the latest news, subscribe to my 3–2–1 newsletter.

]]> <![CDATA[ How Not to Break Production – My Two Big Coding Mistakes and How to Avoid Them ]]> https://www.freecodecamp.org/news/production-mistakes-and-how-to-fix-them/ 66d45f719f2bec37e2da062c Mon, 05 Oct 2020 20:24:59 +0000 By John Mosesman

In this article, I'm going to share with you my two biggest production mistakes.

Luckily, there's only two of them.

It's not that I haven't made a ton of mistakes in production—I have—but these two in particular required me and the rest of the team to put our heads together and work to revert the damage.

When your mistake takes a team of five the rest of the day to fix it tends to stick in the 'ol memory bank.

I'm not ashamed of these mistakes – it was a little embarrassing in the moment sure – but they were honest mistakes and mistakes happen.

I'm sharing these stories with you so you can know what to do when you inevitably break something in production. And if you stick around in the development world long enough, you will.

But, no one has to lose their heads. [Spoiler alert] I wasn't fired from either job, and I wasn't even really reprimanded either. People make mistakes and the other people on your team and in your company understand that.

Test, hope, and pray

Over time, the development world has adopted practices to help reduce the chance and severity of mistakes.

We write automated tests. We test changes in a staging environment. We do code reviews. We systematize or script our deployment processes.

All of these practices catch or squash a countless number of bugs every day.

But, regardless of all of these practices and processes, mistakes still happen. In the end we're still human, and humans make mistakes.

We miss edge cases. We forget to check the layout in IE9. We delete the wrong record. We bring down half of the internet by passing the wrong parameter to a deploy script.

The mistakes I'm sharing with you fall somewhere in the middle of these, and the first one starts with my very first development job.

First job – first mistake.

I made the first of these mistakes during my very first development job.

I had only been at this job for maybe a year or so, and the team I was on built internal applications to help power the rest of the work the company was doing.

We built customer support and management tooling, but we also setup and managed the databases and web services built on top of those databases that powered the company's products.

In short, we were in charge of a lot of really important and (too) complex SQL queries and databases.

This was my first developer job, and I was scrapping to learn SQL as fast as I could.

We had a QA environment ("quality assurance") aka a test environment with a copy of every database to test against, and new developers like myself were not given write permissions to the production databases (and rightfully so).

To get a change made in production, I first had to write and test the query against my local database.

After I believed it was good locally, I had to then request a "code" review from a more experienced team member who would review the query and, if it was solid, run any structural migrations in the QA environment. After that I could then test again in QA.

Once I was confident that my query worked in QA, I had to then request another code review and ask that the query be executed in production.

All well and good right? Lots of room to practice and lots of checkpoints to make sure things that went into production were solid.

Putting on my big boy pants

After a while of repeating this process successfully, I began to get production write access to a couple of these databases—ones that I was familiar with and were directly relevant to my work.

I had proven I was careful and I could be trusted with production access (you already know where this is going).

If you aren't familiar with SQL, there are a few different types of queries you can run.

Sometimes you just want to retrieve information, and sometimes you want to insert, update, or delete information.

The majority of the queries you write are SELECT – queries to retrieve information. Only occasionally do you do an INSERT, UPDATE, or DELETE.

So, most of the time your queries are harmless. A SELECT doesn't change any data, and there's no risk of something going wrong.

But, sometimes you do need to change that data—and that's when you have to be really really careful.

An UPDATE gone wrong

I don't even remember what task I was doing or why I was doing it.

The only thing I remember now was that blasted UPDATE statement.

I was updating something that involved customer information—updating something like their name, email, or address.

I had written a statement that I believed was correct, and I was testing it as a SELECT:

--UPDATE users SET name = 'blah', ...
SELECT * FROM users
WHERE ...

Notice the UPDATE statement that is commented out above the SELECT. This was a handy format I learned at this job that helped reduce errors in running your queries.

First you write a commented out UPDATE statement with the values you want to set. Next, you write a SELECT below that statement and use the SELECT to test and finalize the result of the query.

By commenting out the first statement you eliminate the possibility of accidentally running the UPDATE before you're ready. The only way to run the statement is to either uncomment it (which takes an action), or by highlighting the text after the comment along with the rest of the query and then running it (which is also a deliberate action).

This little technique prevents many mistakes. But back to my query writing.

When I was ready, all I had to do was uncomment the UPDATE line, comment out the SELECT line, and hit run.

Now the example statement I showed above is greatly simplified compared to the query I had written back then.

The statement I had written back then was a decently complex statement. It had a lot of joins, subqueries, and it was checking some range of orders or products or something else—not just a simple WHERE id = blah kind of thing.

It probably looked more like this:

--UPDATE users SET name = 'blah', ...
SELECT * FROM users
JOIN something
  ON something.user_id = users.id
JOIN another_thing
  ON another_thing.something_id = something.id
WHERE 1=1
  AND something.blah = 'bleh'
  AND another_thing.bleh = 'blah'
  OR (
    users.name <> 'Karen'
    AND thing = thing
  );

(This is not a "the fish was this big" story I swear.)

I checked that the users I got back were the users I was expecting. I had verified it locally, tested it in QA, and I had gotten approval by a team member to run it in production (see it wasn't my fault (I'm kidding)).

Here's where the problem comes in. And before I tell you what it is I'll give you a little pro tip that will prevent it from ever happening to you.

When running a query that will do a write to the database: drag your cursor from the bottom of the query to the top of the query.

Why drag it from the bottom to the top you say? Good question.

Bottom to top

Let's say I start at the bottom of this query and drag my cursor up halfway and run the query:

image of halfway drag Dragging bottom to top but incomplete

What happens?

Well, nothing.

I didn't select a valid query. The query parser will throw an error and say silly John this isn't a valid query you silly goose.

Oh thanks query parser! No big deal. I'll try again:

image of full query Dragging bottom to top complete

Now I've selected the full query, and it runs. Yay!

All good right?

Now what if you're working on this query and due to the size of your window or the scroll position of your query tool you start at the top of the query and drag to the bottom...

top to bottom Dragging top to bottom with what you think is the full query

This query runs—but oops! The rest of the query was outside of my viewable area, and I've only included half of my WHERE clause!

Image Dragging top to bottom but missing part of the query!

And just like that, it happens. The UPDATE goes awry.

This is exactly what I did.

I ran part of the query, and it was missing some of the filtering conditions to properly limit the result set I was acting on, and I ended up updating the entire users table to one person's information.

Every single user in our system was now "John Smith at 1234 Main Street Ave".

I had goofed, and I realized the problem too late.

So what did I do?

"Secret secrets are no fun. Secret secrets hurt someone." - The Office S03E15

Here's the first major takeaway (aside from that sweet bottom to top query tip): if you make a mistake—tell someone. Immediately.

It can be very tempting to try and hide or ignore the mistake you made—especially if it's serious. I've been there. I've felt those impulses.

You realize your mistake and the dread sets in. Oh no what have I done.

When this happens, there's a few things to remember:

  • Every developer of reasonable experience has made production mistakes
  • Many of these mistakes are time-sensitive
  • I don't know anyone that's been fired over an honest mistake

Every developer has made production mistakes. I've made them, and I'll make them again (but hopefully not the same ones). Anyone who would criticize you for it is either inexperienced or a jerk. Either way you shouldn't care.

Many of these mistakes are also "time-sensitive." This means that the sooner you can fix the problem or revert the change the less damage will be done. Waiting to acknowledge the problem can result in a more difficult process fixing it.

Of all the mistakes I've made and all of the mistakes I've seen others make, I don't know of a single person that has been fired or even seriously scolded over an honest mistake.

I think this is because programming is hard and anyone who's made it into leadership has done something similar or worse.

So here's what you do:

  • Own up to it
  • Own up to it quickly
  • Work to help fix it

Own up to the mistake. Don't shift blame or make excuses—just explain what went wrong and what you've seen or done.

Alert your boss or team lead as soon as you recognize the issue. The severity of the alarm you raise is probably proportional to the size of the mistake.

"Oops I messed up the validation for that field, I went ahead and made another PR to fix it."

If it's a small thing, maybe you can just make a new PR fixing it and tell someone to review it. Small issue, small fix—no biggie.

If, per chance, you update a production table with one value across the entire table—you raise the alarm quickly.

Updating an entire table

As soon as the oh no set in, I grabbed my team lead and told him what happened.

Thankfully he was cool about it, and we set to work trying to undo it.

The unfortunate thing about a bad database update is there's not really an easy way to revert that change. You can't just revert some commits and re-deploy—a database is persistent storage for a reason.

When something goes wrong with the data you have a couple options:

  1. Write a new query to undo the data (if possible)
  2. Load up a database backup and find the correct data, pull it out, and run a new update
  3. Head to Mexico

As enticing as #3 sounds, we went with #2.

Now this happened almost ten years ago, so devops was a bit different back then.

This company managed their own servers and databases and had "tape backups." They also only kept daily backups, so at best we could get data from early the previous day.

Needless to say, this was going to be painful.

To make a long story short, we tried to see if there was a way to re-create the original data and re-update it. After a couple hours we had the data back to its original state—but that's not the important part of the story.

The important part is to admit the mistake. Try to fix it. Learn and don't let it happen again.

If you make a mistake, your teammates will greatly appreciate you actively working to try and fix it. Even if that's just pairing and watching them fix the issue, dive in and take part.

Finally, learn from that mistake and don't make that same mistake twice.

(Drag bottom to top.)

Mistake #2: 7 years later...

After that period I enjoyed a long mistake-free period of about seven years—at least for major mistakes.

Now seven years later, instead of the title Junior Developer I was wearing the shiny hat of Senior Software Engineer (wooOoOo).

It was just like any normal day. Writing code, pushing it up, code reviews, deploying—just an all-around general crushing of the codes.

I got a ping in Slack about a bunch of background workers that were failing. My coworker said that it looked related to my last PR I had recently merged.

"Ok thanks I'll check it out", I replied.

Yep, there were definitely a good amount of jobs failing and they were piling up.

I wasn't too alarmed. Background jobs are generally written in an "idempotent" way—they're generally safe to just re-run when they fail. Most background queueing systems also have a built-in way to automatically retry the jobs after they fail.

It wasn't long after that, however, that things took a turn for the worse.

The alarm bells began to ring—or more realistically—the Slack notifications in the on-call room began sounding off.

Timeouts after timeouts after timeouts. Database usage was reaching 100%. The whole system was coming to a deadlock. All of the companies' products were coming to a standstill.

Oh no.

I didn't know why this was happening, but I knew it was bad.

And so I did the only thing I knew to do: log off and head for Mexi—I mean tell someone immediately.

We jumped into a Zoom call (before Zoom was well-known to the entire world thanks 2020).

As we investigated the matter, we noticed that a particular query was taking a really long time to complete.

Each instance of this query was taking several minutes to run, and there were an ever-growing number of them being kicked off every minute.

We began to look at recent commits in the area of the codebase where the problem seemed to be coming from and we found something suspicious: my last pull request.

In this pull request I updated a background job and changed its behavior.

This project was a Ruby on Rails codebase, and the change I made was something like this—but if you've never seen Rails before, don't worry, I'll explain each line:

def run(some_status)
  items = Item.where(status: some_status).all

  items.each do |item|
    # do some database querying and updating
  end
end

This background job calls a function, run, and a status value is passed in as a parameter (some_status).

The first line of the function queries some records from the database.

This line uses methods from the ActiveRecord portion of the Rails framework, but it's really just some nice wrappers around basic SQL queries.

items = Item.where(status: some_status).all

This line is really just a simple SQL statement:

SELECT *
FROM items
WHERE status = ?

When the query is run the value of some_status is bound to the placeholder (?) in the query and then executed.

After the database returns the results of the query, Rails takes these records and creates nice and neat Ruby objects out of them.

So in summary, we query the items table where the status is a certain value.

(Again this is probably not exactly what I was doing but it's close enough to illustrate the scenario.)

The next few lines are a simple loop over the items we retrieved, and for each item we do some more database querying and then update some information on the item.

items.each do |item|
  # do some database querying
  # then update the item
end

Pretty simple right? Get the stuff. Loop over the stuff. Update the stuff.

However, there's one thing I didn't realize here—and it's a big one.

Little 'ol NULL—or nil

The status field doesn't have a NOT NULL constraint. This means that the status field can be NULL—or in Ruby land: nil (or null in other languages).

It's easy to get used to querying based on things like IDs which you know will always be present. A similar line like...

items = Item.where(id: list_of_ids).all

...would not have produced the same problem. A query looking up records by their ID with a blank list of IDs returns nothing, and so nothing is done.

But in this case, here's the problem. This part of the code:

items = Item.where(status: some_status).all

Is looking up all Item records by a specific status—the one passed in via the some_status parameter.

But, this column value can be NULL (or nil).

So, if the some_status parameter happens to be passed in as nil, it would try to look up all of the Item records where status = nil.

Ok, but that doesn't sound so bad right?

Well, the next layer in this onion of awful is the fact that this items table contained 40 million rows—and most of them didn't have a status.

This little function that was originally trying to load a few records, loop over them, and do some work was now looping through the entire table.

So, when every one of these hundreds or thousands of jobs that were getting kicked off on a steady interval (if I remember correctly about every 15min) started up, each of them started performing very expensive queries for almost every record in the table.

That alone was probably enough to sink the system, but it actually got worse.

You see, I wasn't expecting a nil value to be passed in. This nil value also broke some of the code that the job was supposed to be doing, and so each of these jobs started to fail in turn.

Normally this wouldn't be a big deal, but in most systems when a background job fails it is re-enqueued a short time later.

So not only are all of these very expensive jobs failing, but they're all failing and starting up again a short time later—and they just kept stacking up.

The failing ones eventually would be met with a fresh batch of new jobs starting on their own interval, and the system just ground to a halt.

The final straw is that the work that this background job was supposed to be doing was updating all of those records.

That meant that I was looping through every record in this table and again updating the entire table with bad data.

By pure luck, I had one saving grace here.

The result of this query wasn't ordered. That means that by default the oldest (or first) records of the table were returned first.

That may not seem relevant, but the first and oldest records were effectively legacy data—so updating these records wasn't nearly as bad as records the customers are interacting with every day.

Also, the job kept crashing early in its execution and restarting—which resulted in the jobs only updating the same small and old portion of the table over and over again.

This meant that these jobs never reached the more newer, more relevant rows of the table.

Basically the job only updated a small, insignificant portion of the table before shutting down and trying it again (if I remember correctly only a few thousand rows out of the ~40 million).

It was like I had metaphorically tripped and fallen while walking up to a crosswalk—which kept me from being hit by the car that was going to run the stop sign.

A simple fix

As we reviewed my PR on the Zoom call someone eventually found the error and pointed to the offending line (the query looking up the records by their status).

Even after they said the problem out loud, I still didn't see it. After they tried to explain it again (and maybe even again another time), it finally clicked.

It's a deceptive line of code like this one:

items = Item.where(status: some_status).all

Look up the item by its status—sure seems good. If you're not careful you'll do like I did and miss the lookup with the critical nil case.

Luckily, the fix for this is really easy. Guard the function and do a quick-return like this if the status is nil:

def run(some_status)
  return if some_status.nil?

  items = Item.where(status: some_status).all

  ...
end

If you're not familiar with Ruby and Rails, that one-liner is just some syntactic sugar for this:

def run(some_status)
  if some_status == nil
    return
  end

  items = Item.where(status: some_status).all

  ...
end

Basically, if some_status is nil just return early from the function and get the heck out of there man.

This is the fix we ended up deploying, and after some server restarts and stopping the mounting queue of background jobs and long-running queries, things eventually returned to normal.

Since it was 2019 we had better backup solutions in place. We loaded up a recent backup and (carefully) made an update statement to revert the data to its previous state.

UpdateGate2019™ was finally over.

What we can learn from this

There's a few key lessons from these stories.

The first is update statements are scary.

Both of my mistakes were update statements. When updating (or deleting) records take extra caution to ensure the records you're going to update are the correct ones.

If you're executing a raw SQL query, be sure to drag "bottom to top" to ensure you run the entire statement. If you're doing an update through code, be extra careful of the parameters and dynamic pieces of your query. Check for nil, NULL, or null depending on your language.

The second important takeaway is if something goes wrong—tell someone immediately.

Hiding or ignoring the problem will only make things worse. The sooner you can surface an issue to your team the sooner you can stop damage from continuing to be done, and it will save you a ton of pain in the long run.

Third: I don't know anyone that was fired from making a mistake.

In both cases my team realized it was an honest mistake.

Afterwards we did a little retrospective to determine how it happened and what we could do to avoid this same mistake in the future.

Mistakes often come from the same root cause: rushing to get work done.

Looming deadlines, tired minds, and not reviewing PRs with enough scrutiny can cause many mistakes to slip through the cracks.

Onward

I'm glad to know I have six more good years in me before I make another terrible mistake (kidding).

I know I'll make another mistake again—mistakes happen.

But, these mistakes didn't destroy my career or fill me with shame. It's just a mistake. I tried to learn from it, and I hope by reading this you will also learn from my mistakes without having to experience them yourself.

If you enjoyed this post, you can follow me on Twitter where I talk about stuff like this—career development and how to succeed as a developer. I also write about these same topics on my site.

Thanks for reading!

John

]]> <![CDATA[ How to Learn Python The Easy Way (And Not the Way I Did) ]]> https://www.freecodecamp.org/news/learn-python-the-easy-way/ 66d45dd59f2bec37e2da0616 Thu, 24 Sep 2020 21:26:19 +0000 By Charlie Custer

Python is supposed to be one of the easiest programming languages to learn. Knowing that made me feel pretty bad the first time I tried and failed to learn it. It was even worse the second time I failed.

But it turns out — and I learned this on the third try — that Python can be really accessible, even to a humanities-loving non-coder like me. You just have to approach it in the right way.

How I failed at learning Python… the first time

The first time I tried to learn Python was almost a decade ago. I wasn’t really sure what I wanted to do with it — maybe automate some of my work, maybe write a little app. It just seemed like a skill that would be good to know.

So I picked up a copy of the then-free Learn Python the Hard Way PDF and started trying to work through it.

The first wall I hit was getting Python set up on my own system. Especially at that time, most of the instructions on how to do that were written for experienced programmers, and it took me forever to slog through it all.

I wanted to learn how to write Python code, and my first step was to spend five hours fighting with the command line? I was demotivated before I even started.

Once I finally got things set up, I could write code along with the book. And I did, for a while, slowing piecing together a very simple text adventure game.

But when I hit the first real challenge — those moments that always come in coding where something doesn’t work and you just can’t figure out why — I quit.

I had more important things to do than pound my head against the keyboard and puzzle through inscrutable error messages. Especially when my end goal was making a text adventure game that I didn’t care about, and that no one would ever play.

How I failed at learning Python… the second time

A few years later, I tried again. By then I was working as a journalist, and I had become interested in data journalism, and web scraping in particular.

I knew that having Python coding skills would be necessary, so I found an online education platform — I won’t say which one — and started a beginning Python course.

Like most MOOCs, this course was video-based. I would watch a lecture about a Python-related topic, answer a quiz on the course site to confirm that I’d learned the material, and then move on to the next module.

Experienced programmers can probably already guess what happened next: when I went to try to write Python code for myself, I couldn’t do a thing.

Watching someone else code in videos and listening to their explanations, I had thought that I was learning how to do it for myself. And the multiple-choice and fill-in-the-blank quizzes I was getting 100% on seemed to confirm I had grasped the material.

But of course, when it came time to apply it on my own, I couldn’t. I could scan back through the videos and copy what the lecturer did, but I had a really hard time applying anything I’d learned to my own projects.

It was also hard to stay motivated, because I was working on things that didn’t seem relevant.

I wanted to learn web scraping. But instead I was struggling to understand video lectures about the concept of object-oriented programming (OOP). What did any of this have to do with my goals? I wasn’t sure, and that made it easy to quit. Again.

Why I failed

In retrospect, it’s not too difficult to figure out why I failed. The first time, my big mistakes were:

  1. Not having a clear goal. Why was I learning Python? I didn’t really know. That makes it really easy to quit when the going gets tough — which it always will, sooner or later.
  2. Too much of a challenge up front. Sooner or later, I’d have to figure out how to get Python onto my system, but setting this up with zero relevant experience, before I’d written as much as a print(‘Hello world!’) was a recipe for frustration and failure.

When you’re learning something challenging, especially as a total beginner, you need early wins to help you believe that you can really do it.

Starting with a frustrating challenge that didn’t even involve coding ensured that I didn’t get those motivating and affirming early wins.

The second time, I avoided those mistakes, but instead I made some new ones:

  1. I wasn’t learning by doing. Watching videos and passing quizzes was making me feel like I could code, but I wasn’t actually coding. When I did try (and fail) to write code, it was even more frustrating because I thought I already understood it. And because I had to do a bunch of clicking around in each video to rewatch different sections and relearn things.
  2. I had a clear goal, but not a clear path towards it. I knew I wanted to do data journalism and web scraping, but I was taking a generic beginning Python course. That meant I was learning lessons that might have been critical for software development but weren’t as relevant to data journalism. I often had a hard time connecting the fundamentals I was learning in class with what I actually wanted to be doing with the code.

Throughout it all, I was also making another big mental mistake. I was thinking about learning Python in very black-and-white terms. Either I had “learned Python” — all of Python — or I had not.

This made the prospect of learning really intimidating. Whenever I hit a challenge, it was made worse by the fact that I was thinking about some mythical Python “finish line” that was still very, very far away.

That’s misguided, of course. Like a spoken language, Python (and other programming languages) are not something you ever really finish learning. And like a spoken language, you don’t actually need to be fluent in Python to get things done.

As any first-year exchange student will tell you, just being able to ask “How much is this?” and “Where’s the bathroom?” in the local language can really affect your quality of life.

The same is true for Python. You don’t need to know everything — or even all that much, necessarily — to make a real difference in your own life.

But that’s a lesson that I only learned by accident.

How I actually learned (some) Python

By 2018, I had given up on learning Python. I had tried twice and failed twice! But then I got hired at Dataquest, a company that teaches data science skills — including Python programming — online.

My new job didn’t require any coding skill, but I figured I still needed to give the learning platform a try. I needed to understand our product, and what our learners felt were experiencing. Maybe, I thought, I could even learn enough to do some web scraping, like I had planned to before.

So, with some trepidation, I created an account and started our Python for Data Science course path.

To my surprise, it felt fun and easy. And to my greater surprise, it didn’t take long at all before I felt like I could build some projects on my own.

I wrote a little script to sort emails. I used Python to quickly analyze some survey data. And, in fits and starts, I built the big web scraping and analysis project I was dreaming of back when I was a journalist.

I was — and still am — actually using Python to facilitate my work, and improve my life. A couple of years later, I’m still a novice coder, but I can hack together little scripts to make things easier and solve data analysis problems I have at work using Python.

This happened because, more by chance than by design, I had stumbled across a way of learning Python that avoided almost all of the mistakes I’d made with my earlier efforts:

  • I came in with a clear goal — learn enough Python to be able to do a little data work so I could better understand our customers.
  • I avoided the up-front challenge of installing Python entirely, because Dataquest lets you learn and write code right in a browser window.
  • I was learning to code by actually coding rather than watching someone else code.
  • I was learning on a path that was designed for Python data work specifically, so everything that I was learning and every exercise I did felt relevant.
  • I was just trying to learn what I needed, not trying to learn all of Python.

How to make learning Python easier

Looking back at my mistakes, and then my accidental success, I think it boils down to a few simple takeaways:

First, go in with a goal. Why do you want to learn Python? What, specifically, do you want to build with it? If you don’t have a good answer for this question, it’s going to be really hard to stay motivated.

Second, find a way to learn by doing the thing you actually want to do. If you can find a targeted learning resource, like a platform that teaches Python specifically for game dev, that’s great. But general learning resources can work too as long as you’re applying what you learn with some beginner Python projects as you study.

Your learning to code has to include actually writing code, and it has to be actually writing code that does something you are interested in.

Third, avoid the up-front challenge of getting Python and its various libraries set up on your local system.

There are plenty of online platforms now that let you write and run code in a web browser, or you can write and run code in a notebook on Google Colab or a similar platform. Just try to make getting started as easy on yourself as possible. You can worry about your local setup later.

Fourth, don’t try to “learn Python.” That’s a massive long-term goal that’s arguably kind of unattainable — even the best Python devs don’t know literally everything about it.

Instead try to learn how to use Python to build a simple version of your goal project, or one part of that project. Then, learn how to use Python to make that project bigger, or how to move on to the next step.

Break big tasks down into smaller chunks, and focus your goals on building something so that you get the psychological reward of having built something when you complete one.

Follow these guidelines regardless of your personal reason for learning Python and I have no doubt you’ll be able to reach your goals without having to fail and quit twice along the way!

]]> <![CDATA[ I spent 3 months applying to jobs after a coding bootcamp. Here’s what I learned. ]]> https://www.freecodecamp.org/news/5-key-learnings-from-the-post-bootcamp-job-search-9a07468d2331/ 66c34178a1d481faeda49ac4 Fri, 29 May 2020 15:48:00 +0000 By Felix Feng

A less-talked about part of the bootcamper’s journey is what happens after you graduate — when you’re searching for that six-figure developer position.

Image < 3% of applications became offers

I completed Hack Reactor in July 2016 and took almost 3 months before accepting an offer with Radius Intelligence. I applied to 291 companies, did 32 phone screens, 16 technical screens, 13 coding challenges, 11 on-sites, and received 8 offers. The offers ranged from $60-125k in salary from companies all over the US, and for both front end and full stack roles. In total, 2.8% of applications became offers.

Here are 5 things I wish I’d known before I began my job search.

Insight #1: Get through to real people

At first, I applied for companies using the shotgun approach. I applied through Indeed.com, AngelList, LinkedIn, StackOverflow, Hacker News, company websites, and even Craigslist.

I’d submit a resume for any role that wanted React, Node, or JavaScript experience. In the first week, I applied to 15–20 companies a day.

Pro-Tip: Find companies using this easy-application repo.

My yield was low. Less than five percent of companies responded to me. I was throwing applications into a black hole.

Everything changed when one of my cohort-mates, a former recruiter, shared a guide to the job search. He told us to send emails directly to real people with each application. It could be anybody. As long as someone read it.

From then on, whenever I submitted an application, I searched for the company on LinkedIn and emailed someone on their engineering or hiring team.

For most small companies or C-level executives, the email format is usually firstName@dreamCompany.com. For larger companies, it may be firstName.lastName@dreamCompany.com.

To verify emails, I used Rapportive to cross-check emails with social media accounts.

The results were amazing. With 150+ emails sent, my response rate was a whopping 22%.

It also felt great to hear from real people. Surprisingly, CEOs and CTOs responded to me. Sometimes they even interviewed me themselves.

Takeaway: If you’re applying through the front door, make sure you’re getting to human beings.

Insight #2: Start small and work your way up

You will face Level 1 interviews (a non-tech company that needs any dev), where interviewers ask you nothing more than JavaScript trivia.

You will face Level 9 interviews (Google/Facebook level), where interviewers ask difficult data structure and algorithm questions.

I strategically set up my process so that I had lower-level interviews earlier, and higher-level interviews later on.

Early on, I gained experience, built confidence, and secured offers from companies that had less intensive interviews.

As I got more experience, I effectively “leveled up.” I became capable of completing interviews at companies with higher hiring bars. This is illustrated below as a linear correlation between the number of weeks I was into the process and the base salary I was offered.

Image There’s a direct correlation between time spent interviewing and offer salary.

I unlocked tougher questions. I unlocked higher salaries. And eventually, I unlocked the job I took.

Takeaway: Plan to tackle easier interviews early on and more difficult ones later on.

Insight #3: Study like your future job depends on it (because it does)

I hate to break it to you, but the most important thing you could be doing at any point is studying and preparing.

Why? Because you won’t get the offer if you don’t have good answers to the questions they ask you.

People won’t refer you if they don’t think you’re prepared for their interviews.

Coming out of Hack Reactor, my weaknesses were data structures and algorithms. A study by Triplebyte has found that bootcamp grads are weaker in these areas than computer science grads.

So I learned and practiced. Every day.

I devoted entire days to learning sorting algorithms. Other days, I focused on understanding how the internet worked.

If I didn’t fully understand a concept, I’d spend the day watching YouTube videos or searching StackOverflow until I did.

I found the following study materials useful:

  • InterviewCake: My favorite resource for data structures and algorithms. It breaks down solutions into step-by-step chunks — a great alternative to Cracking the Code Interview (CTCI). My only gripe is that they don’t have more problems!
  • HiredInTech’s System Design Section: A great guide for system design interview questions.
  • Coderust: If you’re avoiding CTCI like the plague, Coderust 2.0 may be perfect for you. For $49, you get solutions in almost any programming language, with interactive diagrams.
  • Reddit’s How to Prepare for Tech Interviews: I constantly used this as a benchmark for how prepared I was.
  • Front End Interview Questions: An exhaustive list of front-end questions.
  • Leetcode: The go-to resource for algorithm and data structure questions. You can filter by company, so for example, you could get all the questions that Uber or Google typically ask.

Takeaway: There’s no such thing as too much preparation.

Insight #4: Put your best foot forward

Breaking into the industry is hard. You have to perform well, even when you’re not fully prepared. In order to succeed, you have to be your own advocate.

Sell Yourself

At Hack Reactor, we’re trained to mask our inexperience. In our personal narratives, we purposely omit our bootcamp education.

Why? Otherwise, companies automatically categorize us into junior developer roles or tag us as “not enough experience.”

In one interview with a startup, the interview immediately went south once they realized I’d done a bootcamp. One company used it against me and made me a $60k offer, benchmarking against junior developers.

Ultimately, you need to convince companies that you can do the job.

At the same time, you need to convince yourself that you can do the job.

You can. Focus on your love for programming. Focus on what you’ve built with React and Node. Focus on demonstrating your deep knowledge in JavaScript and any other languages you’ve learned.

Only then can they justify giving you the job.

It’s a Two-way Conversation

Interviewing is a mutual exploration of fit between an employee and an employer. While it’s your job to convince employers to hire you, it’s also their job to win you over.

Don’t be ashamed of using the interview as an opportunity to evaluate the job opportunity.

I talked to any company, even if I had only the slightest interest.

I did on-sites all over the country with any company that invited me out. I asked questions, and sucked up knowledge on engineering team organization, technologies and tools used, company challenges, and system architecture.

Pro-Tip: During interviews, ask the following questions:

What are some technical challenges you’ve recently faced?

What do you enjoy about working at X company?

How are teams structured and how are tasks usually divided?

I treated every interaction as a learning opportunity. Each interaction helped me improve my presentation, interview, and technical skills. Each failure helped me find my blind spots.

Takeaway: Don’t sell yourself short! And remember, it’s a mutual exploration.

Insight #5: It’s a marathon, not a sprint

The journey is by no means easy. For 3 months, I grinded 6 days a week. But I tried to take care of myself.

Image What a typical day could look like in JavaScript

Some days, I’d study with friends. Other days, I’d go find a cafe and study alone, or hang out at Hack Reactor’s alumni lounge. And every week I’d check in with our career counselor to talk about my progress.

It’s easy to burn out during the process. Eat well, sleep, and exercise.

It can get lonely. Spend time with friends who are going through the same experience.

Takeaway: Prepare for the long game and make sure you take care of yourself.

In summary, the key takeaways are:

  1. Get through to real people
  2. Start small and work your way up
  3. Study like your future job depends on it
  4. Put your best foot forward
  5. It’s a marathon, not a sprint

The process may seem endless, but you’re going to make it. Keep putting in the hours. Keep sending in the applications. Keep taking caring of yourself. All of it pays off in the end.

A special thanks to Dylan Tran, Karen Zhao, Rohit 'Sunny' Rekhi, Jake Pace, Anamita Guha, Stephanie Liu, and many others.

Please share this with friends going through the job search.

]]> <![CDATA[ Lessons Learned from My Journey as a Self-Taught Developer ]]> https://www.freecodecamp.org/news/lessons-learned-from-my-journey-as-a-self-taught-developer/ 66d46175b3016bf139028d9e Thu, 28 May 2020 11:30:28 +0000 By Victor Cassone

The path of the self-taught developer is tough and filled with uncertainty. There is no straight line from newbie to career programmer. Because of this, I believe all self-taught developers have a unique story to tell.

In this article, I’ll share my coding journey through a series of lessons I learned along the way. Hopefully reading about my experience teaching myself how to code will help you reflect on your own past, and motivate you to keep moving forward.

Lesson #1: Focus on the Process

When I first started learning to program, I never had the intention of making a career out of it. I just wanted to make a specific app.

My journey started when I was a senior in college. I just finished Richard Branson’s biography and I was probably reading too much TechCrunch. I was pumped full of entrepreneurial energy.

I was constantly reading about how college kids were receiving massive amounts of investment for their mobile app ideas. I thought I could be one of those college kids.

One day, while walking in between classes, an app idea hit me. I quickly became convinced that I’d found the next big thing.

I was consumed by the idea and stopped paying attention to lectures. My excitement for the app idea quickly grew to the point where I felt I needed to take action.

There was one big problem. My idea was a mobile app and I didn’t know anyone who could build mobile apps.

So I thought, "what the hell, how hard could programming be?" I was losing interest in my major and I was spending a lot of time playing Xbox. I could put some of my free time towards building out my mobile app idea.

Sometimes being naive helps you take action when you normally wouldn’t.

I was a college student with no programming, business, or design experience trying to learn Android so I could build a complex mobile app. I guess that’s what you get when you mix a big idea with the Silicon Valley hype machine.

I wish I could tell you things went well from here.

I bought a few books on Android development and spent countless hours in my room trying to duct-tape my app together. I didn’t care how the app worked, I just wanted a finished product.

Time went on and the app turned into a Frankenstein of copy and pasted code. The app didn’t have many features and it barely ran without crashing.

It wasn’t until I accidentally got into a Computer Science class that I realized that I should focus more on actually trying to learn software development.

My inability to program lead me to abandon my initial app idea. I'd come to the realization that I wasn’t going to make the next big thing, at least not yet.

Over time I corrected my behavior and took learning more seriously. I started to enjoy programming and eventually started a career as a software developer.

My big app idea consumed me for a long time. It put my focus on the end result rather than the process of getting there.

When you get too focused on the end result, you start taking shortcuts. Shortcuts might lead some short-term progress but in the long run, your lack of knowledge will always catch up to you.

It’s important to remember that learning anything big, like programming, requires many small steps. Each step will need to be treated with care.

Learning new things is like building a house. You start with the foundation and build up. If the foundation is faulty the whole thing will crumble down sooner or later.

Sometimes building a strong foundation requires you to slow down. There’s no shame in going slow. The people who understand the basics the first time will end up getting ahead of the people who have to go back and relearn them.

There’s an old Chinese proverb that goes:

"It is better to take many small steps in the right direction than to make a big leap forward only to stumble backward."

It's not how fast you can do something, it's how slowly you can do it correctly.

I was a perfect example. From the outside, it might’ve looked like I was a programming whiz kid. In reality, I couldn’t build an app to save my life.

Focus on the process and you will surprise yourself with how much progress you make each day.

Lesson #2: Stack Overflow is Awesome (But Dangerous)

As I was building my killer app, Stack Overflow became my best friend.

Anytime I got stuck I would try to craft together a perfect question to ask the Stack Overflow community. I averaged a few questions a day.

Not only would I post questions, but I would also treat the answers on Stack Overflow as Gospel. I would spend a crazy amount of time scouring the site to try to find an exact chunk of code that would fix my problem.

When I found a suitable answer, I would copy and paste it right into my codebase and try to make it work with my existing code. I spent little time trying to understand the code I was adding.

I made brute-force trial and error a new art form.

This process went on for a while until eventually, I wised up and realized the flaws of my approach.

Stack Overflow is a blessing and a curse. It’s great at helping you solve problems – however, if you aren’t careful, you can quickly become dependent on the website.

Sometimes the website is too good at solving problems. It creates a false sense of confidence that can lead to more headaches down the road.

Stack Overflow shows you how to get something to work but it doesn't usually explicitly tell you why it works.

Understanding the how is important. Bugs need to be fixed and code needs to run.

However, understanding why something works is what's going to help you apply the knowledge again in the future.

It's like the quote...

"Give a man a fish, and you feed him for a day. Teach a man to fish, and you feed him for a lifetime."

Copy and pasting code from Stack Overflow is like giving someone a fish. Understanding why a snippet of code works is like teaching them to fish.

There's nothing wrong with copying and pasting code. We all do it. It's only a problem when it becomes a crutch and stunts our growth as a developer.

The thing I had to learn the hard way was that it's impossible to learn anything if the answers are constantly given to you. There are no short-cuts in the learning process.

When you're stuck, attempt to solve your coding problem at least a few times before going to Google.

When you find yourself copying and pasting code, spend a little time trying to understand the code snippet before moving on.

Lesson #3: Learn How to Find Experienced Help

The first thing I did after I decided I wanted to learn programming was buy two Android development books.

At the start, I followed the exercises in the books closely and worked through the example projects. However, I quickly got frustrated with the progress I was making following the book and decided to go off and figure out how to program on my own.

As you’ve read above, that slowly resulted in disaster.

I spent countless hours isolated in my room trying to figure out simple programming problems. I was getting stuck on every new line of code and it didn't feel like I was making much progress.

I was helplessly stuck and my life was a cocktail of doubt, frustration, and an overwhelming feeling of being lost.

To make matters worse, I had the bright idea to start using a massive C library called FFMPEG. My app needed to edit videos, so I thought it was a good idea to utilize the library’s robust functionality.

It wasn’t my smartest move, considering at the time, I could barely get my Android app working.

I wasted a lot of time trying to read the C code and figuring out how I could use it in my app. I struggled to even get the library imported into my Android project. The Android code and C code didn't want to play nice.

After many hours of getting nowhere, I eventually became frustrated and abandoned the library.

Around the same time as the FFMPEG debacle, I signed up for an Object Oriented Programming class. I'm honestly not sure how I got in. I later found out that I was the only non-Computer Science major in the class. I think there was a bug in the enrollment software.

The first assignment was to build a Blackjack program. I’d been teaching myself programming for 5-6 months at this point, and I felt somewhat confident with my skills.

I finished the assignment and felt good about my work.

It didn't take long for that feeling to fade.

My whole program was written in one huge method. Just about everyone else in the class was able to pick up on the fact that the program needed to be separated into classes.

Not good.

Luckily, the classwork and guidance from the teacher allowed me to take a step back from my Android app and reflect on my programming abilities. I started to value learning and reigned back my desires to make a completed app.

I've now come to realize that if I would've spoken to just one experienced developer in those early days, they would’ve seen what I was doing. I could have set my priorities straight, and talked some sense into me. They would’ve helped me correct my path when I was going down useless dead ends (like trying to work with FFMPEG).

Instead, I isolated myself from the world partially because I felt like there wasn’t anyone who could help me.

Isolation is a double-edged sword. On one side, it helps you focus on the task at hand. On the flip side, it removes you from the world, starving you of crucial feedback.

There were a lot of ways I could’ve found help. I could’ve tried to find a professor/student at the university with Android experience or looked to the local community for help. I also could’ve tried finding an online Android community.

Experienced developers are like a compass. They won’t get you to your destination but they will make sure you are pointed in the right direction. Their help can often be the difference between success and failure.

Make sure you seek out guidance wherever you can find it. It will save you time and frustration down the road.

Lesson #4: Craft Your Environment

This might be the only thing I felt like I did right when I was teaching myself programming.

Throughout my life, I’ve been really bad at studying for tests or doing my homework at home. There are just too many distractions at any given moment. I would often try to find refuge in libraries or coffee shops.

Luckily I applied this rule when I was teaching myself programming.

I ended up becoming a regular at a few local coffee shops. I preferred coffee shops over other study locations because they provided some variety and it’s easy to hide (easy access to caffeine doesn’t hurt either).

If I was studying at home, I made sure my door was shut and my roommates knew not to disturb me for a certain period of time.

Regardless of where I was, I would make sure my music was loud enough so I couldn’t hear what was going on around me.

I can’t say I was perfect at finding a distraction-free work environment but I was able to succeed a majority of the time.

Having the right work environment is often an overlooked part of learning.

Focus is a foundational component of memory and skill acquisition. When you try to learn something new, the strength of the learning is directly linked to the intensity of your focus. When your focus is weak, new information will be less sticky which will result in slower learning and more time studying.

Your work environment should be distraction-free and should allow for long uninterrupted stretches of focus. Even with COVID-19 making it necessary to work remotely, there are still actions you can take to design your learning environment.

Here are a few things you can do:

  • Find a location where people won’t interrupt you
  • Put your phone in airplane mode
  • Use some sort of timed website blocker for social media and news sites
  • Wear headphones and listen to non-distracting music (preferably a long playlist so you don’t have to constantly switch songs)
  • Avoid TV or other highly stimulating surroundings
  • Have a notebook nearby to write down any tasks or ideas that pop into your head
  • Make it known to the people around you that you don't want to be disturbed

Only you can decide where and how to craft your environment. But make sure you do, because it’s worth it.

Lesson #5: Get Out Into the World and Meet People

Landing my first programming job was sort of a random occurrence.

I just moved to Omaha, Nebraska and I had around a year of self-taught development under my belt.

I knew very few people in Omaha, so I searched Meetup.com to try and find other people interested in Android development. I found a Meetup focused on mobile development which covered both iOS and Android development and I decided to go.

Going to that first meeting was nerve-racking. I spent around 10 minutes in my car at the venue deciding if I should go in or drive off.

I was intimidated. I wasn’t confident of my programming skills and I knew everyone at the Meetup had much more experience than I did.

I finally said, screw it and went inside.

I’m glad I did.

I started to attend regularly and during one Meetup, not too long after I moved to Omaha, I met a recruiter who was looking for an Android contractor. We talked for a while and I got an interview for the job later that week.

Before the interview, I felt confident. During the interview, I was a deer in the headlights.

The interviewer was talking about the project I’d be working on and it all went right over my head. I tried to stay engaged but they could tell it was out of my range.

After the interview, they asked me to hang-out for an hour so I could talk to someone else. Knowing I blew it, I walked around downtown trying to clear my head.

I ended up interviewing with someone else at the company, and shortly after, they offered me an internship.

I was so shocked that after I signed all the paperwork and got my work laptop running, I went over to the CEO and asked if it was a paid internship or not.

The internship turned into a full-time job and I started my career as a software developer.

When you are self-taught, people are not going to come and seek you out. You will need to find opportunities for yourself.

Graduates of four-year universities and code schools have the advantage of leveraging their school's network when finding a job. Self-taught developers don’t have this luxury.

Self-taught developers will need to go out into the world and build their networks themselves.

Cold calling employers and sending out resumes can work. However, I've found people like hiring people who are close to them in their social network.

Websites like Meetup.com are great for finding monthly programming-specific groups. Even in a pandemic, there are still many virtual Meetups that are very informative and beneficial.

There are also other Slack channels or Discord communities that you can leverage to make meaningful relationships. You can also try reaching out to various people in your area and ask to have a quick 15-minute virtual coffee with them.

Do what you can to build up the nerve to reach out and talk with people. Be friendly and talk to them about your experiences. Make sure people know of your long-term goal of finding a job.

Put yourself in situations where something positive might happen. You can’t win a raffle if you never buy a ticket.

Consider any opportunity that comes your way, because even if it looks like a dead-end, it has the potential to lead to something bigger.

My internship was a huge pay-cut to the other offers I had at the time. However, I knew if I worked hard it would be an opportunity for me to break into the tech industry.

The key is to think of job opportunities in the long-term. Internships or part-time jobs might not give you your desired salary upfront but they might open up doors in the future.

I Hope You Learn From My Mistakes and Make Exciting New Mistakes of Your Own

As you can see, I made a lot of mistakes in my journey of becoming a self-taught developer.

Teaching yourself to code is never a straight road. All our stories are unique.

The key is to keep going and to avoid getting discouraged when things aren't going your way.

I encourage other self-taught developers to share their stories. Not only will they provide valuable insights, but they will also help shine a light on the unique paths we’ve taken.

Hopefully, my story and the lessons I learned will help you moving forward.

Thanks for reading. If you want to hear about other insights I've learned along the way, follow my account Zero to Programmer on Twitter. My goal is to help you learn programming more efficiently.

]]>