DEV Community: Miranda

3 Reasons You're in Tech Post-Layoff Shock (Based on personal experience)

Miranda — Sun, 21 Sep 2025 04:50:50 +0000

This blog post was originally posted on BooksOnCode

You're in post-layoff shock. Either you have just been laid off from your tech job, have a colleague or friend, or you are reeling from the online news. I hope this article serves as comfort for you as you process this feeling as it is the feeling I've just processed over the past couple months.

I put "based on personal experience" in the title. Why? We are going through human struggles right now: human hurt, shock, and suffering. I am often on my search browser looking for catharsis. No wonder the top result is often Reddit and not the plethora of AI-generated blog posts dominating our browser.

A little aside: blogging has made me jaded over the recent years. A meeting with a blogging coach said I needed to get on the AI-generated-content game if I were to survive this current landscape. Blogging, like tech, has been hit with a wave of turbulence. But with the encouragement of my email list, I know that authentic content is here to stay. Hence, this blog post is worth writing. I hope you read it to the end.

So here's the story: I was laid off from my big tech job.

Though I was in constant survivor's guilt after each round of tech layoffs and in anticipation of the moment, nothing could prepare me for the shock drop.

In this article, I'll highlight my personal experiences as well as share insider information on how we ended up where we are today. Plus, I'll go over where to go from here from a practical (and not 'rah-rah' cheerleader) standpoint -- all from someone who is living through it right now.

3 reasons you're in tech post-layoff shock:

1. You're suddenly financially or emotionally vulnerable after a major life event

It seems like a coincidence. You were laid off amidst a major life event. One of these events may have happened right before or right after your layoff:

You just got married and added a spouse to your health insurance plan.
You just had a traumatic separation with a spouse or loved one.
You just closed on a house and took on a hefty mortgage.
You just moved to another country and rely on employer sponsorship.
You just found out you are having a baby.
You just experienced the death of a loved one or had a major health crisis.

I’ve heard a staggering number of stories like this – to the point that it seems like the rule rather than the exception. Serendipitously, a layoff coincides with one or multiple major life events.

Why does this phenomenon happen?

Logic dictates that life is always changing. People are always getting sick, dying, being born, breaking up, getting together, moving, and making major purchases. But a layoff highlights these things, amplifying major events by a lot. A layoff is a huge blow to your identity, self-esteem, and your sense of security as well as your actual security.

The odds of one or more of these major events happening around a layoff is high – especially when tech jobs are lucrative and give you the means to feel secure enough to take big leaps. At prime working age in the tech industry, many of us have an aging family and are making major moves.

I am no exception to the rule. The shock to my system was great – still fresh, personal, and ongoing. The feedback I get from friends, family, and strangers are a cacophony of the same series of phrases:

Perhaps this layoff was a blessing in disguise
This is a great opportunity to take time to soul-search and discover yourself
You are so great; I’m completely confident you’ll get through this just fine
And the best response: let me know if you need an ear or need any help

I’ve been resisting most of what people are saying. I’m surprised by how many well-meaning and dear people have encouraged me to take time for myself, to breathe, and to discover myself.

I’ve had a series of irritated responses snap back in my head:

If I was employed and looking for another job, nobody would be telling me to pause.
I know my own financial situation best.
I journal and reflect every day; how does a layoff correlate with the need to know myself?
Even if I am ‘so great,’ so are all of my peers who were laid off who have not yet found work. I also have to try hard and know that I’m not guaranteed a good position anytime soon.

I’m not the only one who has had a flare-up of irritability. After getting laid off, I subscribed to LinkedIn Premium and set out to optimize my profile. Being on LinkedIn more, my feed is proliferated with pessimism about the tech job market: tech peers analyzing rejection emails, complaining about interview experiences, and airing frustrations about something someone said (like I just did). Instead of trying to engage with my feed, which is good for my profile’s SEO, I decided to just ignore it.

I heard “blessing in disguise” often over these past couple months and I understand the sentiment. Though I try to take it well, resentment redoubles in my chest. Even if a layoff in the medium-to-long term ends up working well for me – if I re-evaluate my career and make brave choices – the sentiment still grits against the current reality:

I am robbed from making a choice.

Even if we were unhappy at our jobs – even if we instead thought about caring for our parent with rapidly-progressing dementia or being with our young children who are growing up too fast or going all-in on our creative passion project – we are still rejected, shamed, and panicked about getting laid off. It doesn’t feel like a blessing.

The emotions that come during a layoff are well described by Steve Jaffe in his Amazon book, The Layoff Journey (2025):

My body's immediate reaction was, well, shock. How could this happen? Why me? Surely, there must be some mistake! Soon to follow was shortness of breath, elevated heart rate, and a dry mouth. [...] Suddenly, my future had become a giant black hole absorbing and casting doubt on everything in it.

This is a feeling not to be taken with lightheartedness and cheer. If you have a friend who recently experienced a layoff, be soft, be patient, and let your friend feel. If you are the person laid off, it’s important to grieve and to allow emotions to come and go without suppression. It’s the only path to healing.

2. The tech industry was stable for 20 years

Jobs in the tech industry have had great PR throughout the 2010s and early 2020s. Far more Computer Science students were graduating. Coding Bootcamps were pumping out students finding lucrative jobs. I, too, was hired during a big hiring boom in 2021. I was onboarded alongside a staggering 2,000 other software engineers who were hired that year – at one company.

The industry was booming until it suddenly wasn’t. Starting in 2022, nearly 100k tech employees were laid off – a trend that has only continued year after year.

A reason for the shock: "[T]he tech industry has been thought of as layoff-proof for the past 20 years," said Samuel So, a doctoral student in human centered design and engineering who conducted surveys on the “cruel optimism” of those who experienced tech layoffs.

I was unaware of this optimism. But in 2022, an intern on my team entered our usual one-on-one meeting in distress. Our company had just announced they were rescinding all intern offers soon before the start dates. These were current college students who had already accepted their offers, denied others, and made plans. Not only that, but interns who were previously indicated that they were going to be hired post-internship were no longer receiving offers.

“This is not why I went into tech!” said the intern on my team. I could feel her panic radiating.

“What do you mean?” I said. “The tech industry is turbulent. You don’t get into tech for job security.”

“I didn’t know that,” cried the intern. “I thought it was safe.”

That brief exchange sent me into a tailspin. How did she not know?, I thought. But I was just coming to understand the truth: recent Computer Science graduates didn’t know. I thought the tech industry was unsafe, but a wave of graduates were going into tech because of its safety.

Jeane Twenge’s book on Gen Z, iGen, highlights that Gen Z is a far more practical and pragmatic generation than their Millennial neighbors. Millennials, who were taught to dream big, were more likely to choose careers based on passion. Gen Z, who saw ‘passion’ catastrophically fail during the Great Recession, decided to prioritize safety and jobs that pay.

So somehow, tech had become safe – and Gen Z were gravitating toward it.

But pursuing Silicon Valley is like pursuing gold during the Gold Rush: it has great rewards and risks.

The message I gathered was more of a typical Millennial – one of passion: do it not for the money, but because it’s interesting.

Whether we’re there for stability or risk, we have ended up in the same industry during a trying time. But perhaps one group is more in shock than the other.

A lot of us will leave the industry. But many of us will stay, too, and reinvent ourselves to meet the new demands, which seems to look like AI and higher-level architectural thinking. There is also a lot to be pessimistic about with the ever-shrinking opportunities for juniors, seemingly to leave only senior-level positions before the role likely evolves into something else entirely.

It’s a shocking and scary time full of unknowns, completely validating the great shock we now find ourselves in. Despite aiming for stability, it seems there is no stability anywhere.

3. You have no Option B (and can't conceive of one)

Nothing feels safe and everything seems to be affected by AI. It comes after the marketing copywriters, technical writers, designers, artists, and filmmakers. Anything that involves typing on a keyboard, music, or art.

I find the optimists of AI infuriating – not that I’m shirking all of AI’s benefits. It’s just – some of us, especially when we are unemployed, sometimes just want jobs. AI is a boon for the entrepreneur but induces sweat for anyone thinking about putting food on the table.

Designing Your Work Life uses the concept of “good enough for now” for prototyping into a more ideal work life. If we find ourselves not in our ideal work situation, such as unemployment, the next career move may not check all of your boxes.

The book dictates that step one is to accept your situation. And, given your situation, define small moves you can make that would make your situation sustainable in the near term – something good enough for now.

And here’s the thing: that midway step feels yanked away, too. Prior, when I was in between jobs, I used to take on temp work in web development. This work was plentiful and I had no problem securing a small contract in little time. Today, these temp jobs are also saturated with competition and are often open to overseas contracts.

I am finding myself lacking creativity, looking in similar directions to everyone else.

But the reality is still here: extremely seasoned, talented senior developers – thousands of them – are competing for roles where not enough exist. Many of us are not going to squeeze our way in. At least, not now.

So then, what is good enough for now?

Teaching has come up a number of times. I was in a coffee shop, overhearing a well-meaning friend suggest teaching to his laid-off software engineer buddy. Perhaps the local college has a spot? Again, if everyone is thinking of it, the competition still lives there.

The happiest among the laid off, who have not found jobs, have left tech to do something completely different like start a pottery studio. The level of big thinking required, in a state of fear for security, is an incredibly challenging position to be in, especially when our mothers or spouses were so happy for our tech job just a moment ago and may not have accepted our situation.

If we keep thinking that we can rewind time, going back to where we just were, we won’t see other opportunities.

What Now?

This is a turbulent time for many of us. Where I am, in California, we have the highest unemployment rate of any other state – with over a million unemployed.

I see this moment as a calling to practice resilience and to give oneself small graces.

I’ve seen online that the job search is “hell on earth” – announcements from individual tech workers losing their houses and moving into their cars. It’s a scary time and not one where a pep talk is appreciated.

But regardless, we cannot let outside forces control and ruin us. We have to shape and design our own destiny.

During this time, I picked up Designing Your Life again, which has been the best tool for shining light on my situation, allowing me to both accept it, reframe it, and iterate on it. Doing productive writing exercises helps me get a clear head, try new things, and gain some motivation.

And with the wisdom of Atomic Habits, I recommend coding regularly so that you maintain your identity. Going a week or two without touching a line of code begins to sink into your self consciousness, making you feel like a fraud, impacting your interviewing ability. Step-by-step hands-on coding courses like Codecademy gamify this small daily habit.

As scared as I am, I am not going anywhere. Please, comment on this post with your story and let's elevate each other.

72 Free Ways to Learn to Code (Ultimate Guide)

Miranda — Sat, 15 Aug 2020 20:55:07 +0000

This article was originally published at Books on Code

The days of the Computer Science degree as the end-all, be-all is over.

And guess what? An alternate route --- the online route --- is totally valid. Learning to code for free online is not only possible but preferred.

Free resources are so good that they are often even used in paid bootcamps.

Today, there is an abundance of quality, free learning resources. As long as you can prove that you have the programming skills and knowledge around algorithms, you can get hired as a programmer. If you have a will to learn to code for free, you can certainly do it.

With the pandemic, we're likely going to see a huge wave of people taking an alternative route to education. And I say --- embrace it!

We can be anything and do anything without spending any money. Today, anybody can take on the task of learning code for free. The journey is adventurous and the process is rewarding.

The finest part is that you can find the best way to learn to code without paying a penny. I know this sounds too good to be true. Because of the sheer abundance of free resources, gathering the best ones can be challenging.

But don't worry. I am here to help you out.

The internet is flooded with articles that claim to find you the best way to learn to code. However, none of these will actually help you choose the right curriculum.

This ultimate guide is designed to be more than just a massive, quality list of free resources: we're going to be talking about types of resources, how they can remain free, and even the dangers to some free resources.

In this guide, you will learn how to find the best way to learn to code. Since we are in this together, I will also help you in choosing the best resources. I hope that this ultimate guide enables you to live your coding dream to the fullest.

I also hope this helps you choose the right curriculum on your journey of learning to code for free.

Types of Free Coding Resources

Books are among the best learning resources for free (at Books on Code, we have no bias), but there are also other great free ways to learn to code.

Books are among the best learning resource for free (at Books on Code, we have no bias), but there are also other great free ways to learn to code.

While learning code for free, you can use a variety of resources for free: online courses, books, video lectures, and interactive tutorials.

I also encourage using different types of learning materials to drive the same lessons. For example, pair a book with a course or a video tutorial with an interactive tutorial.

What type of learner are you? My bet: you are someone who needs variety --- both hands-on, practical instruction and theory-based study.

The following sections describe each type of learning resource.

Books 📚

Of course books come first, as this site is called Books on Code and we have a bias! Why do we love books as a learning resource for coding? With a book, you can slow down and embark on truly deep learning.

When learning with books, consuming conceptual information is best. Taking notes by hand is a powerful way to etch ideas into your mind.

I personally love books for this reason. I can have a hard time with video lectures when they breeze by an important concept. I think, "That makes sense," only for the information to be gone forever.

With video lectures, I feel a level of shame pausing the video and replaying the same point over and over to capture every nuance of a quickly-drawn diagram and explanation. I love taking notes by hand, and sometimes video lectures are not great for that format.

With books, I comfortably spend as much time as I want contemplating a diagram or how each piece of code works.

Books are as slow or as fast as you want them to be. That's why I love them.

Blogs ✍

Blogs. They're obviously 'free', but they should not be overlooked as a way of learning code for free. In the coding community, many of us are also tech bloggers (myself included).

When programmers encounter a problem in their code, they often feel its their duty to chronicle their problem and how they solved it.

Blogging is a part of dev culture. It's our way of life. 🙂

The best blog posts are often gathered in round-up email newsletters, with my favorite being Frontend Focus. Many tech bloggers solve specific problems that you will likely only encounter during a Google search when trying to solve a problem.

Blogs are great reading when you are actively working on a project.

Blogs are also great learning when you yourself are actively writing your own blog. A great way to learn is to teach others. Starting your own blog, or contributing to the DEV community, is a great way to trace over the problems that you solved so that you can remember your solution forever.

To browse blogs, I recommend joining tech blogging communities like the DEV community. Their email list shares the weekly Top-7. By the way, my article, 7 Effective Steps to Cracking the Code Interview made the Top-7. That's my humble brag for the day.

Video Courses 💻

If you're a visual learner, you may find huge value in video courses.

What I love about video courses is just how consumable video content is. I personally cannot binge enough YouTube videos. When I was learning merge sort, I watched every explanation I could get my hands on. I wasn't getting it. Until I finally did.

I absolutely love video courses: both tutorials and conceptual information. However, the biggest negative for me is retention. I do not retain information as well from a video lecture as I do from a tutorial, a blog, or a book. Why? It's all about the effort you put into retention --- and with videos, it's just too easy to be passive.

Nevertheless, video courses are among the most popular forms to learn code. Companies that offer this service tend to be video only, with no graded assignments. These courses take the form of lectures with slides and may walk through a tutorial, encouraging you to follow along on your own.

Popular platforms that offer video courses are Udemy, Scrimba, Pluralsight, and Frontend Masters. You can find great tutorial videos on YouTube as well (which are free!).

Interactive Tutorials ⌨

Another top coding resource in learning how to code for free is interactive coding courses. These courses have actual deliverables, quizzes, and real coding assignments that are either peer reviewed or checked by a computer. These are sometimes paired with videos, but not always.

Codeacademy and freeCodeCamp come to mind as resources that rely primarily on interactive tutorials. While other resources, like Coursera's Fundamentals of Computing Specialization, is a combination of video lectures and machine-graded assignments that take several hours, similar to a university computer science course.

Great interactive tutorials are rarer than other resources, because interactive tutorials are just more expensive to produce. Everything else is consumed passively, but interactive tutorials themselves requires thoroughly thought out assignments as well as a computational way to grade.

I absolutely love what freeCodeCamp has to offer. It is one of my absolute favorite ways to learn to code for free. But there is a downside to interactive tutorials: you can code to 'win the game' instead of code to learn. Instead of actually analyzing what I am doing, I try some stuff, solve the problem, and then don't think about it again.

That's not how it should go. Even the founder of freeCodeCamp emphasizes that all learning is about repeated exposure.

Because interactive tutorials are gamified, they can give the illusion of learning while you are not actually learning.

Why So Many Quality Resources are Free

Now, you might be wonder: if there is an abundance of quality resources that rival paid material, why are they free at all?

Why Books Are Free 📚

Like with blogs, books are free for many of the same reasons that other products are free. The more generous authors are, the more likely these books are to end up in people's hands, and the more it generates buzz.

Programmers who are sick of seeing the same mistakes made over and over sometimes just want their wisdom out there.

However, many books that are free still manage to make money.

Many free books charge for a print copy or have a suggested contribution, but do not require the contribution. Asking for payment, without requiring payment, can often work in the author's favor. If readers appreciate the value the book gives, they are still likely to pay even if they can get it for free.

This concept is called reciprocity: when people receive great value, they want to return the favor.

Some books, like Eloquent Javascript, has a bonus model: the entire book is free, but if you pay for a print copy, you get a bonus chapter or other bonus materials.

Why Blogs are Free ✍

Alright. I'm sure this sounds silly. Of course blogs are free. It's kind of obvious.

But hear me out: many of the awesome resources we have for free online are so good that someone would pay for them. These resources include Interneting is Hard, the Front-End Developer Handbook, or the Complete Guide to Flexbox --- things that are just gold.

One reason for this: amazing resources offer digital marketing and brand exposure.

Tools like the Front-End Developer Handbook is sponsored by the video learning platform, Front-End Masters. While the handbook provides immense value, the guide advertises their own courses throughout.

Individual bloggers, like Sam Gavis-Hughson's blog on Byte by Byte, offers concise and valuable blogs and freebies on recursion and discrete math concepts. As many blogs do, the freebies lead to an email list, which promotes the business, which in this case is premium consulting and interviewing courses.

Many bloggers want to grow something --- whether that be their name or their business --- and a great way to do that is simply by giving people value. When you give value, people will respond. That response can be powerful.

This is why many programmers use blogging to promote their personal brand. With a blog, they become a standout developer, gaining an advantage in interviews, boosting them throughout their programming career.

Despite these reasons, I do believe programmers blog also just to help others. You do not need to have another motive to be a tech blogger. A well-known tech blogger, Tania Rascia, says in her website philosophy: no ads, no affiliate links, and not even Google Analytics tracking. Reluctantly, she added a donate button, saying the following:

For the first few years, I didn't have any donate button at all because I thought it seemed weird, spammy, and needy to have one, but I realized when you do something cool, people want to show their appreciation.

Bloggers are people, and people have different philosophies about money and conduct their blog in different ways. May of them offer paid ebooks and courses, but not always. Often, they are just generous.

Programmers see a need. And they fulfill that need.

It's as simple as that.

Why Video Courses Are Free 💻

Why are quality, free resources in such abundance? Why do we get such amazing crops for no cost?

Why are quality, free resources in such abundance? Why do we get such amazing crops for no cost?

When it comes to video course offerings like Scrimba, Udemy, Frontend Masters, and others, only a small subset of their courses are free. They offer for free a selection and then charge for more premium courses. This is what we call a freemium model.

A freemium model gives something away at no cost, creating a lower barrier to entry for the platform. This paves the way to offer premium products afterward, particularly if the customer enjoys the free product. Freemium products are also great for the buzz they generate about the service, drawing in more customers without investing more in marketing and sales.

When the pandemic began and many learners went completely digital, many video course platforms upped their free offerings as a move to attract more customers during a time when the public was feeling nervous about spending and more conscious about saving.

Why Interactive Courses are Free ⌨

We want people to become programmers.

We want to give everyone the tools they need to foster their learning.

We do not want to gate access from anyone.

That's why we have amazing, completely free resources like freeCodeCamp. freeCodeCamp is a non-profit organization that has a donation-based model. They provide so much incredible value that alumni who learned through the platform do donate.

It exists to make coding education accessible to everyone.

Other than freeCodeCamp, other services have a model similar to video courses: they offer some courses for free and other courses for a premium.

Other interactive courses with a MOOC model, like EdX or Coursera, offer courses for free as an 'audit'. The video courses are free, but the interactive portions are gated. They might also offer an official certificate of completion that you can only get if you pay.

The Danger of Outdated Free Resources

Just about every free resource article out there talks about how free resources are just so great. But let's stop, take a moment, and talk about what isn't so great.

With all the cupcakes and rainbows that we witness in this world of learning to code for free, there are a few things that need to be kept in mind. The tech world changes with the speed of greased lightning.

Coding languages and platforms see continuous improvement and development right from the time of their conception. As trends keep evolving in sometimes unpredictable ways, resources can rapidly become out of date.

We need to understand that the resources that are free can be the best way to learn to code, but we need to keep resources in check. It is vital to make sure whatever resource you use is up to date and as per the latest technology.

I have asked the dev community openly why so many good resources by amazing, individual programmers are free.

I got a response that surprised me:\
Many developers feel that when they create something, they must also maintain it.

As developers, we have a maintenance mindset. Code is a living thing, and so is our writing and learning resources.

To a developer, the cost of maintenance is the true cost of the product. To create something and share it and then maintain it --- that is a paid service. But to create something once and put it in the world without maintenance --- that is free.

This is a mindset that may occur with some, but not all, of our free resources.

So many, probably too many, amazing developers share quality content for free.

To those who give quality coding resources for free, I think it's important to share appreciation, love, and support. The currency of 'free' for the creator is often in exposure and positive energy.

72 Best Free Learning Resources By Category

Are you prepared for the barrage of amazing free resources? It's going to be intense.

Books 📚

1. Learn Python the Hard Way

This is a substantial sample of the book, Learn Python 2 The Hard Way, which includes a preface, introduction, and the first 8 exercises of the book as well as the introductory text to the other 45 exercises.

2. Learn Ruby the Hard Way

The 3rd edition of Learn Ruby the Hard Way is completely free in digital form. It includes 52 fun-sounding, creative Ruby exercises including Doing Things with Arrays and You Make a Game.

3. A Byte of Python

This is a free digital book on programming using Python version 3 with an option to buy the print version. The book goes over all of the programming fundamentals, including object-oriented programming, exceptions, modules, and data structures.

4. Ruby on Rails Tutorial

This digital book covers Ruby on Rails in detail, from deployment, to building static pages, to building dynamic pages.

5. Launch School Open Book Shelf

This is a library of ebooks created by Launch School that teaches basics. Titles include Introduction to Regular Expressions, Introduction to HTTP, and Agile Planning. You do not need to enter any information. Just start reading.

6. Conquering the Command Line

This digital book explains UNIX and Linux commands for developers through 9 detailed chapters from Ack to cURL to tar.

7. Front-end Developer Handbook 2019

Produced by Frontend Masters, this free ebook lists tons of resources, both paid and free, for front-end developers. The guide includes a career roadmap and practical career advice.

8. Eloquent Javascript

This book is free digitally. The bestseller hardcopy is paid and produced by No Starch Press with a bonus chapter. This book is a favorite for its quality and for its free pricetag.

9. You Don't Know JS Yet (Book Series)

This entire series of books is free on GitHub and paid if you want any other format. This series is also a bestseller despite the content being free.

10. JavaScript for Cats

This guide is "so easy your human companion could do it!" This guide explains Javascript in simple terms. It includes cat illustrations and cat-centric examples.

11. O'Reilly Free eBook Library

In exchange for your email, you have access to a substantial library of quality ebooks and book samplers. You can probably find a book on any technical topic under the sun.

Blogs and Text-Based Tutorials ✍

12. Lydia Hallie

This blogger posts on Medium and the DEV community. Her illustrated tutorials on Javascript are detailed and quality.

13. Randall Kanna

Randall Kanna is a senior software engineer who often blogs about hiring, interviewing, and career success as a programmer.

14. David Walsh

David Walsh is a front-end engineer who blogs about all sorts of front-end technologies, from React to Node to API fetches to everything in between and beyond.

15. Tania Rascia

Tania Rascia has blogged throughout her entire career, since 2015, writing clear and concise, beginner-friendly tutorials about front-end technologies.

16. Kent C. Dodds

Kent C. Dodds is a software engineer and now full-time instructor who publishes his instructional material at not just his blog, but egghead.io, Frontend Masters, YouTube, Twitter, and his own sites like TestingJavaScript.com and EpicReact.Dev.

17. Joshua Comeau

Joshua Comeau’s blogs site design is adorable, with tons of artful CSS touches, like the blue grid of dots that react to your mouse position.

Joshua Comeau's blogs site design is adorable, with tons of artful CSS touches, like the blue grid of dots that react to your mouse position.

Joshua Comeau recently released his 2020 blog, and the site itself is an absolute joy to explore, with artful CSS touches everywhere. The front-end tutorials are detailed and with fun energy.

19. Robin Wieruch

Robin Wieruch is the author of simple, clear courses and guides including The Road to React, The Road to Redux, and The Road to GraphQL. His blog is packed with detailed tutorials on web development tools and frameworks.

20. Tyler McGinnis (UI.dev)

Tyler McGinnis teaches courses on React, Redux, and other modern Javascript. Tyler explains concepts simply, clearly, and thoroughly.

21. DevDojo

DevDojo is a blog with multiple authors. Its most popular topics include Laravel, PHP, Linux, Javascript, and DevOps.

22. freeCodeCamp News

freeCodeCamp's blog has many guest authors who post frequently. It's packed with tutorials that are valuable and relevant.

23. DEV Community

Like Medium, the DEV community houses blog posts and podcasts from a community of authors who do not need approval to publish. The community is active and friendly and a great place to get involved.

24. CodeWall

This blog is regularly updated with code tutorials to "motivate and encourage code lovers". Topics this blog covers is CSS, PHP, IDEs, Laravel, Node.js, and more.

25. SitePoint Blog

SitePoint's blog covers a wide variety of topics, including front-end development, UI design, mobile development, and even entrepreneurship.

26. CSS-Tricks

CSS Tricks is a classic blog, starting in 2007 and still going strong, sharing a huge variety of CSS resources and projects. The guide section is an incredible resource, including A Complete Guide to Flexbox, Media Queries for Standard Devices, and A Complete Guide to Grid.

27. Google Web Fundamentals

This is Google's "opinioned" guide about building a fast, integrated, reliable, and engaging website. The guide is divided into those four categories: preventing slow loading performance, creating integrated experiences, promoting reliability, and going beyond functionality with highly-engaging content.

28. HTML Dog

Step-by-step guides, techniques, examples, and references for HTML, CSS, and Javascript.

29. Interneting is Hard

A beautifully-designed, clean, simple, and thorough explanation of HTML & CSS.

30. Ruby in Twenty Minutes

A 20-minute Ruby tutorial that creates a MegaGreeter class that is friendly and knows how to greet everyone.

31. Ruby Koans

Ruby Koans is a text course with downloadable files. It is valuab le for those who already know Ruby looking to solve unique and interesting problems.

32. Envato Tuts+

Envato Tuts+ has free tutorials, ebooks, text guides, and eBooks covering a wide array of topics and projects including web accessibility with ARIA, PHP fundamentals, and more.

33. A List Apart

A List Apart is a multi-author blog that details creative projects surrounding many topics from code to content to design to business.

34. Learn with Google AI

This guide includes information and exercises about machine learning. If you want to get started in machine learning, this is a great place to start.

35. MIT OpenCourseWare

This free resource platform is not quite a blog and not quite a course: it offers all course materials and assignments for free, but it does not do any handholding.

You have to do all of the work yourself.

The initiative by MIT to make all of its course content public is what powers this platform. This platform is just the perfect match for beginners who want to aid their process of learning to code for free. With courses like programming for beginners to expert level courses, this is a great platform for the young.

36. Hackr.io

Hackr.io has free programming courses and tutorials for many programming languages and technologies, including Python, JavaScript, Java, Android Development, Data Structures & Algorithms, C++, React, Angular, HTML, and more.

37. Mozilla Developer Network

The MDN web docs is a popular, classic resource like the Wikipedia of web development. MDN docs covers about every web technology and serves as a fantastic resource.

38. W3Schools

W3Schools covers everything under the sun about web development, with documentation about every HTML tag and CSS rule.

39. Learn to Code HTML & CSS

Learn to Code HTML & CSS is a fantastic, free text tutorial guide with 12 lessons, including Building Your First Web Page, Opening the Box Model, Positioning Content, Working with Typography, Adding Media, and Building Forms.

40. CSS Tutorial

CSS Tutorial is exactly as the name describes. The teaching style of this tutorial is first showing the HTML and a styled page, then walking through the CSS of the example.

41. WebAIM

WebAIM is one of the most complete and comprehensive resources for web accessibility with articles about how to use ARIA to write accessible HTML as well as accessible CSS and alt text.

Video Courses 💻

42. Bento.io

Bento is created by Jon (Say, "Hi, Jon") who is a self-taught developer creating a learning platform he wished his younger self had. He says, "More than two-thirds of developers identify as being self-taught. I think that one of the best ways to get everyone to code is to help people teach themselves." The site has tons of free tracks for learning front-end development.

43. Scrimba

Scrimba has some impressive free video courses for Javascript, Vue, CSS grid, and more.

Scrimba has some impressive free video courses for Javascript, Vue, CSS grid, and more.

Scrimba offers many premium courses with a handful of quality free ones. You can take free courses in CSS grid, Vue, Algorithms, React, and more.

44. Udemy

You may find volumes of coding resources on Udemy. Even though Udemy has all sorts of topics, it is very good for material related to coding. Where it has paid courses, it also has some great free courses.

45. PluralSight

Let me be clear: PluralSight is not free most of the time.

But it sometimes is. If you are subscribed to PluralSight's email list, they announce free weeks or weekends of PluralSight to access their massive library of courses. Recently, they were free for the entire month of April.

46. BitDegree

BitDegree offers free video coding courses. Popular courses include How Math is Used in Video Games, Learn How to Make a Puzzle Game App, and Beginner Guide to How to Make a Game with Unity.

47. Watch and Code

The design of the Watch and Code website is deceptively simple: plain black-and-white, and a bold claim that this learning platform aims to be “unapologetically boring”.

The design of the Watch and Code website is deceptively simple: plain black-and-white, and a bold claim that this learning platform aims to be "unapologetically boring".

Watch and Code offers a "one-of-a-kind, unapologetically boring curriculum." What does that mean? Well, according to the plain black-and-white home page, the courses do not focus on what's trendy but what is timeless in programming. More than just video courses, Watch & Code aims to help the "serious learners" with accountability through daily accountability meetings and video chats for help when you get stuck. For Watch & Code, the introductory Javascript course is free, and instead of teaching syntax and features, the course teaches real-world development. The instructor is relatable and talks about knowing that big learning gap between the basics and more advanced material.

48. The Code Player

The Code Player shows the process of coding an element on a web page in real time. It is actually very cool and feels a bit like watching the landscape to go by on a train. This is different from a video tutorial in the sense that it has mistakes (such as typos) and meandering along the way to get to the solution, just like how someone would arrive at a solution in real life.

49. Mammoth Interactive

Mammoth Interactive offers lots of premium courses and trainings, but there is a small selection of free ebooks and trainings, including Learn to Make a Game in 30 Minutes for FREE and 2-hour Python Coding Bootcamp.

50. Programming with Mosh (on YouTube)

Programming with Mosh offers premium courses on his own site (which I have taken personally and loved). But Mosh also posts free tutorials straight to YouTube. He is a clear, upbeat instructor who produces quality tutorials on a wide range of programming topics.

51. The Net Ninja (on YouTube)

The Net Ninja offers high-quality video tutorials for free on YouTube, organized neatly into playlists. Some free video tutorials include Modern Javascript, Flutter for Beginners, Node.js, HTML & CSS, and more.

52. Upskill

If you create an account with Upskill, you have access to over 200 free lessons: The Essential Web Developer Course (197 lessons) and Javascript Basics (18 lessons). Upskill's teaching style sets them apart, focusing on explaining things simply and down to the theory behind the lessons.

53. Khan Academy

Khan Academy is marketed toward grade-school students, but the computer science principles offered in these free computer science courses still apply. Khan Academy is a non-profit educational organization created in 2008, aiming to help educate students in a range of topics.

Interactive Courses and Games ⌨

54. freeCodeCamp

freeCodeCamp is a nonprofit. This means that you can expect nothing but learning for free: no premium offerings or upsells --- just learning. freeCodeCamp's interactive tutorials are wide-ranging and valuable, cumulating into rewarding and hard-earned certificates that will make you feel proud.

55. edX

The good part about edX is its university backing. This platform has content from prestigious institutions like MIT, NYU, and Harvard. There are many different programming languages sorted into many different classes that aspiring developers can take.

56. Coursera

Another popular platform for learning things online is Coursera. It has over a hundred courses that can help you learn to code. There are a few really good free courses available here.

57. Codecademy

You can learn coding online via Codecademy. There are several languages in which you can program and you will be able to find most of them on Codecademy.

58. Learn Javascript

Learn Javascript has beginner-friendly interactive tutorials about Javascript. These tutorial exercises range between the classic "Hello, World!" to Object-Oriented Design and Javascript scope contexts.

59. Learn Python

Learn Python is by the same author of Learn Javascript. Complete beginner-friendly interactive tutorials about Python, ranging from (you guessed it) "Hello, World!" to closures and decorators.

60. Codepip

Flexbox Froggy is a free game that teaches how to use flexbox CSS rules. Move the frog to the correct lily pad.

Flexbox Froggy is a free game that teaches how to use flexbox CSS rules. Move the frog to the correct lily pad.

Codepip produces free CSS games, including the free games, Flexbox Froggy and Grid Garden, which teaches Flexbox and CSS grid respectively. I admit, I have a soft spot for Flexbox Froggy. When I worked at an agency, we all played Flexbox Froggy --- even the creative director and the designers --- and it felt like such a fun empathy-building exercise for front-end development.

61. Javascript.com

A very short, sleek and attractive tutorial on Javascript. Be warned, it's very short (but as I said, very sleek)! And it leads straight into a sell for a premium product.

62. Skillcrush's Free Coding Bootcamp

This is one of the best platforms for people who have just started the coding journey. This platform helps you stay committed to the tasks, and that too, in the easiest of manners. This will also help you in determining if learning to code is your true calling.

63. CodeGym

CodeGym lessons feel like a story-based sci-fi fantasy adventure game.

CodeGym lessons feel like a story-based sci-fi fantasy adventure game.

CodeGym was created because boring lectures are, well, boring! This program aims to teach Java with imagination and fun. CodeGym is highly gamified with rewards, currency, and 'quests'. It also has an informal speaking style, narrative, and fun, cartoonish illustrations. To use CodeGym, you need to register and select your language. Then you can start your lessons for free.

64. Codewars

Codewars believes in achieving "mastery through challenge." Codewars allows you to start writing code in the browser right away and use test-driven development (TDD) along the way. The platform is also gamified with ranks and honors.

65. CodeCombat

In CodeCombat, you guide your hero through perils by writing code that controls your hero. In the first lesson, you guide a hero with simple methods such as hero.moveRight() and hero.moveDown().

In CodeCombat, you guide your hero through perils by writing code that controls your hero. In the first lesson, you guide a hero with simple methods such as hero.moveRight() and hero.moveDown().

CodeCombat is more intended for kids, but I cannot help but mention it, because I love RPGs. In this free game, you write commands to control your character through mazes and through fights. Like a classic RPG, you equip your character and get more skilled over time.

66. Code.org

Code.org is also primarily intended to teach kids to code. Their learning games are fun and top notch.

67. GA Dash

GA Dash teaches you the web fundamentals --- HTML, CSS, and Javascript --- through projects you can do in your browser. This service is provided by General Assembly, which has both online and in-person workshops and immersives.

68. Edabit

Edabit aims to help you learn to code in the "fastest, easiest, and most addictive way." Edabit offers free interactive tutorials in a variety of languages, including C++, Java, Javascript, PHP, Python, Ruby, and Swift. Edabit has gamification features such as the ability to earn XP and level up.

69. Ruby Monk

You can become a Ruby Monk with these semi-interactive tutorial, where you click to run single lines of code and get words of affirmation from your Ruby master.

70. The Odin Project

The Odin Project offers a free full-stack curriculum, which entails HTML, CSS, Javascript, Git, databases, Ruby, Ruby on Rails, NodeJS, and even getting hired. The Odin Project (TOP) offers tracks, including Full Stack Ruby, Full Stack Javascript, and a purely front-end development track. TOP's goal is to provide a complete path to bring students from zero to an employed web developer.

71. SoloLearn

SoloLearn offers interactive lessons on a sleek mobile app, complete with lots of quizzes you can use to sharpen your coding mind while you're at the checkout at the grocery story. SoloLearn offers a series of courses, including Python, Java, C, Javascript, HTML, machine learning, data science, and more.

72. ShortcutFoo

ShortcutFoo is a cute desktop app that allows you to practice your speed and recall with keyboard commands. I have personally used ShortcutFoo to get better at using Vim. You can also do drills for Git or for your text editor. These drills will make you look like a keyboard wizard and impress your friends!

Conclusion

The path to learning to program for free can feel like a bridge with boards removed. As we learn from free resources, we encounter gaps and greater challenges we don’t yet know how to solve.

The path to learning to program for free can feel like a bridge with boards removed. As we learn from free resources, we encounter gaps and greater challenges we don't yet know how to solve.

Did we get this right? Did we just go through 72 whole free resources?!

You may be wondering: is this list aiming to be exhaustive?

The answer is 'no'. It is impossible to exhaust all of the free resources available. Believe it or not, this list is curated. There were free resources that did not make the cut.

In the middle of compiling these free resources, I looked into each one of them: watched some videos, did some interactive tutorials, and played some coding games. In this process, I was speechless --- in complete awe --- just of the abundance and of the quality.

I also learned that most of these resources are for complete beginners and it is rare to see a resource talk about truly getting from zero to programmer for free.

There is a moment between the beginner and intermediate period that is the struggle.

You know the syntax. You have the tools. But how do you code and get better? This is the moment when mentorship comes in --- when a complete project-based focus is key.

And yet this is the area that lacks in free resources. It was refreshing to see some of these resources speak to the intermediate level, such as The Odin Project, Watch and Code, and Bento.io. These are the resources I look out for.

That said, I hope you enjoyed this Ultimate Guide. If you're interested in learning faster and studying wiser with your programming books, sign up for my free email course, Getting the Most From Technical Books at Books on Code.

And if you are interested in learning more about free resources for front-end developers, I have a Books on Code article that you will love called Top 5 Free Books for Front-end Web Developers. I will see you there. 👋 😁

What are your favorite DEV blogs and bloggers teaching coding concepts?

Miranda — Mon, 03 Aug 2020 05:47:38 +0000

I'm compiling an extensive list of free coding resources.

I would love to know your favorite self-hosted blogs or bloggers that are instructional and valuable.

I'm sure to miss some awesome people without your help. 🙏

Accessibility Matters: How to Build Apps for Everyone with Miranda Limonczenko

Miranda — Thu, 23 Jul 2020 11:52:28 +0000

About Miranda

Miranda is a Senior Technical Writer at VMware, a front-end developer, and a user experience advocate. Miranda chronicles her coding journey at BooksonCode.com.

Presentation Outline and Transcript

My name is Miranda Limonczenko. I am a senior technical writer at VMware and a front-end web developer. Today I'm going to be talking to you about web accessibility, why it matters, and my experience building a website for Guide Dogs for the Blind with a team. And also what we did for web accessibility.

Why Web Accessibility?

Really, it's in the name: access. Web accessibility allows anyone to use web apps and software without restriction. It's vitally important because of how much we rely on software. Our ability to work, learn, and live depends on our ability to use software and web apps.

When we build sites that are not accessible, even though we have all of the tools to make it accessible, we are excluding people from a job, from an education, or from a product. That is why there is such a good case for lawsuits.

Today, I'm not talking about lawsuits, but what's positive in web accessibility, which is creating experiences for users.

Which is why it was so exciting to work with Guide Dogs for the Blind building their website.

Our Goal

Our goal for building their website was to create a delightful experience for those who are blind or visually impaired.

People going to the site, maybe those who just recently had an injury, who may those have been suffering for years -- creating a delightful experience on the site is offering some sort of relief or comfort so that hopefully they will seek out services.

Key Areas of Focus for the Blind and Visually Impaired

We broke it up into two user groups: the blind and the visually impaired.

For the visually impaired, we focused on high color contrast, dramatic hoverstates, and an option to raise contrast among many other things, but we're focusing on these today.

For the blind who are using screenreader software listening to an HTML document being read, we focused on menu architecture, grounding elements in context, and alt text to enrich the experience with images.

High color contrast

With high color contrast, we used this contrast tool, which was fantastic. We tested all of our brand colors: black text and white text on top of all of the brand colors. I recommend that anyone do this.

So some things we discovered:
We had all of our brand colors in a spreadsheet. We discovered white text worked best on the brand color pink, but also for all of the other brand colors, black text worked best. For me as a web developer, it was important for me to remember this and to make an exception for white text on a pink background. In this case, there is an exception instead of consistency between brand colors.

But we also learned that black text on orange, which is another brand color, is better contrast even though visually to some of us it felt like it was higher contrast. It's important to keep in mind color blindness, which is why it's important to use software. We can see contrast when it's different for different people.

Dramatic Hoverstates

This one is not that intuitive for a lot of people. It's definitely something we all need to learn -- myself included.

This is true not just for hoverstates but for diagrams or status indicators. Color should not be the only indicator for a change. Just changing something from green to orange to red as status indicators is not enough to signal state.

So this can be movement and this can be an icon or an outline or just something visually different that is color based.

I have a couple of examples. There's the white on pink and the black on orange. For before you hover, it's a pink background and white text. After you hover, the text color changes, the background color changes, and there is a border. If you imagine that the color difference is not there, you can still see there is a difference. But also I think it's important to note that it really does look beautiful. When we think of hoverstates, so often the trend is to show slightly less opacity or to go from black to gray. Even though it may seem like these subtleties are beautiful, it's also beautiful to have high color contrast and it serves more people.

Here is another example: the color changes but also the icon flips the negative so that the arrow is colored in and the dot disappears.

Contrast Toolbar

Finally, I say it's a 'bonus' -- we added a toolbar to raise contrast and text size. This was something that we did because we wanted to show that we valued people coming to the site. We know that there are people who use magnification software or they use contrast software. But for people who don't have the software or don't know about it, we wanted to give them this option to raise contrast and text size across the site and that will stay saved so that every time they look at the site, it is configured to their settings.

I had feedback from one of the users. She used magnification software and color contrast software, but when she was using the site, she said "the site is so beautiful, I don't need the software". It just made me so happy.

Menu Architecture

Now we're talking about people who primarily use screen reader software. These are people who can still be looking at the site when they use screenreader software, but primarily they are using the screenreader software.

One thing we focused on was the menu architecture. This is something a lot of us don't think about: the main body of the page stands out to sighted users. There's advertisements, there's call to action, there's all this stuff. But when you use a screenreader, what you experience first is the menu architecture. A lot of the time, you don't get to the body. If you hear the place you want to go, you navigate to it.

That's why it's important to focus on the experience of main menu architecture. We did research for this. We used a tool called Optimal Sort. We took content, put it on a bunch of cards, sent it to various users and had them group the content into buckets. Funny story: I felt like I did a great job. When I organized the content, I thought it was perfect. But when I saw how other people organized it, I was definitely an outlier. People percept things differently, which is why it's important to do research.

Grounding Elements in Context

Next, we focused on elements and grounding them in context. With this, I think it's so important for a web developer to use screenreader software. Voiceover software is built-in for Mac. You can navigate your web app with a screenreader so that you can optimize it.

One of the things you can do with a screenreader is to jump from header to heade or link to link. They are not read with the paragraph in mind. You might hear "click here". You might think "What's here?" and you don't know.

With links, you should say where they are going.

If it doesn't make sense visually, you can override with an aria-label. For example, an aria-label can say "you are currently on page one" when the actual text just shows "1".

Images Enrich the Experience with Alt Text

Last thing we focused on (in this presentation anyway) is "images enrich the experience with alt text". Alt text is something I'm passionate because it's so easy to get wrong.

There's so many times I see "diagram about" but it doesn't say what's in the diagram. That alt text is leaving out the information that someone needs to learn. It's important to have empathy, to imagine what the intent is, and to deliver on the intent. Context matters. If the exact information is redundant, then you don't need to repeat it.

Here's another example from the Guide Dogs website: there's hero images all over the site. They're beautiful and they take up most of the page. Me, I thought that they should be left blank because they are decorative. But, I got the feedback from users that they can see this big, colorful, beautiful image taking up the majority of the page, but they couldn't see what the image was. We ended up going through the site and adding alt text to the big hero images.

For example, a hero image says, "A female GDB graduate hikes along a rail with her black lab guide dog next to her."

Final Thoughts

Really, I wanted to emphasize how much fun it was to build a thoughtful, good site for the blind and visually impaired. It really helped me see that it's just good design, good development, and it should be at the heart of everything we do. It's about being empathetic, curious, and building the best experience for users.

Link to Presentation

Here is a download link to the talk slides (PDF)

This talk will be presented as part of CodeLand:Distributed on July 23. After the talk is streamed as part of the conference, it will be added to this post as a recorded video.

Why Clean Code is Still a Classic

Miranda — Wed, 22 Jul 2020 16:11:44 +0000

This article was originally published on Books on Code.

Not many books can be considered classics in the programming community. Programmings books too easily become out of date. In order for a programming book to be a classic, it must share all-around good wisdom rooted in good principles.

Clean Code is certainly one of these rare classics. When I asked my readers what programming book they can't live without, this book topped the list along with The Pragmatic Programmer.

For being published over a decade ago, which is a lifetime in the tech world, the book has Java examples that are beginning to date. Long-time fans are now likely hoping for a fresh coat of paint soon.

But even with this small fallback, Clean Code is the current Amazon #1 bestseller for the "software testing" category.

Why does Clean Code continue to have such an impact on readers a decade after its publication?

Programmers self-report having a coding awakening after reading the book. They are profoundly changed. Their entire philosophy about code, and therefore about their careers, gets a radical shift.

Programmers who have coded for decades discover this book and deeply regret all the years they went without this book's teachings. That's how powerful this book is.

Those who have had their code philosophy transformed wear this book like a badge of honor, reading it every year to stay fresh and to spread the word of Clean Code.

So if, like me, you are wondering what all of this is about, I have a fresh copy of Clean Code in front of me and we're about to walk through it together, key point by key point.

Let's get ready to embark on the clean-code mindset shift and share the greatest takeaways together.

My Top 7 Clean Code Rules

The following sections are key takeaways I had reading Clean Code for the first time.

Rule 1: Code Matters and You're Responsible for Cleaning It

Clean your code with soap and water every day. It's your responsibility.

You are reading this book for two reasons. First, you are a programmers. Second, you want to be a better programmer. Good. We need better programmers.

This is a book about good programming. It is filled with code. We are going to look at code from every different direction. We'll look down at it from the top, up at it from the bottom, and through it from the inside out. By the time we are done, we're going to know a lot about code. What's more, we'll be able to tell the difference between good code and bad code.

--- Clean Code

Code represents the "details of the requirement." Code itself is a small, essential piece that makes up the whole. We cannot abstract away code, just like I can't abstract away the individual words and sentences in this article. Code itself is essential to programming.

By talking about abstraction in the opening pages of Clean Code, we immediately launch into the philosophy of code that we adopt for the whole book.

The book gives its first warning: we should not worship abstractions and respect foundations.

The book goes on to say that bad code has been the culprit in dismantling whole companies. Debt builds and builds. Features pile and pile. Sooner or later, the whole foundation crumbles and the company folds.

Bad code is behind major slow down after a big spike in productivity with a fresh codebase. The build slows and slows so that changes that should take hours instead take weeks.

But for many codebases, the mess prevails!

Clean Code then shares something that is the beginning of the code indoctrination: it's your fault. Programmers must take responsibility for the code. Why? Well, who else actually knows the code and can speak on behalf of it?

And while managers can seem scary, they honestly want the truth. But just as a part of being human, it's too easy to be agreeable, to divert blame, and to let bad situations happen.

As an employee at a software company myself, I know how it feels to divert blame because I have done it and have seen others do the same without realizing it. It takes courage to take responsibility and to do the right thing and to not naturally spot scapegoats.

Taking responsibility is a powerful skill and it can turn a fine programming into a truly good programmer. That is, if they have the ability to turn mess into clean code. The book calls this ability "code-sense."

Clean Code likens "code-sense" to any art in the sense that it can't be taught but guided and nurtured. The book itself claims to give rules that are not an absolute principle, but absolute in the sense that we create rules around sports. The 'rules' are law within the discipline, although they may not speak an absolute, universal truth.

Rule 2: Pick Good, Intention-Revealing Names with NO FUNNY STUFF

On a name tag, I write just "Miranda." My intention is for people to call me by name. What if I were to write something funny there instead?

The hardest thing about choosing good names is that it requires good descriptive skills and a shared cultural background. this is a teaching issue rather than a technical, business, or management issue. As a result many people in this field don't learn to do it very well.

--- Clean Code

Alright. So we're in the meat of the book now (and also in the meat of code). We're talking about names now: variable names, function names, argument names, class names, file names, package names, and all of the names.

So what's in a name? You know, to make it "smell as sweet"?

Here's a quick summary of the basic tips:

Use intention-revealing names: The name should answer big questions like why it exists, what it does, and how it is used.
Avoid disinformation: The name should not leave false clues. For example, an object with List in the name, when it is not itself a list, is disinformation. Even if "list" has some semblance of truth, our technical understanding of "list" makes anything other than a "list" data structure disinformation.
Make meaningful distinctions: An example of poor naming is a1 and a2 for argument names instead of simply distinguishing them with meaningful names.
Use pronounceable names: Clean Code argues that as humans, our brains have evolved to deal with the spoken language and therefore pronounceable names are just aesthetically nice and easier to talk about with colleagues.
Use searchable names: This is a dis on single-letter names like e. When we're searching through a codebase, having some intuition about where to find code would be nice.
Avoid encodings: Encodings in names create the problem of requiring anyone reading the code to have additional context.
Avoid mental mapping: No mentally translating names into other names. In other words, no being smart about names. Just say it straight.
Class names: Class names should have a noun phrase. No verbs. Save those for methods.
Method names: Methods should have a verb phrase. No nouns. Save those for classes.
Don't be cute: And don't be funny. Don't name a function HolyHandGrenade (which breaks the rule directly above anyway) but instead say DeleteItems.
Pick one word per concept: In other word, be consistent. Don't use fetch and retrieve interchangeably. Choose one and stick with it.
Don't pun: Same as being cute. Also don't be funny!
Use solution domain names: We can assume that programmers have computer science knowledge, so we can use computer science terms, algorithm names, pattern names, math terms, and more.
Use problem domain names: Code that has more to do with problem domain concepts should have names drawn from the problem domain. Worse case, the programmer will just have to ask an expert or use Google.
Add meaningful context: Imagine a variable out of context. If you see state next to zipcode, you have a different idea than if you see state by itself.
Don't add gratuitous context: Adding prefixes or using redundant naming conventions are both ugly and unnecessary. Shorter names are normally better as long as they are clear.

In the list, I find funny the number of "don't"s and "avoid"s. Multiple points drove the same point: don't be funny, cute, or smart. Just say what the thing is or what the thing does.

The most valuable and prescriptive naming conventions for me are consistency ("pick one word per concept"), use solution domain names, and use verbs for methods and nouns for classes. Also, the more we know about algorithms and design patterns, the more aptly we can name our objects.

Rule 3: Functions Do One Thing Within the Same Level of Abstraction

Each domino does only one thing: once it receives force, it falls over.

The first rule of functions is that they should be small.

The second rule of functions is that they should be smaller than that.

--- Clean Code

Here's the problem with the "do one thing" advice that is common for chunking functions: what is one thing, exactly?

Depending on how much we abstract, one thing can be quite big or quite small. A whole piece of software is "one thing." Can you imagine what that function would look like?!

So Clean Code came up with a more specific rule about this: the statements in our function must be within one level of abstraction.

Clean Code says, "Master programmers think of systems as stories to be told rather than programs to be written." Reading code is reading a story: it introduces elements, puts them through a journey, and ties up loose ends.

Mixing levels of abstraction is always confusing and we can sense when they have been mixed. We expect to see pieces of consistent size within our functions even if we don't consciously know it. Writing code in this way can be challenging to grasp, but ultimately rewarding for the readability and maintainability of the code.

The goal of any function doing "one thing" is to have no consequences. It doesn't mutate anything unexpectedly. There are no tricks.

Rule 4: Comments are Always Failures

Comments exist when things are out of place or not working as they should.

It is possible to make the point that programmers should be disciplined enough to keep the comments in a high state of repair, relevance, and accuracy. I agree, they should. But I would rather that energy go toward making the code so clear and expressive that it does not need the comments in the first place.

--- Clean Code

The ideal state is for code to be self evident. Whenever there is a need for a comment, it indicates how the code is failing.

This philosophy about commenting was the opposite taught to me in the classroom. I would have a failing grade on a C++ assignment if I didn't extensively document the purpose of every method and every argument and every variable of a class. Because of this traditional education I had, I got a rude awakening in the workplace. How embarrassing.

The problem with comments, as I have discovered myself, is they do become wrong over time and don't follow the original source of code. "This list is in alphabetical order." Is it really now?

Rule 5: If Error Handling Obscures Logic, It's Wrong

Error handling within the code acts like a thick fog on the code itself.

Many code bases are completely dominated by error handling. When I say dominated, I don't mean that error handling is all that they do. I mean that it is nearly impossible to see what the code does because of all of the scattered handling. Error handling is important, but if it obscures logic, it's wrong.

--- Clean Code

When it comes to error handling, Clean Code encourages using exceptions rather than return codes. For code to truly be clean, the error handling must not obscure the logic.

So how is this done? The book describes several rules:

Write your **try-catch-finally** statement first: Doing this helps you define what the user of that could should expect no matter what goes wrong in the code.
Provide context with exceptions: Thrown exceptions allows you to be able to determine the source and location of an error so that you can determine the intent of the failed operation.
Define exception classes in terms of a caller's needs: While we can classify exceptions by any number of things, like source or type, but Clean Code argues the most important distinction is in how the error is caught.
Don't return null: If you don't ever return null, you don't have to check for null. Simple.

Rule 6: Write Clean Test Suites, Too

Messy tests can ruin your production code.

[In TDD, we]write dozens of tests every day, hundreds of tests every month, and thousands of tests every year. If we work this way, those tests will cover virtually all of our production code. The sheer bulk of those tests, which can rival the size of the production code itself, can present a daunting management problem.

--- Clean Code

You probably knew this was coming. Clean Code wouldn't be deemed clean without Test-Driven Development (TDD). But Clean Code talks about more than TDD: it talks about also keeping your tests clean.

If you practice TDD, you will grow a huge number of tests. And like everything else, you need to organize and manage it. The book says that "having dirty tests is equivalent to, if not worse than, having no tests." Like code itself, it can get so messy that it adds hours of bloat to maintenance and creates an unhealthy relationship between the tests and the production code. Changing something in the production code might set off dozens of unnecessary bombs in the test suit. For programmers changing production code with messy tests, they brace for impact each time they edit a line.

But there's a solution!

Clean Code says that "readability" is everything when it comes to tests. Readability trumps all with test suites --- potentially more than production code.

But 'readability' is actually a fairly loaded term, defined in the book as "clarity, simplicity, and density of expression." Quite a lot to unpack there. Perhaps an entire other book's worth.

The book does include a cute, little acronym on writing good tests, though. The acronym is FIRST and it goes like this:

Fast: Tests should run quickly, otherwise people are less likely to run them and the code will begin to rot.
Independent: Tests do not depend on each other.
Repeatable: They can run in any environment.
Self-Validating: They either pass or fail. You do not need to have to interpret the results.

Rule 7: Recognize Code Smells

How does your codebase smell? Can you make it smell like flowers?

This list of heuristics and smells could hardly be said to be complete. Indeed, I'm not sure that such a list can ever be complete. [...] Clean code is not written by following a set of rules. You don't become a software craftsman by learning a list of heuristics. Professionalism and craftsmanship come from values that drive disciplines.

--- Clean Code

The final chapter of the book includes a catch-all section for 'smells'. These are general rules for when something probably isn't right. But with the same philosophy The Pragmatic Programmer, programmers should not follow rules blindly, but have their own understanding.

In my time working in the software industry, I have heard of a number of these 'smells', but it's nice to see a collection of these all in one place.

Here is a sample of the 'smells' a codebase might have:

Obsolete comment: Old comments. Ew.
Redundant comment: Comments that describe something self-evident. Also ew, but honestly not so bad. A simple delete takes care of that.
Poorly-written comment: In my experience, the worst writing over-explains details that nobody cares about.
Commented-out code: This just rots over time. We have version control. Just remove it.
Test require more than one step: All unit tests should run with one command.
Functions have too many arguments: Keep it down to zero, one, or two. More than three is questionable.
Dead functions: Functions should be removed if they are never called.
Duplication: Duplication in code is a missing opportunity for abstraction.
Inconsistency: Do the same things the same way every time.
Understand the algorithm: Make sure you understand exactly how your function works. It's understandable that the process to get there came from little tweaks here and there, but truly get the full picture before you're done.
Replace magic numbers with named constants: Magic numbers are those strange numbers that are not self-evident in purpose, but we need them to make specific calculations. Leaving the numbers as they are, without a label, can confuse future readers and obscure what the operation is doing.

Final Thoughts

Wow. After reading Clean Code, I am surprised to have discovered a well-written and inspiring programming book.. I enjoy that the book addresses programmers as craftsmen. It makes me feel respected as owning a trade that takes skill and creativity.

Clean Code echoes a similar reverence and charm as The Pragmatic Programmer, and I can see why these two texts are toted side-by-side. As programmers, we have a duty to uphold the integrity of the code, and I feel inspired by the nobility of the task.

Overall, I feel this book is worth owning and refreshing with from time to time. The book is large enough to grow with you as you focus on different pain points of coding throughout your career.

If you liked this article and if you are inspired to better yourself by reading more books on programming this year, I have a free email course that you are sure to enjoy called Getting the Most From Technical Books.

As always, let's keep bettering ourselves as programmers and perfect our crafts.

Until next time. 👋😁

What is Web Accessibility and Why Does It Matter?

Miranda — Mon, 22 Jun 2020 16:46:06 +0000

This article was originally published at Books on Code.

There is no better time to talk about web accessibility. You may have started a project where you know web accessibility is a project priority. Perhaps your teammates advocate for better web accessibility practices or you want to advocate for web accessibility yourself.

In order to advocate for web accessibility, you need to answer the essential questions for your team --- questions like "What is web accessibility?"

This article will teach you everything you know about what web accessibility is and why you and your team should care about web accessibility so that you can start that initiative, draft your plan, and start building better web apps today.

Overview

This article draws much of its information about web accessibility from Practical Web Inclusion and Accessibility(2019) by Ashley Firth, which is an up-to-date guide on web accessibility that is both succinct, simply written, and empathetic to various user groups. The book is written with not one discipline in mind; it has value for both product managers, designers, and web developers.

At Books on Code, we focus on the rich web development skills we can build from books. This accessibility book delivers on that, bringing an in-depth experience that helps you fully immerse in web accessibility thinking.

What is Web Accessibility?

[Vinton Cerf, recognized as one of the "fathers of the Internet", ] described email to the New York Times as "the great equalizer in that everyone, hearing and deaf, uses the same technology." This is the essence of accessibility. It means removing the barriers that might prevent someone from using something, regardless of their access need.

--- Practical Web Inclusion and Accessibility

Web accessibility is in the name: access.

Web accessibility means that you accommodate different access needs. This concept is far broader than what you might think.

An access need is, according to Practical Web Inclusion and Accessibility, "anything a person requires to communicate, learn, or take part in an activity."

A disability can be permanent or temporary. It is important to think of disability not as a 'personal attribute' but as a state that is dependent on environmental context. According to the book, "disabilities happen during interactions between a person and the world around them on a physical and cognitive level."

Examples of permanent disabilities can be blindness, visual impairment, or motor disabilities.

Examples of temporary disabilities: when someone drives a car or has an arm in a cast. These various conditions mean that certain modes of access, such as sound, keyboard, mouse, or a screen, may be inaccessible.

We often overlook access needs and don't realize how vast this landscape is.

Why Should I Care about Web Accessibility?

[D]ue to the growing trend of lawsuits and media coverage, it's also important for project stakeholders to understand the importance and repercussions of exclusionary design.

--- Practical Web Inclusion and Accessibility

Web accessibility is for everyone.

Designing for web accessibility is just good design.

Developing for web accessibility is just good development.

That is why building for web accessibility ought to be integrated from the very beginning --- it's why web accessibility ought to be taught with fundamental design and web development classes. These concepts are that basic, and yet our literacy is still too low.

Web accessibility changes lives because the web itself changes lives. Through the web, we have access to both education, entertainment, and our livelihoods. We can build businesses and communities. We can learn anything.

No child should lack access to education. No adult should lack access to making a living.

With my work in enterprise software, we have provided software in which it is peoples' jobs to use the software. If that software does not allow for certain access needs, then we are excluding people from a job.

That is why those who sue companies have so much leverage --- because it infringes on our civil liberties. When the web is so flexible that we can build for accessibility with a little bit of knowledge, there is no excuse to restrict access for anyone.

We have all of the tools we need to provide accessible technology. Failing to provide it is a disservice to the communities we serve.

How Do I Learn Web Accessibility?

Now that you have reached this point of the article, you are 100% bought in on web accessibility and its huge importance.

But now it's time for the hard question: how do you learn about and implement web accessibility practices?

And this is where it is so easy to be led astray. Because while I sold you on building and designing accessible web sites for users, the bait-and-switch is this: there is web accessibility compliance and guidelines, and it's all-too-easy to focus on compliance and not user experience.

Did you know that you can build a web app that is both web accessibility compliant and does not serve access needs? As a word of caution, do not be a slave to the guidelines and get into a "ticking boxes" mentality. Otherwise you will not truly be serving your users.

To truly prioritize users and create great apps that meet web accessibility, I highly recommend purchasing and reading the book Practical Web Inclusion and Accessibility. The book groups web accessibility standards by disability and access needs. The book is also not dry; it's extremely well written and packed with examples for designers and web developers.

You can also read my article, Top 10 Web Accessibility Standards Every Developer Should Know, which helps you get into the mindset of a mindful developer.

I hope you enjoyed this article on web accessibility. If you are a web developer who wants to grow and learn through books, please join my Books on Code newsletter.

If you want to start a web accessibility initiative, share this article with them. Let them know how important and crucial web accessibility actually is.

As always, I appreciate you taking the time to read this article, and I look forward to seeing you in the newsletter. 👋😊

Top 10 Web Accessibility Standards Every Developer Should Know

Miranda — Mon, 08 Jun 2020 16:31:05 +0000

Article originally published at Books on Code.

You know that web accessibility standards are important. As a web developer on your team, you want to be knowledgable and committed to applying the most impactful web accessibility standards so that you can create better experiences for everyone.

There is a problem though: the Web Content Accessibility Guidelines (WCAG) are crazy long. The depth of each rule is overwhelming, and with each mind-numbing paragraph you read, you feel farther and farther away from the true goal: creating great experiences for everyone.

At the end of the day, we want to be developing web apps for people, not rules. And instead of facing overwhelm, we should be able to pinpoint real changes we can make to our products and websites that we can make right now.

While these top web accessibility standards are obviously not an exhaustive list, I hope they give you a starting point to begin thinking about and implementing accessibility standards today.

Overview

These top web accessibility standards are drawn from the hands-down best book on Web Accessibility, Practical Web Inclusion and Accessibility(2019) by Ashley Firth. The book is designed with not any one role in mind, because web accessibility standards are best championed by an entire team. That said, I believe the book is particularly valuable in the hands of a web developer. The book includes many code snippets and simple instructions for developers to implement web accessibility standards.

The book is also designed to help you think critically about solving problems for people. As such, the book organizes around various disabilities, both permanent and temporary, with disability defined as people in relationship to the world they interact with. These chapters include blindness, low vision and color blindness, motor disabilities, deafness and hard of hearing, cognitive impairments, mental health, and more, acknowledging that there are still cases outside of the book's coverage.

The crux of the book is about empathy rather than rules or systems, which is the philosophy I take in prioritizing the top skills you see below.

Top Standards for Blindness

Contrary to common belief, visual impairments need not be a barrier to using the Internet. If websites are well designed, it is easy to include users with sight loss, who can have just as rich an online experience as anyone else.

--- Practical Web Inclusion and Accessibility

The following web accessibility standards are particularly beneficial to those who experience blindness. The blind interact with the web typically through screenreading or braile software.

1: Use Semantic Markup and Landmark ARIA Roles

A div does not give context to the content it contains, yet we use the div all the time. For someone using screenreading software, jumping through a sea of divs, they don't have a sense for where they are on the page.

Am I in the beginning, middle, or end?

Am I in a modal or a form?

We have two solutions to offer context to the user: semantic markup and ARIA roles.

Semantic markup are tags like header, section, main, nav, and footer. Tags like header, main, and footer are tags that you can easily add to about any web page.

ARIA roles provide context similar to semantic markup. The difference: you can add an attribute to any tag, including a div.

For example, <div role="navigation"></div> is equivalent to <nav></nav>.

For a list of landmark ARIA roles and other ARIA roles, see Landmark Roles on the MDN Docs site.

2. Include alt tags on images

Alt tags are valuable for many types of users, and they help users understand what they are unable to perceive.

In my experience user testing with visually impaired user, for example, I worked with a user able to see a large, colorful hero image, but without alt text, they could only wonder what that image was showing.

Writing good alt text can easily be misunderstood, because alt text authors can be tempted to label an image rather than perceive the image.

For official guidelines about alt text, see Alternative Text on the WebAIM website.

3. Add a Lang Attribute

The lang attribute is often forgotten, but it is vital for a user to experience a page on a screenreading device in the language it is intended. A lang attribute is placed on the html tag. For English, you can set the value to en. But you can get even more specific with script and region subtags.

For example:

<html lang="en">\ ...\ </html>

For more information about the lang attribute, see lang in the MDN Web Docs.

4: Create a "Skip to main content" link

You can include a link at the top of your document to allow a screenreader user to opt to skip common, repetitive content like the logo and main navigation. The user can instead go straight to your main content. Every time your user goes to a new page, you can improve their experience by giving them an easy navigation option instead of go through the same 'welcome sequence'. This is convenient, like the option of skipping the intro to a series you stream on Netflix.

You can visually hide this link using CSS, but the link is visible when users navigate to it using a keyboard.

To add this link, see the following example:

HTML:

<a class="skip-to-content" href="#content">Skip to main content</a>\ <main id="content">...</main>

CSS:

.skip-to-content {\ position: absolute;\ top: -400px;\ }

Top Standards for Low Vision and Color Blindness

Because there are so many types and combinations of visual impairment, sometimes there is simply not a one-size-fits-all solution for users. Low vision is one of the rare areas of accessibility where fixing one barrier can actually create another for a different user.

--- Practical Web Inclusion and Accessibility

Users with low vision or color blindness can be extremely diverse. In my own experience working with low vision users, I found users who both looked at the screen at a magnified size as well as used a screenreader for re-enforcement. In that light, I knew the importance of consistency between the screen and the screenreader.

Despite the varied disabilities users experience, the following web accessibility standards are particularly beneficial for those with low vision or color blindness.

5. Use Relative Units and Not Pixels for Font Size

Using fixed measurements like pixels can be detrimental to those using magnification. Text sized with pixels will ignore user preferences. If 14px font size is too small, zoom in and it is still too small.

Instead, use measurements like rem or em. These measurements factor user preference and will allow for a more flexible reading experience.

6. Test for Color Contrast and Text Size

High color contrast and text size can improve the experience for all of us, and yet as a way of de-emphasizing text, we still use small text sizes and light-gray-on-white text in our designs. As a rule, we should aim for high contrast and experiment with bumping up our base font size and prioritize readable fonts.

My go-to contrast checker is Contrast Ratio.

7. Don't use Color Alone to Indicate Status

In many designs, colors like red and green are used to indicate status. If these are the only indicators, those with a common type of color blindness may not perceive the difference or find it challenging. It is easier for someone with a red-green deficiency to tell the difference between a light green and a dark red. However, indicating status with a light green and light red may be more difficult to differentiate.

You can use indicators in additionn to color. For example, icons can also serve as an indicator.

Top Web Accessibility Standards for Motor Disabilities

Have you ever tried using a website without a mouse? It's harder than you might think, particularly when trying to perform actions across multiple pages such as signing up for or purchasing something. Some users that have motor disabilities often only use a keyboard to interact with a computer[.]

--- Practical Web Inclusion and Accessibility

The following web accessibility standards are helpful for those who experience motor disabilities and use a keyboard to navigate a web page.

8. Use Focus Styles

By default, an element has a blue glow around it when you use the tab button, but many designers might decide to remove this style because they may feel it looks unpleasant. The focus indicator can be removed altogether by using the CSS style *: focus { outline: 0; }.

As you can imagine, removing the focus presents a big problem. Having a clear focus style is invaluable, so take considerations for creating both a tasteful and obvious focus indicator. As a developer, it's important to tab through your app and notice when focus indicators are not obvious.

Also pay attention to overlays like modals. Make sure that the close button is obvious and accessible using a keyboard.

9. Avoid Content that Appears on Hover

In elements such as a drop-down navigation, the hover state is triggered as the area of focus on a keyboard. But there's a problem: when you move off the top-level item, the menu collapses.

In addition, screenreaders do not read content if they have visibility: hidden or display: none set. If a drop-down navigation is in use, make the element appear invisible but remain visible to screenreaders. You can do this in the same way you would the "Skip to main content" link with absolute positioning. If you solve the problem in this way, keyboards can still reach the content, but it remains invisible. A way to solve this issue is by allowing the menu to expand permanently on click.

Top Standards for Deafness and Hard of Hearing

At a glance, these users experience similar access needs --- auditory information must be communicated in alternative ways. In reality, there is far more to it, and it's important to remember that different deaf users have different preferences about how they receive this information.

--- Practical Web Inclusion and Accessibility

10. Add Captions and Caption Actions Using the Track Element

In HTML, you have a lot of control over your captions. Using the HTML track element, you can add multiple subtitles files to video in different languages. A common file format for captions is .vtt or Web Video Text Tracks Format. For more information about the track tag, see : The Embed Text Track element in the MDN web docs.

You are also able to style your captions with CSS. The cue rule, which you can target like video::cue or audio::cue allows you to style the captions themselves.

When you write your captions, it's valuable to keep in mind actions as well as dialog. You can indicate actions with square brackets. For example, [spits drink].

Learn More About Web Accessibility Standards

These ten web accessibility standards are a great set of standards that will allow your site to drastically improve the experience for others today, but there is a lot more to learn, especially when it comes to complex site interactivity with forms and online checkout experiences.

The book, Practical Web Inclusion and Accessibility, covers far more. The book is worth the investment if you are looking for web accessibility standards that are both easy-to-understand and implement.

If you liked this article, share this article with your team. Start the conversation to drastically improve the experience of your website or web app. After all, web accessibility is best implemented with the whole team.

Also if you liked this article and have interest in learning and growing as a developer through technical books, keep that learning journey going by signing up for the Books on Code newsletter.

3 Crucial Strategies to Becoming a Programmer

Miranda — Mon, 18 May 2020 23:06:04 +0000

This article is originally re-published from Books on Code.

I have a serious question for you: what is holding you back from becoming a programmer?

Likely, your blockers are psychological. You tell yourself that there is an impossible number of skills to learn, that other people are smarter or better at studying, or that the competition is just too fierce.

Was trying this expedition a big mistake? Are you too old? Do you need to go back to school for a computer science degree? Perhaps you were not meant for this after all.

I get emails from my readers who are going through these struggles. Students from my free email course, How to get the Most From Technical Books, ask questions about concrete and specific ways to study, when what they don't know is that fear is driving their study habits. They quit their job or declared their intentions; they feel the pressure while facing a steep and seemingly endless learning curve. They want to sit with a book and glean knowledge, but the scatterbrained mindset pervades.

In this article, I'm sharing three crucial strategies to become a programmer. These strategies are to help change your mindset, dispel fear, and become the person you want to be.

Overview

The three strategies outlined in this article are inspired and drawn from the book Atomic Habits (2018) by James Clear.

Atomic Habits is a New York Times bestseller that book lovers rave about. As someone who has read self-help books for a long time, I have become cynical to the genre. When I first heard of the title, I thought Atomic Habits was going to have another airy premise along the lines of "good habits are good and bad habits are bad" with lots of filler and inspirational words.

This is not true of Atomic Habits. The book is dense, no longer than it needs to be, and packed with actionable mind hacks and real lightbulb moments. If any self-help book gives me one great insight, I consider it a success. For my review of Designing Your Work Life, my great insight was "gravity problems": all of humanity's tendency to drive themselves crazy over problems as persistent and unsolvable as gravity's existence.

With Atomic Habits, my key insight is our identity's unconscious bond with our environment. More about this in the following sections. But on top of that insight, the Four Laws of Behavior Change are real show stoppers.

Strategy #1: Make 'Programmer' Your Identity

Who do you want to become? ... Start there and work backward from the results you want to the type of person who could get those results. Ask yourself, "Who is the type of person that could get the outcome I want?" Who is the type of person that could lose forty pounds? Who is the type of person that could learn a new language? Who is the type of person that could run a successful start-up?

--- Atomic Habits

Start with the end-game first. This is similar to the insight Cory Althoffhad in his book The Self-Taught Programmer: "Instead of studying opening moves [of chess, [Josh Waitzkin] started learning the endgame (when there are only a few pieces left on the board) first. This strategy gave him a better understanding of the game, and he went on to win many championships."

When you have a clear vision of what you want to become and frame your actions around the identity, your chances for success are far greater. Why? You are better able to identify the characteristics you need to embody and filter out the distractions. The murkier the vision, the more likely you are to be overwhelmed and focused on areas that do not contribute to the end goal.

A common pitfall for aspiring programmers: they think they need to know everything --- basically the whole universe pertaining to the set of 'programming skills'. They are so fearful of their own inadequacy that applying for a job today sounds preposterous.

I'm fortunate to have an uncle who has been in the industry for decades more than me. He has had to re-invent his tech career several times over. His advice to me has always been this:

Each tool or skill is not very hard to master. It's just that there's an infinite number of them.

And believe me: you do not need to know an infinite number of things. A small, steadily growing subset is enough.

So really, you need to be defining your subset. And that subset can change across your career.

Start with a picture of what you want to be building and work your way backwards. For example: let's imagine you want to build a fence around the border of your house. Where do you start?

You imagine the fence you want, which is easy to do without skill. If you want to do it in the first place, you probably have an idea about the end product. You then pose initial questions about how you might build your fence. This is the point you start learning: you watch YouTube videos, or consult books, or do whatever you have to do to answer your questions. You isolate your project into steps and learn each step as you go along. Eventually, you do end up building a fence, and you picked up skills along the way. Now that you can build a fence, you can build fences for other people and maybe even get paid to do it.

Notice that it's building a a fence --- not building a house with plumbing and electrical and all. And notice the skills centered around a project.

Programmers ultimately are builders and we use building terminology to talk about our work. Reframing your identity as a builder, rather than a learner, may do you wonders in achieving your goals. Instead of framing your programmer journey around reading books and taking courses, you frame your journey around building things and supplementing your knowledge with books and courses. This simple reframe will move you to the fast track in achieving your goals.

Programmers are a diverse crowd. As someone who enjoys working with designers and empathizing with the end user, front-end development suits me. There are many areas in the universe of 'programming skills' that I do not know. When I started a web developer internship, I only knew HTML, CSS, and programming fundamentals. It was all I needed to start building things.

Common career wisdom is to "do what you are" (and there is a popular career book, called Do What You Are) so your specific programmer identity should be at the intersection of who you tend to be already and the identity you aspire to. What makes Atomic Habits such an amazing habit book: it's all about going with the grain of who you are.

If your true goal is to get a job as a programmer, you ought to design your goal specifically to build just enough skills so that someone will pay you to do it. Ways to work backwards from your aspirational identity: doing informational interviews, reading job applications for their top list of skill requirements, and doing mock interviews if you can.

Strategy #2: Make Programming a Daily Habit

Every action you take is a vote for the type of person you wish to become. No single instance will transform your beliefs, but as the votes build up, so does the evidence of your new identity.

--- Atomic Habits

I have a secret: Books on Code itself is an act of identity building. When I show up to write an article or a candid weekly email, I am casting a vote for myself as a programmer, a writer, and a little bit of an entrepreneur. I am still taken aback when I receive emails seeking my "expert" advice.

Books have frowned upon the phrase "fake it 'til you make it," but I find it empowering. If imposter syndrome is going to be there anyway, you might as well own it. I say to myself, "Yeah. I'm a total faker. But gosh darn it --- I'm going to walk the walk and fool everyone, including myself."

How do you fool yourself into thinking that you are a programmer? Atomic Habits points out a truly life-changing mind hack: if you take little actions in the name of that new identity, your subconscious will take notice.

The truth is this: we're not trying to change what your conscious mind thinks about who you are. You can call yourself a programmer all you want, but if your subconscious mind doesn't believe it, you can't truly become.

As Atomic Habits says, "The most practical way to change who you are is to change what you do." And so, what do you do? For a programmer, it's simple: you code every day.

The act of coding is one of the most crucial votes you must take for your identity. I receive emails from people who feel stuck in their endless books and courses --- certainly not feeling like they can call themselves programmers.

Programmers program. Get rid of your imposter syndrome by opening that dusty text editor or IDE. Get rid of the other metrics, like how much you do not know. Programming is programming. Don't overthink it.

Sometimes, it's easier to grasp this concept by framing it in a different context. Consider these other votes you can cast for different identities:

Each time you write a page, you are a writer.\
Each time you practice the violin, you are a musician.\
Each time you start a workout, you are an athlete.\
Each time you encourage your employees, you are a leader.

Each time you code, you are a programmer.

Atomic Habits also encourages being kind to yourself. When casting votes for yourself with identity-shaping habits, keep this in mind:

The good news is that you don't need to be perfect. In any election, there are going to be votes for both sides. You don't need a unanimous vote to win an election; you just need a majority.

So cast your votes and be kind to yourself.

You are on your way.

Strategy #3: Make Programming Practice Simple and Rewarding

It's one thing for me to tell you to do a thing: "Program every day." But will you actually do it? Maybe not.

We can all agree what is good for us, but we don't all actually do what's good. In reality, we're antsy, bored children inside who don't like to take direction, including from ourselves.

So how do we talk to the child inside each of us? Atomic Habits offers two frameworks: the four-step pattern of habit formation and the Four Laws of Behavior Change.

First, the four-step pattern of habit formation. It goes like this: (1) Cue, (2) Craving, (3) Response, and (4) Reward. Habits require these things in order to be habits. For example, hunger is always triggered by an (often subconscious) cue, like an apple in a bowl on the kitchen counter. It forms in the consciousness as a craving. Then we 'respond' by eating the apple. And we are rewarded with the sweet, crunchy taste.

When we try to form a habit, we fail when we rely on willpower . We are wired for immediate satisfaction, and yet most good things do not have that intrinsically.

The Four Laws of Behavior Change mitigate this problem. These are criteria you can implement into every habit you want to have:

Make it obvious
Make it attractive
Make it easy
Make it satisfying

Making it obvious is setting up the 'cue' response. For example, if you set up a reminder with your home virtual assistant, or if you leave a coding textbook where you're sure to find it in the afternoon, you are 'cued' to take the action.

I titled my strategy "Make it easy and satisfying" because I think those are the bigger challenges in forming a coding habit. We tend to overcomplicate things and be harder on ourselves than we need to be. The labor of deciding what to work on may make the habit complicated. Taking on projects that are overly ambitious might make the habit hard and not satisfying.

Whenever I want to build a new habit, I try to focus on easiness. I know the kid self inside me is lazy. She will fight me on a bad day. So I need to build an argument for my future self so that she can't say no. The "five minutes" strategy is great. Tell yourself that you only have to do it for five minutes --- or even less. Just two minutes. You can have the project already open or pre-planned. Perhaps your coding for the day is just following along with a tutorial (but actually following along; not watching a video) or doing exercises on FreeCodeCamp. Be kind to your future self and remove the guess work.

I have a phrase I tell myself. My present self is smart. My future self isn't. I do not expect my future self to behave or to anticipate edge cases. It's up to me to anticipate them now, so that when my future self fails, I have taken care of her.

And of course, you need to make your habit rewarding. Make sure you are giving yourself something with the right amount of challenge. Give yourself milestones to celebrate and ways to celebrate them. We are reward machines, so give yourself a daily treat after coding. I am a big fan of matcha, so I promise myself I make a latte after a coding session. I like matcha for its identity vote --- for the health conscious, mindful, and rejuvenated version of me.

Expecting human error is thinking like a programmer.

Creating a reward response is just being smart.

We're programmers, so we ought to program our subconscious.

If you take these strategies to heart, I guarantee you that you will get closer to your goal of becoming a programmer. The journey is hard, but it can be made easier with good habits built through the right mindset.

Also know that I am here for you on your journey. If you want to stick around, feel free to join my email list at Books on Code or to sign up for my free email course How to Get the Most From Technical Books. We're sure to have lots of fun.

Also, if you have been sold on Atomic Habits, which can help you form better habits everywhere in your life, you can find an inexpensive copy on Amazon.

As always, I appreciate the time you spend learning and sharing with me. I look forward to seeing you in the next article. 👋😊

3 Coping Strategies for Programmers in Quarantine

Miranda — Mon, 30 Mar 2020 18:46:56 +0000

Originally published from Books on Code

When something like a personal crisis or a global pandemic such as the notorious coronavirus (also known as COVID-19) occurs, a war is waged on our concentration.

In quarantine, we are in a state of survival. Our timeline is narrowed. Instead of thinking about the future in months or years, we think days or weeks. The near future is so unknown that looking at next week feels like looking at next year.

This rapid shift in perspective can make working on long-term projects feel very, very difficult. Our mind wants to focus on the needs of the immediate present --- food and shelter --- and yet our real livelihood comes from our slow, deliberate, project-driven craft of writing software. After all, programming is how we get paid.

Below, I describe three ways to shift your mindset during a personal crisis to get through it stronger than ever.

Coping Strategy #1: Take a Break from Professional Development. Instead, Find Comfort in Your Space.

At Books on Code, I recommend reading books about programming. I encourage investing in yourself and bringing your career to new heights. But in unique cases such as a personal crisis, I encourage slowing that down.

If you are like me, suddenly being home always and 100% remote, you find yourself with a radical life change. It is unfair to expect yourself to maintain the same level of concentration and productivity as you did before. For me, this meant studying and maintaining Books on Code. We are learning a new way of living, and so we are taxing our minds more than normal.

We may not be as in the mindset for professional investment as we once were, but I understand the urge to try to push yourself to remain on the same trajectory for 2020 as you were before. I give you permission to let go and shift your focus to self care.

Instead, we need to take an introspective approach and truly realize the space we are in right now.

Being home so regularly has allowed me to form a new relationship with what it means to be 'home.' I need to respect the space I am in all the time, because I must like being in it. I have no alternative. I now think mindfully and deliberately about regular, everyday activities such as cooking meals, cleaning, walking my dog, and doing at-home workouts.

There has never been a better time to slow down, get introspective, and appreciate the little moments.

This is an opportunity for mindfulness and gratitude.

An opportunity to enjoy your meals, the morning sun, the crisp air, and the stillness.

It's a unique opportunity.

Coping Strategy #2: Shift Your Mindset for a New Economy

A concern I hear often is from junior developers in the middle of a job search when the pandemic occurred. Scheduled interviews vanished from the calendar. Instead of a hiring boom, there's layoffs.

Have we went from a buyer's market to a seller's market, just like that? Just a second ago, companies could not hire fast enough.

Those looking for a career change into development are wondering if they should pause their job search.

The general professional answer is always the same: don't pause. If you stop looking for opportunities, then you won't find them. The only big expense you are making in your search is in your time and the emotional vulnerability you feel. Don't let that nagging voice stop you. Persevere!

My recommendation: adjust your expectations and stay resilient. Whatever timeline you had in mind to find a job, relax those expectations and let the pressure off.

Also, keep in mind that a new economy is emerging. While there are industries that are severely hurting, there are other businesses that are booming. Shift your perspective to think about the industries that are suddenly drowning in demand for their services. They probably need someone like you.

When the crisis passes and our economy bounces back, I can't imagine our markets will return in the same way. The sudden demand to offer services remotely expedited an eventual trend. Once we see the power of all we are able to do remotely, life in-person is bound to alter.

Coping Strategy #3: Define your "Good Enough For Now"

Figure out exactly what you need to do to make your days successful. But "successful" needs to be redefined. By "successful," I mean "sufficient."

As the book Designing Your Work Life recommends, define what is "good enough for now". You may have already experienced this: many of your struggles and pains have shrunk away now that other worries have taken precedence.

You have many pains in your personal life and career that have been complaints for a long time --- things that "could be better", but sometimes it's optimal to forget that metric and focus on a different one: what is "good enough."

If what you have is working well enough currently, now is not the time to tinker with it. Instead, have gratitude for what works: a life raft that floats is a thousand times better than one that doesn't.

Define what is sufficient and be happy with it. Not for forever. Just for now. There is so much that is working --- and we have built so many skills that can sustain us --- so allowing some aspects of our life to 'just run' without tinkering is refreshing, and we can be pleasantly surprised how nice of a life raft we built for ourselves already.

There you have it. I hope these three coping strategies help you as you navigate this terrain. We are in a strange time at work. The ultimate message is to be more forgiving toward yourself, as we all need to be.

If you liked this article, please share it. And feel free to sign up to receive my Books on Code newsletter below.

I will see you next time. 👋😊

How I Became a Beginner Again (An Imposter Syndrome Story)

Miranda — Mon, 09 Mar 2020 18:48:31 +0000

I walked into an interview blind.

At the marketing agency, I thought we were going to be talking about writing.

I had a fresh degree in English literature and a year on my resume writing copy for enterprise software companies.

My interviewers saw my soul — the HTML, CSS, and computer science courses — my secret side projects, and my self-talk that I was not smart enough to be a professional. At this agency, developers decided they liked me enough to train me.

I walked out of the interview with an offer to start as a web developer intern. I packed my bags and moved immediately.

A few months turned into a few years, and I never had so much fun, growing from intern to full-time lead and perfecting my craft from project to project.

But when it came time to move on, something happened: I was scared.

When I went out into the world, outside of the safe haven of my agency, I struggled selling myself. Scathing technical interviews and massive lists of technical requirements scrambled my mind. In an instant, I was a beginner again, and the great investment I and others made had melted away in my mind to become a developer again.

This fear changed my path. I went back to writing — something I knew that I could confidently do.

And this is where I have remained.

Just last Fall, I was in the middle of taking yet another computer science course, wondering when I was going to finally reach the professional threshold in my mind.

During this time, I bought my first home with my partner of ten years. When I missed class on moving day, my professor mistook me for a freshly-graduated high school student. He told me I was in the real world now and warned me against slacking again.

I wondered what brought me here — to yet another class and to being 19 again.

When will I be good enough? I kept wondering. And then, it hit me: I am good enough right now.

That is why this year I have started Books on Code -- to renew myself as a developer, to soak in the world, and to contribute in a way I am uniquely qualified to do.

Imposter syndrome — that fear of never being able to earn our place or of not being smart enough — has been the most insidious blocker in my life.

I got here by others believing in me.
Now it’s time for me to believe in myself.

Thank you for reading this short post.

If you like, follow me on my journey! Sign up for my newsletter on Books on Code, where I send weekly motivational letters, or find me on Twitter.

Let’s conquer imposter syndrome together.

3 Must-Know Differences: Eloquent Javascript 2nd Edition vs 3rd Edition

Miranda — Mon, 09 Mar 2020 17:51:35 +0000

Republished from Books on Code

Eloquent Javascript 3rd edition has made quite a name for itself. It's free. It's eloquent (I mean, it's in the title), and it's a best seller despite being free.

But Eloquent Javascript has humble roots. Its 1st and 2nd editions were important predecessors before Eloquent Javascript launched into super stardom as the best book for Javascript programmers in 2020.

As someone who scavenges the internet for the best programming books, not a day goes by where I don't hear about Eloquent Javascript.

But some of us hopped on the bandwagon early, having read the 2nd edition and not sure if the 3rd edition is worth it. Maybe some of us have inexpensive access to 2nd edition print book, wondering if that's a suitable edition to read.

Well, I got all the details for you. Today, you're learning the differences between Eloquent Javascript 3rd edition and 2nd edition. Be fully informed and know the play-by-play: Eloquent Javascript 2nd edition vs 3rd edition style.

Overview

Eloquent Javascript 3rd edition is widely considered one of the best books on Javascript. Released at the end of 2018, the book is still touted as the best Javascript book, even in 2020.

Amazon reviews of the title state the following:

Eloquent JavaScript is unlike so many of the educational materials out there. It is complete and thorough in a sense that few books or websites are.
If you have learned JavaScript basics but want to go deeper then I recommend this book. I think this book would benefit anyone who isn't a total expert or a total beginner.
This book is a delight. Reading it is like a warm cup of tea on a cold winter day. The way the ideas are presented is very clear and dare I say, 'Eloquent'.

Eloquent Javascript 3rd edition covers a rare territory: it is not for complete beginners. It can benefit programmers who have been coding for years. In a market saturated with programming books for beginners, Eloquent Javascript is refreshing. It gets you to think deeper about the "why" and re-kindles excitement for the craft.

"Like a warm cup of tea on a cold winter day," reading Eloquent Javascript is like cracking open a magical spell book. The typography and illustrations are elegant and classic, with some old-timey enchantment to them. The book gives its reader the feeling that the craft of coding is magical and worth knowing well.

Even though the book is 100% free to read online, Eloquent Javascript 3rd edition is the #1 bestseller in Javascript programming on Amazon.

3 Differences: Eloquent Javascript 2nd Edition vs 3rd Edition

Before diving into the big differences between Eloquent Javascript 3rd edition and 2nd edition, you may wonder what is the same. If you read the 2nd edition, you will find that the structure, including chapters and sections, are nearly-identical, with whole swaths of conceptual paragraphs unchanged.

The order of chapters and the chapters titles are the same, with some minute differences. For example, the 2nd edition has two separate chapters for HTTP and forms, whereas in Eloquent Javascript 3rd edition, the two chapters are combined. For this article, I do not intend to focus on the small differences, but the bigger, high-impact ones.

Difference 1: Eloquent Javascript 2nd Edition Does Not Cover ES6

In the introduction of both Eloquent Javascript 3rd edition and 2nd edition, you find a detailed history of Javascript. Because the 2nd edition of Javascript was released in 2014, that pre-dates the release of Javascript's major update, ECMAScript 2015 or ES6.

The introduction of Eloquent Javascript 2nd edition says:

Changing a living, widely used language in such a radical way turned out to be politically difficult, and work on the version 4 was abandoned in 2008, leading to the much less ambitious version 5 coming out in 2009. We're now at the point where all major browsers support version 5, which is the language version that this book will be focusing on. A version 6 is in the process of being finalized, and some browsers are starting to support new features from this version.

But the introduction of Eloquent Javascript 3rd edition says:

Changing a living, widely used language in such a radical way turned out to be politically difficult, and work on the version 4 was abandoned in 2008, leading to a much less ambitious version 5, which made only some uncontroversial improvements, coming out in 2009. Then in 2015 version 6 came out, a major update that included some of the ideas planned for version 4. Since then we've had new, small updates every year.

The fact that the language is evolving means that browsers have to constantly keep up, and if you're using an older browser, it may not support every feature. The language designers are careful to not make any changes that could break existing programs, so new browsers can still run old programs. In this book, I'm using the 2017 version of JavaScript.

In these contrasting quotes, I intentionally left some overlap to show that some of the language has not changed from one book to the other. If you are a fan of the original, you will find much has not changed. For example, the introductions between versions are nearly identical, with the same sections: "On Programming," "Why Language Matters," and so on. The illustration has changed, as has the opening paragraphs.

Though the editions have many similarities, it is worth investing in Eloquent Javascript 3rd edition for one big reason: we need to know ES6 features as modern Javascript developers. The industry, and the browsers themselves, demand this change. Though the book structure is the same, reading the book in the context of 2017 ECMAscript is worth the time investment of reading a newer edition.

And if you are concerned about it being ECMAscript 2017, which is soon-to-be 3 years old, feel safe knowing that the major update was in 2015. ECMAscript releases annually, making catch-up easy. Once you understand the major features, you can look up release notes or articles to brush up on the new features.

Difference 2: Eloquent Javascript 3rd Edition is Better Written

What do I mean by better written?

The 3rd edition book cuts needless words and simplifies language. The writing is tighter and with a sharper eye toward technical writing. In my free email course on Getting the Most From Technical Books, I advice to "read only good technical books," but "good" can often be hard to define.

Good technical writing removes all ambiguity. Good technical writing is simple and easy to understand. Good technical writing does everything it can to remove barriers to understanding. That means good technical writing digests the materials and presents them well. It never makes you feel stupid, which I also talk about in How to Read Programming Books.

Eloquent Javascript 3rd edition has better technical writing than in the 2nd edition.

For example, the book is more conscientious about conceptual information by putting definitions in italics and defining terms immediately and in simple terms.

The 3rd edition also uses shorter sentences and few complex sentences, which improves readability.

To see this for yourself, observe the first paragraph of Eloquent Javascript 2nd edition:

This is a book about getting computers to do what you want them to do. Computers are about as common as screwdrivers today, but they contain a lot more hidden complexity and thus are harder to operate and understand. To many, they remain alien, slightly threatening things.

And the first paragraph of Eloquent Javascript 3rd edition:

This is a book about instructing computers. Computers are about as common as screwdrivers today, but they are quite a bit more complex, and making them do what you want them to do isn't always easy.

You can see that the paragraphs are the same, but revised.

Here are a handful of choices made in this first paragraph:

Instead of the wordy "getting computers to do what you want them to do," it is simply "instructing computers." Brilliant.
The 2nd edition uses the trite word "thus," which is removed.
Bigger phrases like "hidden complexity" is swapped for "are quite a bit more complex." This is easier to conceptualize, as "hidden complexity" is a loaded phrase.
The 2nd edition uses the phrase "they remain alien," which is removed in the 3rd edition. The word "alien" has many dictionary definitions, which can be hard on non-native English speakers. The choice to remove that phrase is smart.

The first paragraph is perhaps the most important cluster of words in a book. In the first paragraph alone, the many tiny choices are smart, which sets the scene for the rest.

Difference 3: Eloquent Javascript 3rd Edition Has a New Project

In Eloquent Javascript 3rd editions, one of the projects from the 2nd edition was scrapped ("Electronic Life") and replaced with a new project called "A Robot."

You may be thinking that "Electronic Life" sounds like a synonym for "A Robot," but trust me --- the projects are different. This new one is about graphs and Dijkstra's algorithm, whereas the 2nd edition exercised focused on a two-by-two grid.

Also, this new project is more advanced and more challenging.

Here is the description of the "A Robot' project in Eloquent Javascript 3rd edition:

Our project in this chapter is to build an automaton, a little program that performs a task in a virtual world. Our automaton will be a mail-delivery robot picking up and dropping off parcels.

And here is the description of the "Electronic Life" project in Eloquent Javascript 2nd edition:

Our project in this chapter is to build a virtual ecosystem, a little world populated with critters that move around and struggle for survival.

The project description of the 2nd edition may sound familiar to you. Having taken a number of programming classes, I have done the "Electronic Life" project twice already, which I know as the "Game of Life."

But I have not heard of the mail-delivery robot project. Immediately, I am more intrigued. This is not an out-of-the-box computer science course assignment.

The "A Robot" project comes with an adorable map where your robot makes deliveries.

The "A Robot" project does not disappoint. It presents you with a 16-bit map of buildings along with an array called roads. Each item in the array contains a string: a building + " - " another building. The assignment also provides additional code to parse the array into more useful data.

The fun part is the assignment: get the robot to decide on the best route to make its deliveries. It's a good assignment that uses principles learned in data science & algorithms classes. I highly recommend the book, Grokking Algorithms. Chapter 7 of Grokking Algorithms details Dijkstra's algorithm. This could be good supplemental material for the exercise.

Conclusion

As you can see, Eloquent Javascript 3rd edition is a worthy and much-needed update to the popular programming book. The fact that the book covers ES6 is worth a re-read, but the new edition goes above and beyond with new illustrations, a new exercise, and tighter writing. The 3rd edition of the book is substantially improved from its predecessors and worthy of the hype.

If you're interested in reading Eloquent Javascript 3rd edition, you can get it for free online or support the author by purchasing the print book on Amazon. Also, No-Starch Press is an amazing publisher. They are leading the industry with quality and fun titles on programming. Supporting them is supporting quality programming publications, and who doesn't want that?

If you liked this article, be sure to share it with fellow Javascript programmers and sign up for the Books on Code email newsletter to get weekly inspirational updates on books and on learning.

With that, I will see you in the next article. 👋😊

7 Effective Steps to Cracking the Code Interview

Miranda — Tue, 03 Mar 2020 05:27:13 +0000

Originally published from Books on Code

There is a reason programmers are prone to imposter syndrome. Failing a technical whiteboard coding interview can be one of the most sobering experiences alive.

Getting tested on data structures & algorithms, taught to you by a dull lecturer years ago, is the foundation of the test. Yet the test is absolutely brutal.

A failed test -- or several -- can cause you to question your self worth as a programmer. But don't.

I am here to tell you that a test is all the coding interview is, and to crack it, you need to study to pass the test.

This is our own version of the Bar exam for US lawyers or the Fundamentals of Engineering Exam (FE), only we get no credential and we are simply being measured against other candidates (which is a relief!). Engineers and lawyers who pass these exams study hard; they don't just rely on their experience. We should approach the coding interview the same way.

Studying successfully to pass this popularly-used whiteboarding coding interview will get you the software engineering job at a top software company, so making the investment in studying is one of the best you can make.

Overview

The seven steps below are based on the popular book, Cracking the Coding Interview, now in its 6th edition. This well-regarded book is monolithic in size and intimidating: 17 thick chapters of grueling interviewing questions as well as additional advice: how to behave during interviews, think about Big O notation, and how to handle offers and rejections.

This book is your friend -- someone to laugh with and cry with over wine, a movie, and a cheap box of chocolates. It's the book you hug in victory as you run up the steps from Rocky, having successfully completed your training.

What this book has to offer is hard work and big rewards.

The advice in this book is coming from Gayle Laakmann McDowell, someone who has seen it all as a software engineer and interviewer at Google. She knows the pitfalls software engineers commonly fall into. She serves as a guide, climbing treacherous and deadly terrain. Listening to her advice is clinging to your liveliness as a software engineer.

7 Steps to Cracking the Coding Interview

I'm excited for you and for the skills you are going to develop. Thorough preparation will give you a wide range of technical and communication skills. It will be well worth it, no matter where the effort takes you.

--- Foreword, Cracking the Coding Interview

Step 1: Practice on Paper

We are spoiled by IDEs, Google searches, and autocomplete. It's possible you have typed a command hundreds or even thousands of times, but when at a plain text editor, a piece of paper, or a whiteboard, you draw a complete blank. When you're on a whiteboard, you have no mental crutch.

This is normal and one of the main pitfalls that makes these exams so challenging.

Cracking the Coding Interview has several recommendations around training your mind for paper when solving problems:

Write the code on paper. Coding on a computer offers luxuries such as syntax highlighting, code completion, and quick debugging. Coding on paper does not. Get used to this --- and to how slow it is to write and edit code --- by coding on paper.

Test your code --- on paper. This means testing the general cases, base cases, error cases, and so on. You'll need to do this during your interview, so it's best to practice this in advance.

Type your paper code as-is into a computer. You will probably make a bunch of mistakes. Start a list of all the errors you make so that you can keep these in mind during the actual interview.

Are you squirming in your seat right now? I know I am. It's crazy to think that we can or must code on paper in order to excel in our careers.

As a mind hack, you can get in the mood of coding on paper by choosing a distinctly separate and delightful place to practice your coding. Splurge on a favorite pen. Light a candle. Brew your favorite hot beverage. Then, think about how nice it is that you get to practice code while away from your computer.

I want to emphasize the last tip, Type your paper code as-is. This is a crucial step. Studies have shown that when we make a guess, check ourselves, and get it wrong, we learn from the mistake and learn faster.

Getting it wrong is one of the best ways to learn.

Throwing ourselves into these problems cold, writing our answers on paper, and being willing to face everything about how wrong we were will put us in the absolute best place for when we face the real interview.

Step 2: Do Mock Interviews

Heed my words: do not skip out on this absolutely crucial step to cracking the code interview.

I'm serious. If you ever think of not doing mock interviews before the real deal (out of fear --- fear of asking your friends or fear of failure), imagine Mr. Resetti, the mole from Animal Crossing, not letting you get away from this.

Recite to Mr. Resetti now: "I will do mock interviews." He doesn't believe you. Say it again.

Now let's look at what Cracking the Code Interview has to say about this:

In addition, try to do as many mock interviews as possible. You and a friend can take turns giving each other mock interviews. Though your friend may not be an expert interviewer, he or she may still be able to walk you through a coding or algorithm problem. You'll also learn a lot by experiencing what it is like to be an interviewer.

Offering to give and receive coding interviews is a great way to help prepare. Reach out to your network. Remember that asking for a mock interview is not selfish. Friends who give or receive tests benefit as well.

If you don't have friends to do mock interviews with, you can turn to the internet. Pramp.com is a free service that pairs you with other programmers to conduct practice coding interviews.

Step 3: Listen to Every Detail

When in your mock interviews (and later, in the real interviews), practice your attentive listening.

Coding interviews are interactive --- an exchange between the interviewer and interviewee. As such, you need to pay attention. Your active listening reveals the intelligence and inquisitiveness they are looking for.

When listening to a problem, you need to pay attention to all of the details. This is like gathering the ingredients to a recipe: you're not using it all in the first step.

When you listen to a problem, you need to be absolutely certain you heard it correctly so that you are not off to the races solving the wrong problem. Ask questions. Repeat it back. Asking for clarification is encouraged.

It is unlikely that the interviewer will give you information that does not relate to the problem.

Cracking the Coding Interview says:

Many candidates will hear the problem correctly. But ten minutes into developing an algorithm, some of the key details of the problem have been forgotten. Now they are in a situation where they actually can't solve the problem optimally.

If you find yourself stuck, ask yourself if you used all of the information in the problem.

But also, if you find you are not using some of the details in your first draft of the solution, don't worry. A necessary step to problem solving is just having a solution --- even if there's some problems with it to start. Your interviewer would understand that you are actively problem solving.

Step 4: Draw a Specific and Sufficiently Large Example

In your mock interviews, as every first step to solving your problem, you need to draw an example. The author of Cracking the Coding Interview cautions that interviewees commonly draw bad examples.

What is a bad example? They are too small and do not sufficiently convey a common case for the problem scenario.

The book illustrates a tree with only two branches: three cells in total. That tree is not sufficient for the problem space.

It is also possible for you to draw an example that later turns out isn't quite right.

But in a technical interview, everything can be adjusted. Go back and fix your example.

Step 5: Design an Algorithm and Optimize

Before you write code in your coding interview, you need to design your algorithm based on your example. And here's where you need to start: you just do it.

Start, even if your algorithm is terrible.

Start, even if your algorithm is so obvious that surely the interviewer will think you're an idiot.

Just do it. A solution --- even a bad one --- is a place to start.

And once you have it in place, you can speak aloud what you're thinking: the ways it is not optimized. And you have a place to move forward and you've taken a step toward wrapping your mind around the problem.

Cracking the Coding Interview has several suggestions to improving your algorithm. These are among my favorites:

Look for any unused information. Did your interviewer tell you that the array was sorted? How can you leverage that information?

Use a fresh example. Sometimes just seeing a different example will unclog your mind or help you see a pattern in the problem.

Use a hash table. Hash tables are widely used in interview questions and should be at the top of your mind.

Step 6: Write Beautiful Code

In order to write beautiful code during your mock or real coding interview, you need to know your algorithm well.

When you have your algorithm planned, you do not need to jump straight into coding. You can take a second to plan the code and to understand exactly all of the steps. Know what the variables are as well as where and when they are going to change.

Cracking the Coding Interview cautions: "Whiteboard coding is slow---very slow. ... If you don't understand exactly what you're about to write, you'll struggle to code it."

To write beautiful code, you are facing the challenge of the board, your own handwriting, and your own neatness --- oh boy. Simple precautions you can take is to give yourself plenty of room and be cautious about writing straight lines.

But beautiful code isn't just how it looks on the whiteboard. Beautiful code is modularized, with error checks, uses other classes and structures, and has good variable names. You can do it.

Step 7: Test Your Code

Once you make your best attempt at writing beautiful code, you are not done! The final step is to 'run' the code and 'debug' the errors using the power of your own brain.

Cracking the Coding Interview warns this is a major pitfall for many interviewers, because running a test by hand takes a long time --- too long. The interview will be over before you have solved the major bugs in your code.

So what then? Cracking the Coding Interview recommends taking a faster approach by first reading the code line-by-line, explaining what each line of code does to the interviewer. Check to see the code is doing what you think it ought to do.

Next, scrutinize any part of your code that looks odd to you. Did you make choices that are not obvious in the code?

Next, check spots prone to error. If you have coded for a long time, you will know where these places are.

Next, actually test with a small test case.

Next, test special cases, such as null or extreme cases.

Finally, when fixing the errors you find, take a second to analyze why the bug occurred and ensure your fix was actually a fix.

Conclusion

Now that you reached the end of these 7 steps, do you feel ready to crack the code interview?

I know. It's like drinking from a firehose.

But there are resources out there to study and gain more confidence. You can find live coding interviews posted on YouTube to see what coding interviews are really like. You can refresh on your data structures & algorithms by watching lectures, reading books (which, I recommend Grokking Algorithms), or taking an inexpensive online class.

If you liked this article, share it with the programmers in your life. Use it as a way to break the ice and start doing mock interviews together.

The life of a programmer can be hard sometimes, but you have the support of a community who live and breath the lifestyle of learning and continuous improvement.

If you want to join me on this journey to improvement through code, join the Books on Code newsletter and receive motivational updates about the coding and learning journey.

And with that, I will see you in the next article. 👋😊