Musk’s purchase of Twitter in 2022 marked a new direction for the platform, and - either in response, or by coincidence - two new players shot up soon after; Bluesky and the meta-owned Threads.

These three primarily text-based platforms offer competing visions for how social media should be, and in this article I’ll consider what this all means now and for the future of the web, and society more generally.

X: Pay-to-Play

Moving Fast and Breaking Everything

After Elon Musk took charge of Twitter in 2022, it underwent a massive transformation. While the name change - from the recognisable Twitter to literally just a random letter from the alphabet - might seem like a big change, it saw bigger changes in its internal structure and the features in the app itself.

Musk’s approach is what I would describe as ultra-capitalist, built on free-market principals, based on the belief that private, for-profit organisations will be the most efficient and innovative players in any competitive marketplace, and that regulation and employment protections are unnecessary red tape that slow down technological progress and growth.

With this in mind, after taking charge he immediately cut huge chunks of the Twitter (or X, let’s go with that) workforce, and vowed to cut down on the bots on the site by making users pay for features, in effect verifying themselves as human through the payment process.

Free Speech Absolutism

Musk is a self-proclaimed free speech absolutist, suggesting any attempts to discourage freedom of speech is an attempt to censor the speaker (we’ll get to that later), and in the months following his purchase he re-instated the accounts of several high-profile people who had been banned from the platform by its old ownership, including alleged sex trafficker Andrew Tate and controversial US president Donald Trump. Musk’s reasoning - if you can call it that - was that while they are controversial, they should not be excluded from the conversation.

At this point, Musk was effectively telling X users that content will no longer be moderated, or that content that would have been removed in the past for being racist, homophobic, or pure dis/misinformation is now fine to share. For a free speech absolutist, this is fine, right?

Advertisers did not agree.

Huge corporations began withdrawing their dollars from the platform, keen to ensure their brands’ ads were not presented to users on the timeline alongside hateful or controversial content.

Disney, Apple, IBM, Sony and many others all withdrew, equating to hundreds of millions of lost revenue for the platform.

Musk’s response? Try a new monetisation strategy, and get users to pay for the privilege of having their content seen by others.

Monetisation

What once operated as a free and open forum for public discourse now revolves around monetisation and algorithmic visibility. X’s premium plans, X Premium and X Premium+, increase post visibility, offering paying users an advantage over those using the free tier.

Got money? Get ahead. Sounds pretty capitalistic, to me.

Users are now referred to as Creators, and can also receive ad revenue shares if they meet an engagement threshold, effectively monetising their ability to engage others, or their popularity.

X’s transition to a marketplace-style model goes beyond user interactions. Twitter’s API had a generous free tier, and users were encouraged to build third-party tools on top of the platform, to extend its features. When Musk came in, this got shut down quickly.

Now, the platform’s API costs a frankly ridiculous $42,000 per month. This effectively priced out researchers, developers, and smaller organisations that once relied on its data to build tools or study trends​, locking down both the data and the features of the app itself.

Grok and Generative AI

Next, let’s consider Grok, X’s generative-AI. Without getting in to technical specifics, the key difference between Grok and other well-known gen AI tools is Grok is less restrictive in terms of what it will let you generate.

For example, in the run up to the US election, Grok was used to create less-than-flattering images of politicians, images that ChatGPT or Claude would have blocked from being generated on ethical grounds. Again, Grok is designed to reflect Musk’s free speech absolutism, even if the images could potentially defame the character of the people featured in them.

All of these features and strategies reflects Musk's broader vision of the internet as a capitalist ecosystem. In this world, influence is a commodity, everything is a transaction, and visibility comes at a price.

While some argue this model incentivises creators and reduces reliance on advertising partners, critics note that it creates a two-tiered system where those that can pay can play. Those that cannot pay just get to sit and watch.

Bluesky and Mastodon

Ownership Matters

Unless you’ve been living under a rock, you’ve probably been hearing a lot about Threads, Bluesky and Mastodon recently. After Musk’s controversial role in the re-election of Donald Trump, millions of users worldwide began leaving X to join alternative platforms better suited to their own beliefs about either politics, or how the web should work.

Threads is perhaps the best known of the alternatives on offer, created by Mark Zuckerberg’s Meta (the parent company of Facebook) and launched in 2023.

Bluesky was quietly launched much earlier, in 2019, by its creator, the founder and then-boss of Twitter, Jack Dorsey.

Lastly, Mastodon, a non-commercial, privacy-focused, open source alternative started back in 2016, ironically because its created was dissatisfied at where Twitter was heading at the time.

All three have different models of ownership, and this matters. Threads is of course owned by one of the largest companies on earth, Bluesky is owned by software engineer Jay Graber, and Mastodon is decentralised in that no single individual can claim ownership.

As we’ve seen with X, when ownership is consolidated to one person (or a very small group of people), the app can change direction on the whim of its owner, sometimes in directions that its users don’t necessary like.

Algorithms and APIs

While X is heavily criticised for the way its algorithm seems strangely aligned with interests of Musk (ie amplifying right wing voices, flooding Grok news with Tesla and SpaceX stories, hiding content that he does not agree with), these tools all approach algorithms quite differently.

Threads, with its consolidated ownership, applies a one-size-fits-all algorithm. Bluesky - built on Authenticated Transfer Protocol (AT Protocol), a decentralised framework designed to give power back to users - allows individuals to choose or even create algorithms tailored to their preferences. Mastodon simplifies the entire thing, to essentially just display content in chronological order.

All three platforms have free-to-use APIs, encouraging the community to build tools, features, or (in the case of Bluesky and Mastodon) entirely new platforms on top.

This openness contrasts sharply with X’s restricted API and closed systems.

Philosophically, Bluesky represents a belief in the internet as a democratised space, where users retain control over their data. With data being as valuable commodity as it is, its refreshing to find a platform take this approach.

Importantly, while all three are competitors, they’re in some ways designed to co-exist alongside one another, with shared technology and the Fediverse making it easy for users to connect their accounts across platforms. Again, a very different approach to the one taken by X.

Threads: Sitting in the Middle

Threads, Meta’s entry into the microblogging space, occupies a middle ground between X’s ultra-capitalist ethos, Bluesky’s open-source approach, and Mastodon’s decentralised ideals.

Originally launched as an extension of Instagram, Threads cleverly positioned itself to attract users disillusioned with X in the early days of Musk’s takeover.

Its tight integration with Meta’s ecosystem meant users could seamlessly port their account across from Insta to Threads. This was helpful, but also underscores the platform’s centralised nature and the data they hold on users.

Meta’s approach to monetisation in Threads has been more cautious - at least for now. Unlike X, Threads does not yet offer premium subscriptions or ad revenue sharing. However, Meta’s business model is historically rooted in data collection and targeted advertising, raising concerns about privacy and user autonomy as well as what Threads might look like in the near future.

Scandals like Cambridge Analytica - where millions of Facebook users’ data was harvested without consent and used to influence the 2016 US election - highlight the risks of entrusting Meta - or any corporation for that matter - with your personal information​, so the jury is out on this one, for now.

What Will the Web Look Like in Future?

The divergence between X and Bluesky, Mastodon and Threads reveals more than just differing business strategies; it highlights conflicting ideologies about the internet’s purpose and future.

X’s pay-to-play model envisions the internet as a marketplace where visibility, influence, and access are commodities. This approach rewards those who can invest financially in their presence while sidelining those who cannot, further widening the gap between the haves and have-nots.]

Threads may, for now, paint a picture of a more open web than the one envisioned by X, it still suggests the power would ultimately remain consolidated in the hands of some powerful corporations and individuals.

Bluesky and Mastadon’s open-source, decentralised vision offers hope for a more democratic internet if they can overcome the financial hurdles that will inevitable exist along the way.

For users, these platforms serve as a reminder that social media platforms are not neutral, and they impact both the web, and the real world.

The policies, algorithms, and business models they adopt reflect deeper values about what the web should be, and by examining them in this article, I hope you can make informed choices about the platforms you support.

If you enjoyed this article and want to see more content about development, design, creativity and learning, then follow me on:

• X: http://www.x.com/danielcranney

• Bluesky: https://bsky.app/profile/danielcranney.bsky.social

• Threads: https://www.threads.net/@daniel.cranney

• LinkedIn: https://www.linkedin.com/in/daniel-cranney/

If you'd like to see my work, check out danielcranney.com.

Do you really know what these words mean? Or, perhaps more importantly, do you need to know what they mean?

Before learning to code, I spent a decade working in education, primarily teaching filmmaking skills to media production degree students.

Video production and programming are different in many respects, but they have more in common than you might think. Both are incredibly technical pursuits, centered around problem-solving and—like any skills worth mastering—take years to perfect. Video production arguably demands a higher degree of creativity, but it requires less lateral thinking than debugging a complex code-related bug. While they’re similar, they diverge in key ways too.

Even so, both areas of expertise bring with them an entire glossary of terms for concepts, approaches, and technologies that the learner must understand alongside the hands-on skills they’re developing. As if learning to code (or to create video content) wasn’t complicated enough, this glossary of terms might just be making it harder.

My question is… does technical language, otherwise known as jargon, help or hinder us when we’re learning to code?

Why Technical Terms Exist

I should say upfront, I’m not opposed to all kinds of technical language. I know it’s not there just to make things sound more complex than they are or to make the person using it sound smarter (though it’s great for that, too).

Technical terms make communication precise.

Take the legal industry, for example. Legal professionals communicate almost entirely in technical language, so much so that it has its own name: legalese.

Similarly, the field of medicine is filled with long and complicated Greek and Latin-origin terms that often have quite literal meanings. Take the term gastroenteritis. Gastro comes from the Greek gaster, meaning belly. Entero comes from enteron, meaning intestine. The itis suffix means inflammation. If it’s just a word ‘created’ by putting origin words together, why not just call it "stomach and intestinal inflammation"?

Well, for a start, it’s more concise. Harder to understand in terms of meaning, sure, but definitely more concise, wrapping up a number of concepts into one (hard-to-decipher) word.

Secondly, it distinguishes the issue from other similar kinds of inflammation, making it more precise too.

Is Technical Language == Technical Knowledge?

Let’s stay focused on the field of medicine a little longer. We’ve accepted that technical terms are concise and precise, but these are only really beneficial for those using them.

In the case of medicine, this is the medical professional communicating with other professionals.

How about for the patient? When we hear professionals using technical language, do we assume they know more about the topic they’re discussing, even if we understand very little of what they’re saying?

In short, yes.

Michel Foucault, the French historian, author, and philosopher, wrote about how technical language shapes our interactions. He suggests that while it does legitimize expert opinions, it can also exclude others from participating in the conversation and subtly dictate their behavior.

In the case of medicine, it means we are more likely to take our doctors’ advice if they use technical language, even if we don’t understand the meaning of it.

Now let’s map this back onto the world of programming.

As a junior, you ask a couple of senior developers for help with an issue. They start discussing the problem between themselves and immediately switch to language you barely understand.

So, naturally, you zone out, unable to keep up, and mentally check out. You wait for the conversation to reach its conclusion and follow the advice they give you.

Did you learn anything new? I mean, you heard some new words, but you didn’t learn what they meant, so no, you didn’t learn much.

Now you might be asking yourself, is it so bad that the junior (or the patient, in the medical setting) is excluded from participating in the conversation? I mean, surely they should just leave it to the experts?

The issue with our programming scenario is that the power rests firmly with the seniors, who effectively speak in code (no pun intended!) to exclude someone with less knowledge from participating and, at the same time, deprive the junior of a valuable learning opportunity.

How to Use Jargon When Teaching Others

As a teacher, I quickly realised that overloading students with technical terms too early was counterproductive.

If I started talking about chromatic aberration or logarithmic profiles before they’d mastered the basics, I’d lose them. Instead, I’d allow them to learn visually and by getting their hands on equipment, then introduce the related terms once they’d experienced the technique, problem, or solution firsthand.

Only then could I reinforce this new kind of language, asking questions like, “X, could you explain how optical flow works to Y?”

If they first understood the concept in plain English, learning the terms afterward made them more concise and precise while still able to explain it to others in a jargon-free way, effectively passing on their knowledge.

Programming tends to flip that approach. Many technical articles, videos, and talks are so laden with terminology that you have to wade through abstract concepts and complex sentences just to make sense of what’s being said.

This can make programming feel more intimidating than it needs to be. But that doesn’t mean jargon is the enemy—it just means we need to use it wisely.

How to Find the Balance

The challenge, both in teaching and in programming, is finding the right balance. Technical terms are essential for precision, but they need to be introduced thoughtfully.

In filmmaking, I’d never skip over the term aperture just to keep things simple—it’s too important. Instead, I’d say, “This is the aperture—it’s like the pupil of your eye. It controls how much light gets in.”

A blend of plain language and technical terms made it easier for students to pick up the information, with the most capable students using the technical term immediately and less capable students opting to introduce it later.

The same approach works for programming. If I were explaining something like the event loop to someone new, I’d pair the technical term with a relatable analogy: “The event loop is like a to-do list for your code—it keeps checking what tasks need to be done next.” That way, they understand the concept without feeling overwhelmed, but they’re still learning the terminology.

Conclusion

In education, teaching in a way that makes the content accessible to different levels of student is called differentiation, and it’s something we don’t do well in the world of programming. By mixing technical language with plain language a little more, we can do our bit.

We need to meet people where they are, and make them feel included in the conversation, not excluded from it. Remember that you were where they are once.

Start with plain language to explain the what and why, then introduce technical terms when they’re ready, and never just to make yourself sound smart.

The key isn’t to avoid technical language - just make it a little more meaningful.

If you enjoyed this article and want to see more content about development, design, creativity and learning, then follow me on:

• X: http://www.x.com/danielcranney

• Bluesky: https://bsky.app/profile/danielcranney.bsky.social

• Threads: https://www.threads.net/@daniel.cranney

• LinkedIn: https://www.linkedin.com/in/daniel-cranney/

If you'd like to see my work, check out danielcranney.com.

As I've written about before in previous articles, learning is a complex process made up of multiple steps, and 'application' of what you’ve learned is only one of them. Believe it or not, even sleep helps you learn, so suffice it to say learning is far more complicated than it might appear, and you’re not even necessarily conscious that (or when) it’s happening.

With this in mind, it's important to remember that your success in learning to code isn't measured by how many lines you write each day, and you can still learn a great deal without even typing a word.

Some days it's difficult to find the physical or mental energy to sit down in front of your code editor and add new features to that project you've working on, or hammer out complicated logic, but it doesn't mean your learning has to stop.

In this article, I'll give you a number of ways you can continue on your learning journey and take significant steps forward, without writing a line of code.*

*Okay, you might write one or two, but you don’t have to.

📚 1. Read the docs

When I first started learning to code, it took me a while to really see the benefits of reading documentation. Sure, I’d heard people say ‘read the docs’, and would often see comments on StackOverflow linking to official documentation in what a seemed like an unhelpful alternative to actually trying to help the person solve the issue they needed a hand with. It turns out, they were actually trying to be helpful, I just didn't see it right away.

I used to skim over documentation when I first picked up new tech, but only really used it for reference, when I really had to. I just wanted to get stuck in to writing code. Reading docs would just slow me down... or so I thought.

In retrospect, I can't tell you how many times the solution to a problem I was struggling to solve was right there in the documentation... often on the first page. Had I taken more time to read the docs, I would've been more familiar with the concepts at hand, solved issues far more quickly, and written cleaner code all along.

I know reading documentation may not sound like the most exciting way to spend your time, but so many coding languages, frameworks and technologies have easy-to-digest docs that explain complex concepts in simple terms.

Whether you're troubleshooting issues with your code, getting to grips with something new, or levelling up with your chosen tech, don't skip over reading the docs.

🤓 2. Read other people’s code

Joining a version control site like GitHub, BitBucket or GitLab is a rite of passage for any developer, but these sites aren’t just handy places to store your code. Sure, when you first join, that's probably all you'll use them for, but these storage sites are treasure trove of code written with all kinds of languages, available for all to see.

Just like reading literary books is a great way to expand your vocabulary, you're guaranteed to expand your skills, and learn new terminology and techniques simply by taking the time to read some code written by somebody else every once in a while.

GitHub alone has literally tens of millions of codebases at your fingertips (themselves stating they have more than 83 million developers as members, and over 200 million public repositories, 43 million of which are public), ready for you to read, clone or fork, where you’re free to play around with it.

With such a staggering number of projects on GitHub and the alternatives listed above, there's a good chance somebody else has a solution to that tricky issue you just can't seem to solve, or taken a novel approach to a common problem, with the snippets available for you to use right out of the box.

In a world of SaaS subscription packages and paywalls for products that were once free, GitHub is a valuable resource that shouldn't be taken for granted. Take full advantage of it, try to pick it up early on, and immerse yourself in the code you find there.

💻 3. Read technical articles

We've all come across a blog or article in pursuit for a solution, but how often do you read articles just to learn something new? To be fair, if you're reading this article at all then there's a high likelihood you read tech blogs relatively often, so I won’t preach to the choir too much.

Just remember that tech blogs aren’t just there to help get you out of a sticky situation when you need it, but reading them is a great way to pick up tips and tricks for working with your chosen stack. While simply reading articles without any application of what you learn from them won't lead to particularly deep or meaningful learning, there's a good chance you'll pick up enough of the basics (or surface-level information) to recall it at a later date, and every little helps.

🎥 4. Find content that suits your learning style

Okay, I get it, advising you to 'go on YouTube' really isn’t that insightful, but it’s important that the content you consume to learn new things is actually doing what it's intended to do: help you learn.

Maybe you’re someone who likes to get stuck in to the nitty gritty syntax right away, copying what's on the screen until it starts to make sense, one puzzle piece at a time, or you like to ease into a subject with analogies and metaphors and a high-level overview rather than specifics, or on a simple level, benefit more visuals than audio (or vice-versa); choosing and using the right content is incredibly important.

Personally, I'm a big fan of Kyle from Web Dev Simplified with his jargon-lite explanations of complex concepts, and mixture of both long-form and and bite-sized lessons, but remember, the point is to find content that works for you.

🔖 5. Bookmark time-saving snippets

Tech Twitter has some amazing developers sharing tips tricks, cheat sheets and snippets on a daily basis.

If you’re like me and you appreciate clean, concise code then these accounts deliver little nuggets of code gold, without having to worry about a larger project surrounding it. Snippets are an amazing way to pick up tips and tricks; and taking the time to save some that you appreciate will help you solve problems you encounter in the future, guaranteed.

Snippets help you learn some of the finer details of coding at the same time as helping you to break out of old habits and routines as you add new tricks to your tool kit.

🕵️‍♂️ 6. Inspect sites you admire

Whether you're a developer or otherwise, most of us spend a significant portion of our day online. ... But everybody needs a break from coding every once in a while. Whatever you spend your time doing when you're not coding, there's plenty to be learned while you're doing it.

When you’re next online and get caught off-guard by an impressive-looking site or extraordinary feature, open up your developer tools and take a look at the source code. Is the HTML semantic? How did the developer do that fancy animation? How have they styled their components? What can you learn just by looking, because the answer is probably more than you think.

🔽 7. Download cheatsheets

Rarely a day goes by where I don't see a coding cheatsheet making the rounds of Twitter, and I often keep scrolling without looking too closely. Take the time to read them though, and you'll find some absolute gold.

Cheatsheets might not be enough on their own to make you a great coder, but they’re a great way to go over fundamentals, find shortcuts or pick up nifty one-line solutions. The time saved by using simple shortcuts compounds over time, so something relatively simple can radically transform your productivity and output.

🤔 8. Be critical of the UX/UI on sites that you use

The more you learn about UX, the more you realise that the best websites have carefully crafted UI’s that make a tool - and the process it facilitates - intuitive, and frictionless.

The next time you’re logging in to your online banking account, buying clothes online, or even navigating around this very site, be critical of its design and the impact this has on your experience as a user, positively and negatively.

Ask yourself some of these kinds of questions: How does the UI indicate an incorrect password was entered, or a product was added to the basket? How straightforward or complicated was onboarding? Was the checkout process slick and seamless, or slow and clumsy?

Save examples of food UX that you encounter in your bookmarks, it’s a simple way to remind yourself of good practice when the time comes for you to build similar features for yourself.

🙋‍♂️ 9. Ask questions

Even when we have the opportunity to learn from people more knowledgeable or experienced that ourselves, we often won't ask the questions we want to ask, for fear of looking stupid. Each time we pass up these opportunities, we’re missing a great chance to learn something new and be gifted with an answer that it would take far longer to learn for ourselves, through experience.

Join a community, whether it's Hashnode, Twitter, Reddit, GitHub projects or elsewhere, and speak to other developers to learn more about their approach, their mindset, their stack. These conversations might not seem like much, but experience matters, so you're guaranteed to learn a lot even when you're not expecting to.

🎓 10. Teach somebody else

Teaching somebody else, regardless of the topic, teaches you a lot about yourself, as the teacher. You become aware of where your knowledge on a given subject begins and ends (and where gaps exist), and have no choice but to synthesise potentially complex information into easy-to-understand parcels of information, free of inaccessible jargon.

Help those around you or in your social network, because by teaching others learn along the way you inevitable learn a lot for yourself.

To conclude

So often I'll hear developers talk as though the only way to learn to code is to stare at your code editor for hour after hour, and this simply isn't true.

Hopefully this article has given you a couple of ideas for how to keep the wheels turning even when those days hit where you don't have the time (or energy) to sit down and code.

If you can think of any other ways to learn without writing code, feel free to leave them in a comment below, or send them my way on Twitter.

If you enjoyed this article and want to see more content about development, design, creativity and learning, then follow me on Twitter at @danielcranney.

If you'd like to see my work, check out my portfolio at danielcranney.com.

If you'd like to support me to make more content, check out my BuyMeACoffee page.

I had worked with HTML and CSS since my teens (I'm 33, by the way...) and made websites with almost every CMS around, but I'd never ventured into full-blown programming; instead, I fell into the world of design. The pandemic was a tricky time in so many ways, but it gave me the time and space to finally explore something that had interested me for so long.

So, I committed to learning to code, and decided to make one of my ideas a reality; a simple tool that would help teachers write progress reports for students more quickly. I would build it as I went along. Each time I would learn something new, I would it into practice and add it to my project, in the hope that eventually it would be a fully functioning software-as-a-service tool (or SaaS), complete with a backend, authentication, subscriptions, a payment gateway, and more. It was ambitious, but gave me something to aim for.

It's 18 months since I started on this path, and I've just launched my SaaS, Reportr, into public beta, so now feels like the perfect time to look back on what the experience has taught me.

This article isn't just written for coders thinking about building their own SaaS, but rather for anybody considering learning to code, in the hope that my words might save others time and headache, regardless of where they are on their learning journey.

🗺️ 1. A roadmap will keep you on track

I'd love to say that I had it all planned out when I first started out; a clear plan of which languages I was going to learn, the stack I wanted to have, and the coding concepts that underpinned my SaaS idea, but this would be lying.

I was looking forward to getting stuck in, but was focused on learning languages I could actually use to build my SaaS. I didn't want to fall into the trap of aimlessly picking up shiny new tech without a big picture in mind, so I needed to decide where I wanted to head.

After reading a few articles, Reddit posts, and Twitter threads, I decided to start with JavaScript; it was versatile, a gateway-language to other languages, and paired well with HTML and CSS. It seemed like the perfect place to start. ...But then what?

I took my time and put together an outline of what I wanted to learn. Plotting my roadmap would mean I would learn more efficiently, and with greater focus. If I had a final destination in mind, the journey wouldn't feel endless and meandering. I could measure progress, I could set myself targets along the way, both long-term and short-term.

Just a few weeks after picking up JavaScript, I knew roughly how I wanted the following 18 months to look; 6-12 months of pure JavaScript, 6 months of React, and then I would focus on backend technologies unless something else came up along the way (spoiler: it did).

I knew I needed a strong coding base to build on top of, so the entire 18 months would be spent immersing myself in core principles, fundamental concepts and whichever tech would (a) be of use in building my SaaS and (b) versatile enough to build others projects with in future.

🏃‍♂️ 2. It’s a marathon, not a sprint.

I knew I wasn't going to learn to code overnight. This was something I had committed to it for the foreseeable future, and something for which I knew the learning would never really end.

I knew there would be ups and downs along the way, and times when my progress would slow, but so long as I was still making steps towards my goal, that's all that mattered.

It's cliche to say consistency is key, but it really underpins the approach I have taken to learning to code. I have a full-time job as a teacher, so finding time each and every day to code hasn't - and isn't - easy.

Some days I would make next-to-no progress at all, and other days, take a giant leap forward. Some days I'd write hundreds of lines of code, other days I'd spend what little time I did have, reading. It's all part of the process, and whatever happens, come back the next day and keep moving forward.

🧰 3. You’ll build your SaaS, then build it again.

About 6 months after first delving into JavaScript, keen to practice what I had learned, I started building a rudimentary version of my SaaS. No frameworks, no backend, just HTML, CSS and some JavaScript.

The code was long-winded, bloated, ugly, inefficient, but the most basic functionality was there. But basic really is the operative word to describe what I built at that time. No frameworks, no backend, just HTML, CSS and JavaScript. It combined almost I had learned up to that point, cemented my learning, and showed me that I was ready for the next step.

I put this project to one side, confident I had a good grip on the fundamentals of JavaScript, and turned towards React. I was excited to see what all the fuss was about, but still unsure of exactly what it was and what it made it so special.

As I always do when learning something new (coding or otherwise), I spent a few days familiarising myself with basic concepts and terminology; learning what React was all about.

It was exciting, but also a little demoralising, because once I'd wrapped my head around the benefits of React, I just knew I was going to have to practically rebuild my SaaS from the ground up.

Little did I know, but this rebuilding process would happen again - but admittedly to a lesser extent - when I would add Tailwind CSS to my stack. Then again when I found Next.js. As is often the case, I would upgrade my skills, and see new ways of approaching the project that I didn't even know were there, and a simple refactor just wouldn't be enough.

Be ready to build, rebuild, and then build it all over again.

🔥 4. Having multiple projects helps you avoid burnout.

Along the way, my motivation to work on my SaaS fluctuated. Even at times when it was all going well, too much of a good thing is a real thing. While my SaaS project was my primary focus, it was important to keep things interesting.

After hitting important milestones along the way, I would take some time away from my SaaS idea to build other projects. Sometimes it would be days; other times, weeks.

In the time between that first version of my SaaS and now, I developed and launched three projects: a tool to help developers find colour palettes for their next project, called ColorHub; a simple site that creates image cards for Twitter profiles, Yodlr; and an open source tool called ProfileMe.dev, that lets users quickly design - and get auto-generated markdown code for - their GitHub profiles.

Not only was this a great way to avoid getting tired of working on one project, it was also a great way to get a stronger grip on the new technology, techniques and approaches I had picked up.

To outsiders, it likely seemed like I was procrastinating over creating my SaaS, but I was in fact building up my skills so I could confidently create what I had in mind, not hack something together while having only a tenuous grip on the code behind it.

🐞 5. You’ll encounter bugs you think are unsolvable. Embrace these moments, because they are when you learn the most.

Each time I picked up a new technology, language, concept or framework along the way, I was careful to get comfortable with it before applying it to my SaaS project.

At times, I was working right at the tip of the spear of my skills, struggling through tutorials, encountering issues I never saw coming, with no idea where to start in solving them. I really can't stress how frustrating these times were; it was like I had something stuck between my teeth that I just couldn’t shift.

I would step away from my computer and it would be on my mind; I’d find myself running through logical steps in my head, looking to understand the problem and think of a conceptual solution. Eventually, I would find a solution, and with it would come a eureka moment and (more importantly) a big upgrade in skills, too.

Expect to hit walls, and a lot of them, but know that it’s inevitable that you'll find a way around, even if it takes a while.

👷 6. Building in public is invaluable

I joined Twitter about 5 months in, and decided to start sharing my ups and downs and project progress with other developers.

I originally joined to expand my network, to hold myself accountable, to learn from those in the tech Twitter community and to get over a fear of sharing my work (a topic I wrote about here). What I wasn't expecting, however, was to find a community as willing to give support when I hit a wall, motivation when I had lost my own, and advice on how to solve issues when I came across them.

Through sharing my work, I got regular feedback on the direction I was heading, the UX/UI's I was developing, and the approach I was taking. Oh, and I soon got over my fear of sharing what I was building, too.

🖥️ 7. Low-code tools can ease you into the world of backend

Getting to the stage where I had built a one-page React version of my SaaS was demanding in itself, but I soon realised it had none of the features that would actually make it a SaaS. No backend, no authentication, no payment gateway, no storage, and only basic versions of the features I wanted it to have.

If the user refreshed the page, they were right back at the beginning. ...It needed a backend.

My first instinct was to research backend languages and frameworks that paired well with my Next/React/Tailwind stack. I spent a week or so dabbling with Node and Express (part of the MERN stack), and they seemed like a logical next step.

Conscious that I didn't want to dive into backend before I had a strong grip on my frontend stack, I decided to look at alternative paths. Supabase offered a low-code solution that would help me understand how backend technologies work without having to learn an entire stack of backend languages to do so.

Using Supabase was a fantastic way to get my head around some fundamental backend concepts (CRUD, etc), so if you're in a similar position, I'd recommend starting with a low-code solution, you can pick up the rest further down the line.

🧩 8. You are building a template for future projects.

Building my first SaaS meant a lot of firsts. My first time using GitHub, my first time using React components and hooks, my first time figuring out how to add authentication to my project, and many more.

As with learning anything new, the first time often doesn't run smoothly, and takes a little while to get your head around. With coding, though, each time you create a feature or solve a logical issue, you're creating snippets that you'll use again in future. You'll be able to 'install' features into your projects that took days, weeks or longer to create, but seconds to plug in to a fresh project.

Reminding myself of this periodically helped me to look at my journey as a long-term one that would progressively get easier, rather than more difficult, even if the code itself got more complex.

👨‍💻 9. You’re developing more than just coding skills.

As any developer knows, coding is more than just hammering out syntax. It's a complex and unpredictable game that involves problem solving, creativity and perseverance, but learning to build a SaaS broadens the skills you're developing even more.

Creating a SaaS allowed me to lean on my design skills for the UI and use them in combination with more recent passion for coding, but it also challenged me to develop skills in so many other areas: how to brand and market a product, how to write copy, how to design a subscription structure that incentivises sign-ups, how to improve overall UX, and so much more.

💭 10. Imposter syndrome is inevitable

When I began this journey, I'd heard so much about imposter syndrome, but been lucky enough not to really experience it in any major way. I was careful not to compare myself to others, not to overthink the process of learning and building projects; conscious that I didn't want to encourage feelings of inadequacy or anything that could hinder my productivity and motivation.

It didn't really matter.

It's natural for imposter syndrome to flare up and rear its ugly head, no matter how much you try to avoid it. It's normal to doubt yourself when you've spent days trying (and failing) to fix a bug, or can't seem to get something that seemed so simple to just... work. It's normal to feel that way, but the difficult part is not listening to it.

When imposter syndrome would kick in, I would try to remind myself that it would pass with time, and could only slow my progress if I let it. I'm sure you can do the same.

To conclude

Learning how to build - and actually building - a SaaS has been one of the most challenging things I've ever done, but it's also been one of the most rewarding. The journey to get here was long, and as fun as it was stressful. It's only now that I've launched my SaaS into public beta, I'm able to look back and see how far I've come. Whether or not this SaaS generates revenue is to some degree irrelevant, because what I learned along the way is truly invaluable.

If you enjoyed this article and want to see more content about development, design, creativity and learning, then follow me on Twitter at @danielcranney.

If you'd like to see my work, check out my portfolio or visit my SaaS at Reportr.io.

If you'd like to support me to make more content, check out my BuyMeACoffee page.

My product, ColorHub, helps developers to find the perfect colour palette for their next project.

What started as a small-scale experimental project grew into something so much more.

Eager to share it with other developers, designers, creators (and potential users), Product Hunt was the perfect place to go.

Launch day was scary but amazing, and I ended the day at number 7 in the Product Hunt charts, with over 260 upvotes.

Here’s what I learned from the launch:

You’ll Never Really Feel Ready

A project is never really complete, and you’ll continue to add features and edit your code long after your users start using it.

It's easy to hold off on launching because there’s always one more feature to add, and one more refactor to complete, right?

Early on in the development stage, set some clear goals for your project. What are the key features that you need to add in order to call it a minimum viable product (MVP)?

Write these features down, build them out, and tick them off when they’re working correctly. Try not overcomplicate it, because this will only delay its launch.

It's important you resist the urge to add more features to the list once you’ve written it up. You can always add feature ideas to your roadmap, post-launch, so just take a note of them but don’t start working on them until after launch day.

Launch Time is of the Essence

Choosing the right time to launch your product seems like a simple decision, but it’s important to be aware that the Product Hunt (PH) does not adjust for different time zones. This means the PH day begins at midnight pacific standard time (PST) and runs until 11.59pm.

Product Hunt themselves say "there is no “magic” time to post, but it’s best practice to do it before 9am" pacific time, to make sure visitors have enough time in the PH day to check it out.

As I’m based in the UK, midnight PST is 08.00am GMT. For me, an early morning launch worked well, with launch day lasting until 07.59am the following day, local time.

This gave users plenty of time to take a look at my site, but also meant I could respond to questions and feedback quickly throughout the day.

Get the timing wrong and you’re limiting your chances of reaching that coveted number one spot by cutting your launch day short. Get it right, and watch your product rise through the ranks throughout the day!

It Takes a Community to Raise a… Product

When I first started to learn to code, I joined Twitter to share my journey and connect with other developers and creators.

All the way along, I shared my thoughts and feelings about what I was learning, shared updates on projects I was building, and asked for feedback on features I was adding to each one.

By engaging with the tech community on Twitter (which is huge, by the way) I found that developers invest in products and people that they have watched grow from the ground up.

When it came to launch day, I was bowled over by the level of support I received from so many kind and talented developers and creators from all over the world.

By building in public, people can invest in you as an individual, and the products you make, and help to shape them both.

If people like you, or your work, they're far more likely to tell others about it. Be sure to engage with the tech community, whether it's on Twitter or elsewhere. You'll be surprised at the difference it makes.

Preparation is Key

Once I had prepared my product for launch on the PH dashboard, I scheduled it to launch 10 days later.

This gave me time to ‘promote’ it on Twitter, and let followers know when they could expect it to launch.

During this 10 day period, I shared one of the pre-made colour palettes available on my product each day on Twitter, making sure I responded to everybody that took an interest in the project, and making a note of the feedback they gave.

One of the Tweets I shared in the run-up to the launch

This 10 day run-up was a great way to force myself to focus in on the finer details of the product. I quite simply didn't have time to add any new major features in this time (even though it was tempting), so instead I set about fixing the tiniest of bugs (with the help of some fantastic developers who were kind enough to point many of them out to me).

Those console.log's I left in by mistake? A quick fix. The typo in my code? A two second job.

Wanting to make sure my users would have the best experience possible, I ran my website through Google Lighthouse (on Chrome) to improve loading times and accessibility.

I also took some time to create an introductory video to (a) go on the Product Hunt launch page and (b) go on the landing page of the site itself. Check it out below to get an idea of what I produced.

Feedback Helps You Build Your Roadmap

A question many users will ask you on launch day is, 'what features will you add next?' or 'what does your roadmap look like?'. The truth is, you might not know.

You've probably spent countless hours getting your project to the point where it's fit to launch, and you might not have given too much thought to what comes next.

Listen to the feedback your users give. Users will suggest features they'd like to see, improvements you can make in user experience and user interface, and give you ideas for what your project could become.

Take a note of what your users say. By capturing these comments, emails, tweets and DMs you can produce a detailed roadmap for your product and build it into something bigger, and better.

Launching is a Great Way to Find New Users

Before launching my product, I half-expected it to go almost-unnoticed; being shared by those close to me and people I engage with on a regular basis, but without much traction outside of my circle.

I was wrong.

All the way through launch day, new users reached out to me in the Product Hunt comments and on Twitter, and I was surprised by how many said they'd be using it in future.

Launch day was a great way to meet potential users, and to hear from people who hadn't seen it as it developed but intended to use it now that they knew about it.

Never Skip Over Analytics

Product Hunt does a great job of pulling together some stats on your launch, such as your position in their daily charts and the number of upvotes and comments your product received throughout launch day (see below).

However, it's important you install an analytics tracker to see what kind of traffic your website gets on launch day and beyond.

I made the mistake of focusing so heavily on the styling and user experience of my project that I didn't install an analytics tracker until two days after launch day (oops!).

The simple fact is, installing my chosen analytics tracker took less than two minutes, and provides me with data that would have been useful to have had on launch day (such as the number of unique visitors, the bounce rate, the device users use to view my site, and more).

Don't make this mistake! Take the time install a tracker, and keep an eye on it throughout launch day. It's actually really interesting, and pretty addictive, too!

Conclusion

Launching my product on Product Hunt was one of the best experiences I've had since learning to code.

I've made some amazing connections with some great people, my product has gotten better, my roadmap is clearer, my confidence is higher, and I'm excited to do it all over again with my next creation!

If you enjoyed this article and want to see more content about development, design, creativity and learning then follow me on Twitter at @danielcranney.

Perhaps working late into the night trying to tackle a seemingly-unfixable bug keeps you awake long past your bedtime, or waking up in the early hours with syntax on your mind means you get less shut-eye than you’d like to.

Either way, coding is cognitively-demanding, requiring high levels of attention, deep conceptual understanding, problem-solving, and memory, amongst other mental processes.

Something as cognitively intense as this doesn't always make for a sound night's sleep.

But what if rather than staring blankly at the screen when you hit a snag, you try getting some sleep instead?

Let's take a look at how coding less and sleeping more could help you to become a better developer.

The Power of Sleep

Sleep is a truly incredible thing, and not getting enough can be tough to deal with.

Whether you've had a late one the night before and found it hard to focus the following day, or an early start made you feel you had woken up on the wrong side of bed, a night with poor sleep makes everything feel like more of an effort.

On the other hand, a sound night's sleep makes you feel refreshed, like you've recharged your batteries; But what exactly happens in your brain when you're asleep?

For centuries, scientists knew very little about why we sleep and what happens when we do, but in recent years, researchers have concluded that not only is it definitely good for our brains and body, but they now wonder whether there are any biological functions that do not benefit from a good night's sleep.

Of course, sleep gives your body a chance to recover and recharge, but it also serves a crucial purpose for memory and learning; two functions that are hugely important for any developer to do well.

Making Memories

The effect that sleep has on our memory really can't be overstated.

It has a huge impact on our ability to: (a) acquire - or take in - new information (b) store it in the brain, and (c) recall the information later on.

These three functions must occur for something to become a memory, and research suggests they're all affected by poor - or a lack of - sleep.

In Why We Sleep, neuroscientist and sleep researcher Matthew Walker points to a study where students were divided into two groups, and were then asked to study a list of facts that they would be tested on at a later stage.

After studying the facts, one group was allowed to get a full night's sleep, while the other group was kept awake by laboratory staff, so they were sleep-deprived the following day. Both groups were then given two nights to recover, before being asked to recall the facts they had attempted to learn.

Perhaps unsurprisingly, the sleep-deprived group showed a 40 percent deficit in their ability to recall the facts. They were less effective at cramming new facts into their brain than those that had slept well on the first night.

Effectively, the group that had slept well aced the exam, while the sleep-deprived group failed it.

Those of us that have tried to cram the night before an exam, only to find the facts we thought we had learned had vanished when we tried to recall them in the exam itself, can relate to this research.

So, what can this teach us?

After we learn new information, it's important to get a good night's sleep if we want to make it stick.

Sleeping is Like Pressing Save

It might sound strange, but sleeping really is like pressing a save button in your brain.

When you first encounter new information, it gets stored in the hippocampus (a short-term storage site). While the hippocampus is great for storing information for a short period of time, it's not a great place to store anything really important, as its contents are quickly forgotten.

However, when we seep, newly-acquired information moves from our short-term storage, to the neocortex, the long-term storage site at the top of the brain.

While this process isn't fully understood (the brain is pretty complicated, to be fair), it's clear that a good nights' sleep - or even a solid nap - helps us to process information and commit it to memory; a key component involved in learning.

Solving Problems

Problem solving is a fundamental part of being a developer. More often than not, when we hit a bug we take the 'brute force' approach, typing away hour after hour making small tweaks in our code in the hope that we find the solution.

The issue is, the longer we work without finding a fix, the more mentally tired and frustrated we become, and the less likely we are to find the answer to the problem we were trying to tackle in the first place. It's a pretty inefficient way to go about it, right?

What if there was a better way? It might sound counter intuitive, but what if we take a break from our code when we can't find a quick fix, and just go to sleep instead?

Researchers at Northwestern University looked to better understand how sleep benefits daytime cognition by asking participants to attempt a series of puzzles while listening to specific sound cues.

Later that night, while they slept, participants were played the sounds associated with half of the puzzles they had failed to solve earlier that evening.

The following morning, participants were more likely to solve the puzzles that had the associated sound cues played to them overnight, compared to the puzzles that did not have sounds associated to them.

Kristin Sanders, a doctoral student and first author of the research paper, says the study suggests "people rehearse or ‘consolidate’ memories during sleep, strengthening and reorganising them".

Sanders goes on to say, "the underlying cognitive processes (in the study) could relate to solving any problem on which someone is stuck or blocked by an incorrect approach".

When you're working on a project, it's common to feel that you know what you need to know to solve the problem in front of you, but the pieces just won't fall into place.

A good night's sleep can help you to organise your memories, so you can use them more effectively the next day.

What does this mean for coders?

American Author John Steinbeck famously said, "It is a common experience that a problem difficult at night is resolved in the morning after the committee of sleep has worked on it."

Whether it's moving newly-learned information from short-term to long-term storage, re-organising existing memories, or continuing to think through a difficult problem long after we've closed our eyes for the night, the committee of sleep has got you covered.

So next time you come across a coding problem you just can't seem to solve, try stepping away from the screen and getting some sleep, you might just be surprised how well it works.

If you enjoyed this article and want to see more content about development, design, creativity and learning then follow me on Twitter at http://www.twitter.com/danielcranney .

Sources and Studies

Sanders, K. E. G., Osburn, S., Paller, K. A., & Beeman, M. (2019) Targeted Memory Reactivation During Sleep Improves Next-day Problem Solving. Psychological Science. 30 (11).

Sio, U. N., Monaghan, P., Ormerod, T. (2013). Sleep on it, but only if it is difficult: Effects of sleep on problem solving. Memory & Cognition, 41, 159–166.

Walker, M. (2017). Why We Sleep. [London]: Penguin Books.

From designing artwork to building websites, and from producing videos to recording music... if there was an opportunity to create something, I've taken it. But creating or building something is never as simple as it sounds, and no matter how much experience you have, it involves vulnerability, self doubt and indecision.

For most creative people, the process of making that thing is the fun part. However, for many, showing it to other people is a painful process where they (and their project) are laid bare, open to criticism and critique.

For years, I hated sharing my work. It was a necessary evil that undoubtedly made my work better, but was uncomfortable and awkward.

I would leave the room when others looked at something I had designed, or talk over songs I had recorded, pointing out every little flaw or half-finished element and justifying every creative decision.

A few years ago, as I approached thirty, I decided enough was enough.

I needed to get over the fear that I had of sharing my work, or I never would.

First, I started recording music with a friend and begun sharing it with close mates. It helped, but I needed to do more.

When I decided to start learning Javascript in late 2020, I set up a Twitter account and made a commitment to myself that I would share my journey (and my work), every step of the way.

Here's how I overcame my fear, and actually started to enjoy it...

Face the fear

The first step to overcoming the fear of sharing my work was to figure out exactly what it was that I feared in the first place.

What exactly do you fear? Is it a fear of failure, and not achieving your goals? Is it a fear of hearing criticism? A fear of others seeing the same flaws as you do? A fear or not being accepted by your peers? A fear of feeling like an imposter?

The chances are, it's all of the above (and maybe a couple of others, too), but it’s important to have an honest conversation with yourself about what it is that you find so scary about sharing your work.

Stop overthinking it

We’ve all had times in life where we’ve worried about what others thought of us.

Maybe you wanted to wear that new outfit, admit your guilty pleasure to friends, or go against the grain in a social situation, but didn’t, out of fear of how others might have reacted.

This behaviour is a common trap that most of us fall into at one point or another, but it’s more-often-than-not a result of simply overthinking.

If you had worn that outfit, or admitted you secretly dance around your bedroom miming Whitney Houston’s greatest hits into a hairbrush, would anybody have really thought of you any differently? Probably not. But you let it stop you, anyway.

To put it bluntly, we think other people care far more about what we do and how we do it than they actually do; a phenomenon known as the spotlight effect in social science circles.

The spotlight effect, like other cognitive biases, shows us that our perception of ourselves and the world around us is often out of sync with reality, and how others view us. It's natural to focus on our flaws, inadequacies and shortcomings, but also important to understand that it's highly likely other people don't even notice them at all.

Try to recognise and understand the thoughts that stop you from sharing your work, but don't let them win.

It's normal to feel like an imposter

I once heard someone say "You never really grow up, you just get better at pretending", and it made me think about how no matter what happens in life it's common to feel like a fraud; like you're not quite ready.

Imposter syndrome is all too common in and out of the development community, and creative people of all kinds so often feel like they don't have the skills needed for the task.

So if you feel like a fraud, try not to be hard on yourself; the truth is, most people feel the same way as you do, even when it's not true at all.

Take your own advice

I’m a teacher in my day-job, and have conversations with students about this very topic on an almost-daily basis, but it’s one thing to give advice to somebody else and something else entirely to listen to it yourself.

I took time to try and take an objective look at what I was missing out on by avoiding the awkwardness of sharing my work with others, and think “what advice would I give myself?”.

After discussing this with a friend in a similar position, we settled on the following mantra to live by (or at least, creatively): “Keep consistently creating content, but edit less, and show more.”

Boiling your approach down to it's essence like this can help you to focus in on what you're trying to achieve, and to avoid getting lost in the minutiae of a project and losing sight of the big picture.

Accept that everything is a work in progress

When you build or create something new, it's easy to focus on the finish line; the moment when you throw your hands in the air and shout "It's done! I'm finished!".

The problem is, that moment rarely (if ever) actually happens.

Making something is often an iterative process, with each version of it incrementally better developed than the version before.

For developers, GitHub structures this process and helps to make it a little more obvious, so that each 'commit' marks an upgrade or change in direction in a project.

While this this version-based approach is common, it also means that it's rare that you'll feel your project is ever really, truly complete, without any room for improvement.

Now don't get me wrong, this doesn't necessarily feel like a good thing; truly completing something (where you no longer return to it and edit it) brings a feeling of satisfaction that we miss out if it's just another version. But what if we look at it from another perspective?

In life, we learn from our experiences, develop new skills and work to become a better person (whatever that means to us), but we never get to the stage where we think, "That's it! There's nothing else I can learn, and no improvements to make... I've reached perfection!". So why do we do expect this from our projects?

At the same time, we don't hide away from the world until we're good enough, do we? Our self-improvement happens out in the open, every single day. So why would our projects be any different?

Accepting that your projects, like you, are a constant, never-ending work in progress that you revisit and develop will allow you to be less critical of the flaws that you find because once you've found them, you can fix them, one at a time.

Share the process, not just the product

If you agree that a project is never really, truly complete, then it's much easier to share your work because it'll always have some flaws (no matter how minor), but they won't bother you quite so much because you just haven't fixed them yet.

If we remember that the process is more important than the end product, then why wouldn't we show the project as it develops?

When I first started to learn to code, I started sharing screenshots, videos and links to my projects on Twitter to show each step in the development process.

Not only was this a great way to document the progress of each project, telling the story of how it took shape, but I found that others became invested in my progress and what I was learning and building. This gave me a huge boost in confidence, and helped me to see I was on the right track.

Expect criticism and accept critique

Everybody loves a try-er, right? Well... not everybody, but that's to be expected. It doesn't matter what you do or how well you do it, you just can't please everyone.

Depending on how big your following is, you're bound to receive both criticism and critique, but it's important to recognise the difference.

Criticism is judgmental and focused on finding fault, while critique is balanced and justified by explanation. It's easy to think the two are the same, but critique is constructive and helps you to improve your work, criticism often doesn't.

In my experience, the vast majority of people in creative communities online (and in real life) motivate others around them, not criticise them.

Sure, a small number of people are bound to criticise your work, but most will look for the positives in it or offer ways to help you improve it.

The benefits you'll get from receiving constructive feedback will always outweigh the small amount of negativity that might come your way because you decided to share in public.

Others complimenting your work can be a huge confidence boost and so if you can find a way not to take criticism personally but to learn from critique, you'll be far happier for it (and better at what you do, too!).

Start today

Sharing your development work isn't easy, but the more you do it, the easier it gets. The #100daysofcode challenge is a great way to hold yourself accountable, and get used to showcasing your work, warts and all.

So go for it! Start sharing with others, you'll be surprised how good it feels.

Hopefully this article will give you that push you need to start showing others what you do, and maybe one day you'll actually enjoy it, too!

If you enjoyed this article and want to see what I'm working on (or read more content related to web development, design, creativity and learning) then follow me on Twitter at http://www.twitter.com/danielcranney .

So, recently I decided to build one with React and Tailwind, and it couldn't have been easier!

What are we going to build?

In this article, we're going to build a full-screen mobile menu with an animated hamburger icon, using React and Tailwind. I've included a preview below so you can see the finished result, and the icon up-close. Alternatively, you can check out the GitHub repo to see the completed code for yourself.

Before we get stuck in, it's worth pointing out that the icon animation works best when you're using React Router or NextJS (because the page won't reload, which creates a smoother animation), so if you've not used either of them before then I'd recommend checking them out.

Table of Contents

Structure

• Initialise your Project
• Create your Components
• Import your Components into App.js

Handling State

• Setting up useState
• Passing State into Components
• Accessing State Inside Components

Adding Content to the Components

• Building the Header
• Building the Menu Overlay

Adding the Hamburger Icon

• The Code
• How Does the Icon Work?

Structure

Initialise your Project

Okay, let's get started!

The quickest way to get up and running is to use Create React App, and as we're going to be using Tailwind for styling we may as well get both set up together.

If you don't already have a project open, then follow the steps on this page of the Tailwind docs to initialise your React project and install Tailwind.

If you'd prefer to set up a Next Js project, simply follow these steps before continuing to the next section.

Create your Components

Once you've initialised your project, we're going to start creating some empty components that we'll fill as we go.

For this tutorial, we're going to create just two components: a header, which will contain a logo and our animated icon; and a full screen overlay which will contain an overlay background and some menu items.

First of all, create a components folder inside of the src folder. In the new /src/components folder, create a file called Header.js, and another called MenuOverlay.js.

Inside of each file, create a simple functional component, or use the code below to speed things along (remembering to change 'Header' to 'MenuOverlay' for the second component).

import React from "react";

const Header = () => {
  return <></>;
};
export default Header;

Import your Components into App.js

Once you've made both components, go back into App.js and import them like so:

import Header from "./components/Header";
import MenuOverlay from "./components/MenuOverlay";

Next, we're going to place the components inside the return statement of App.js (wrapped in a div or React fragment, because otherwise React will get angry at you and you'll get an error). They might be empty components right now, but we've got our structure in place so we won't need to hook up any more components as we go, or at the end.

function App() {
  return (
    <div>
      <Header />
      <MenuOverlay />
    </div>
  );
}

Handling State

Setting up useState

In App.js, we're going to the useState hook to track whether the mobile menu is open or closed, switching the state whenever we click our button in Header.js.

First, we're going to import the useState hook at the top of App.js:

import React, { useState } from "react";

Then we'll set our state and our setState function.

const [navbarOpen, setNavbarOpen] = useState(false);

Finally, we're also going to set some basic styles on our wrapper div, setting a minimum height and a background colour (see below). Your App.js file should now look like this:

import React, { useState } from "react";
import Header from "./components/Header";
import MenuOverlay from "./components/MenuOverlay";

function App() {
  const [navbarOpen, setNavbarOpen] = useState(false);

  return (
  <div className="App w-full min-h-screen bg-gray-800">
      <Header />
      <MenuOverlay />
    </div>
  );
}

export default App;

Passing State into Components

At the moment, we've declared our useState, but we're not using it. So, we're going to pass both the state variable (navbarOpen) and the function (setNavbarOpen) into both of our components as props, like so:

<Header navbarOpen={navbarOpen} setNavbarOpen={setNavbarOpen} />
<MenuOverlay navbarOpen={navbarOpen} setNavbarOpen={setNavbarOpen} />

This way, when the navBarOpen boolean changes (eg from true to false) the nav bar will close along with it. Oh, and the icon will change inside of the header component, too... but we'll get to that.

Accessing State Inside Components

Inside of both of our components, we're going de-structure our props so that we can use them inside of each component. Simple change your component declarations to the following, to pull the props through:

// Header.js
const Header = ({ navbarOpen, setNavbarOpen }) => {
// MenuOverlay.js
const MenuOverlay = ({ navbarOpen, setNavbarOpen }) => {

Now that we set up our components, imported them into the main app, and created a useState hook to handle state, we're ready to start building and styling the components!

Adding Content to the Components

Building the Header

In Header.js, we're going to build a basic header component that will hold our hamburger icon a little later on.

Using Tailwind, we're going to create a full-width header element, fix it to the top of the window, then add a div for our logo, and a button for our hamburger icon:

const Header = ({ navbarOpen, setNavbarOpen }) => {
  return (
   <header className="w-full fixed top-0 left-0 p-10 flex z-20">
      <div className="text-white flex-grow z-20">
        <h1 className="text-2xl font-bold my-0">Logo</h1>
      </div>
      <button
        className="lg:hidden flex top-0 right-0 z-20 relative w-10 h-10 text-white focus:outline-none"
        onClick={() => setNavbarOpen(!navbarOpen)}
      >
        Icon will go here
      </button>
    </header>
  );
};
export default Header;

You'll notice we've used flex on the header element to align its children next to each other, and z-20 so that the logo will still be visible when the overlay menu appears.

Importantly, we've also added an onClick function to our button, to switch the status of navBarOpen (from open to closed, or vice versa) when clicked.

onClick={() => setNavbarOpen(!navbarOpen)}

While the button element only holds text at the moment, we'll be adding our animated icon a little later on as part of its own section of the tutorial, and explaining how it works.

Building the Menu Overlay

In MenuOverlay.js, add a nav element, and an unordered list inside of the return statement:

return (
<nav>
    <ul>
      <li>
        <a href="/">Home</a>
      </li>
      <li>
        <a href="/">About</a>
      </li>
    </ul>
  </nav>
);

It might be basic at the moment, but now we're going to start adding styles and it'll really come to life... I promise!

Styling the Menu Items

Inside the nav element, you should replace the unordered list with the following:

// MenuOverlay.js Styles
<ul className="w-full flex flex-col items-start">
    <li className="nav-li">
        <a
        href="/"
        className="nav-link"
        onClick={() => {
            setNavbarOpen(false);
        }}
        >
        Home
        </a>
    </li>
    <li className="nav-li">
        <a
        href="/"
        className="nav-link"
        onClick={() => {
            setNavbarOpen(false);
        }}
        >
        About
        </a>
    </li>
</ul>

You've probably noticed that each li carries the class nav-li, and each anchor tag has the class nav-link. To add these classes, simply add the following to your globals/index.css:

// global or index.css
@layer components {
  .nav-li {
    @apply flex w-full leading-8 list-none focus:outline-none group py-2 tracking-normal opacity-50 hover:opacity-100 transition-all duration-200 ease-in-out;
  }
}

@layer components {
  .nav-link {
    @apply h-full w-full py-2 text-lg text-white;
  }
}

Alternatively, you can add the list of classes to the li and anchor elements respectively, but this creates a lot of repetition, so I'd recommend sticking to the steps above!

Styling the Full-Screen Menu

Next, we need to add some simple styles for our full-screen menu. Replace your nav element opening with the following code:

 <nav
      className={`fixed flex top-0 left-0 w-full px-10 z-10 h-screen pt-24 bg-gray-900 transform delay-100 transition-all duration-300 ${
        navbarOpen ? "opacity-100 translate-x-0" : "opacity-0 -translate-x-full"
      }`}
    >

This fixes the nav element to the browser, adds some padding and a background colour, and some transition settings. There's also a simple ternary statement in the template literal, animating the opacity and the position of the nav element when the button is clicked so that it swipes in from the side and fades in at the same time.

Well done, your MenuOverlay.js is complete! It should now look like this...

import React from "react";

const MenuOverlay = ({ navbarOpen, setNavbarOpen }) => {
  return (
    <nav
      className={`fixed flex top-0 left-0 w-full p-10 z-10 h-screen pt-24 bg-gray-900 text-white bg-opacity-100 transform delay-100 transition-all duration-300 ${
        navbarOpen ? "opacity-100 translate-x-0" : "opacity-0 -translate-x-full"
      }`}
    >
      <ul className="flex flex-col items-start">
        <li className="nav-li">
          <a
            href="/"
            className="nav-link"
            onClick={() => {
              setNavbarOpen(false);
            }}
          >
            Home
          </a>
        </li>
        <li className="nav-li">
          <a
            href="/"
            className="nav-link"
            onClick={() => {
              setNavbarOpen(false);
            }}
          >
            About
          </a>
        </li>
      </ul>
    </nav>
  );
};

export default MenuOverlay;

Almost there...!

Things should be starting to come together, and while you don't have a hamburger icon just yet, you should be able to click the button in Header.js to hide and show the full-screen overlay.

Now then... the stage is set and we're ready to build our hamburger icon. Let's get to it!

Adding the Hamburger Icon

Now that you're familiar with conditional classes, we're going to add the hamburger icon into the mix (because it has a lot of them!).

Take a close look at the GIF below, and you'll see our icon is made up of three horizontal lines, with the top two rotating when the button is clicked (to form an 'X'), and the middle one collapsing down to the left-hand side of itself.

The Code

Replace the button in Header.js with the code below, and then we'll take a closer look at what's happening here.

// Header.js
<button
className="lg:hidden flex top-0 right-0 z-20 relative w-10 h-10 text-white focus:outline-none"
onClick={() => setNavbarOpen(!navbarOpen)}
>
<div className="absolute w-5 transform -translate-x-1/2 -translate-y-1/2 left-1/2 top-1/2">
    <span
    className={`absolute h-0.5 w-5 bg-white transform transition duration-300 ease-in-out ${
        navbarOpen ? "rotate-45 delay-200" : "-translate-y-1.5"
    }`}
    ></span>
    <span
    className={`absolute h-0.5 bg-white transform transition-all duration-200 ease-in-out ${
        navbarOpen ? "w-0 opacity-50" : "w-5 delay-200 opacity-100"
    }`}
    ></span>
    <span
    className={`absolute h-0.5 w-5 bg-white transform transition duration-300 ease-in-out ${
        navbarOpen ? "-rotate-45 delay-200" : "translate-y-1.5"
    }`}
    ></span>
</div>
</button>

How Does the Icon Work?

Our animating hamburger icon is made up of a button element, with an inner container div. Inside the div are three spans, with each span representing a line in the icon.

The Button

Our button is hidden on a large device (above 1024px), has a fixed width and height of 10 (on Tailwind's scale), we've turned off the default outline on focus, and set the z-index to z-20 so that it sits on top of the overlay. Of course, we've also got our onClick function handling the opening and closing of our menu.

<button
className="lg:hidden flex z-20 relative w-10 h-10 text-white focus:outline-none"
onClick={() => setNavbarOpen(!navbarOpen)}
>

The Inner Container Div

The inner container is absolutely positioned in the center of the button... nice and simple!

<div className="absolute w-5 transform -translate-x-1/2 -translate-y-1/2 left-1/2 top-1/2">

The Top and Bottom Line

The top and bottom lines in our icon simply rotate 45 degrees to form an 'X' when clicked, and return to normal when our menu is closed. Note that the top line includes "rotate-45" and the bottom line "-rotate-45".

<span
className={`absolute h-0.5 w-5 bg-white transform transition duration-300 ease-in-out ${
    navbarOpen ? "rotate-45 delay-200" : "-translate-y-1.5"
}`}
></span>

The Middle Line

The middle line follows the same pattern as the others, but transitions between a width of 0 and 5, with to handle its timing.

<span
className={`absolute h-0.5 bg-white transform transition-all duration-200 ease-in-out ${
    navbarOpen ? "w-0 opacity-50" : "w-5 delay-200 opacity-100"
}`}
></span>

Adding the Width Transition

Finally, to avoid errors, we need to add 'width' as a transition property in our tailwind.config.js so that the middle line animates as it should:

theme: {
    extend: {
      transitionProperty: {
        width: "width",
      },
    },
  }

Voilà!

And there we go, you've got yourself a fancy new animated full-screen menu and hamburger icon! Wasn't that easy?

Check out the GitHub repo for this project if you'd like to see the finished code, and feel free to connect with me on Twitter for more coding related content!

There's a load of complex concepts to wrap your head around, syntax to learn, frameworks to add to your stack, and a never-ending stream of frustrating bugs to fix along the way.

Navigating the world of code without a bootcamp or a mentor can be tough, and any self-taught or community-taught developer will inevitably find themselves wondering am I learning the right thing? Am I using the right resources? Am I learning to code the right way?

As if it wasn’t difficult enough, would-be developers will constantly hear others say, "Want to learn to code? Just start building!”, as if there's no learning curve at all.

Of course you can start building projects with a few months of coding experience under your belt, but is diving in head-first really the best way to learn?

How do we learn?

Back in the 1960's, educational psychologist Benjamin Bloom (and a committee of educators) put together a model on the Mastery of Learning that we now know as Bloom's Taxonomy of Learning. The model, used by educators worldwide, suggests students pass through six levels of understanding on their way to mastering a subject or skill, starting with simply remembering facts, and ending by creating original work using what they have learned along the way.

Formal courses, mentorships and bootcamps are usually structured in a way that helps students pass through the levels in Bloom's model in a logical order and at a manageable pace. Learning independently without a syllabus or a structure to follow can mean would-be developers find the process frustrating, and much slower than they had initially hoped.

Why not 'just start building'?

Starting to build your project too early can mean that you overlook core concepts, and these gaps in your knowledge can catch you out later down the line. The way to avoid this is scaffold your learning.

Bloom's model is based on the concept of scaffolding (yes, you read that correctly), where learning is broken down into smaller chunks, starting with simple tasks like "define this" or "describe that" before moving onto more complex tasks that make use of what was learned in earlier lessons.

Throughout the scaffolding process, students connect previously-learned concepts to new ones, so that the links between all of the aspects being covered are clear to them.

Bloom's model suggests that building is the final stage in a students' learning journey, and that it's important to move through the stages carefully, rather than just jumping straight in.

So, let's take a closer look at each of the levels to see how this idea relates to coding...

The Levels

Level one: Remembering

Recalling facts and basic concepts

The very first step when mastering anything is remembering the most basic concepts and the language surrounding them, and coding is no different.

When you first come across words and concepts like variables, functions and conditionals you might not understand how they work, or be able to use them for yourself. However, if you can take the time to define, identify, explain and even memorise a few you're going to level up nice and quickly even without knowing how they work!

Terminology plays a big part at this stage, and if you can define core concepts and terms like parameters, arguments, arrays, strings and booleans then you’re off to a great start.

Programming has a LOT of terminology, so it's important that you take some time to learn the language surrounding programming if you're going to learn quickly and more importantly, deeply.

It’s important to start with a strong foundation if you’re going to progress well later on, so try not to rush this step! Familiarise yourself with as many basic concepts as you can, and keep a glossary of all the terms you come across so that they become part of your everyday development vocabulary.

Level two: Understanding

Explaining ideas and concepts

Okay... this might sound obvious (because if you're learning something, you're obviously trying to understand it, right?), but the next step is to understand some of the core coding concepts.

If we look at functions as an example of a topic you're trying to understand, at this stage you'll move from simply knowing what functions are to knowing what they do.

It might not seem like much, but this shows that you've levelled up your understanding of a subject, and now you can compare concepts, summarise them, and discuss them.

It might not be much in the grand scheme of things, but it's a huge improvement from level one because you're starting to see how some of the core concepts work.

Note that you might not have even written a line of code by this stage, but you're preparing yourself with the knowledge needed to write code and build (and perhaps more important debug) far more efficiently down the line.

Level three: Applying

Using information in new situations

You're half-way!

Level three is where you start applying what you learned at levels one and two to new situations. This is probably where you'll actually start writing code (albeit simple code) on your own.

You're not quite ready to build an entire project on your own yet, but you're ready to use what you know to solve a few simple challenges, and use concepts that you have a good grasp on in your code.

Imagine the challenge is to multiply a given number by two. You might do it in the most efficient way, but at this stage you can probably figure out that a function would be a good way to go about this solving this problem, and be able to use one to solve the problem in front of you.

At level three, you might not be able to write a huge amount of code, but you've got a good grip on some of the key concepts and can apply them in new situations.

If you're a beginner, check out some of these coding challenges to see how much you've learned.

Level four: Analysing

Making connections between ideas

As you continue to learn, you'll start combining different aspects together to solve problems.

The analysis stage is where you start to see how all of the different elements that you have learned so far connect with one another.

By this point, you'll have come across a few concepts that offer alternatives for one another like function declarations, function expressions, and arrow functions. Up until now, you've probably used them all interchangeably without thinking too much about why you're using the one you're using, or even noticing the differences between them!

At this stage, you'll start connecting, comparing and contrasting the different concepts and options available to you when solving a problem, and deducing answers to problems based on logic. Great progress, considering where you started!

Level five: Evaluating

Evaluating: justifying a decision

Okay, I know you'll be itching to start building, but hold up! You've got one more level to pass through before getting stuck into a project of your own.

The evaluation stage is where you're comfortable enough with your coding knowledge that you can look at other people's solutions and critique their approach, evaluate the pro's and con's of different solutions.

If you're at this stage, you've got a really grasp on most of the aspects needed to start building: a solid development vocabulary, a good understanding of the core concepts, experience of applying each of these concepts in practice, and multiple ways of approaching problems that you come across.

A good way of knowing if you're at the evaluation stage is to justify your approach a given task. Think about why you solved a problem one way and not another.

When you think you can justify the approach you take throughout your code, then it's time to start creating!

Level six: Creating

Producing new or original work

You made it... You're finally ready to start building!

The final level, creating, is where you put everything you've learned together to develop something new and original.

Your skills have come so far, and now you can design a project before you build it, modify and rewrite your code as you go, invent new solutions to problems you encounter, and even collaborate with others to get the job done!

What to do next

Of course it's important that you put your knowledge into practice and build projects when the time is right, but it's easy to think that you're only learning to code when you're actually building something.

Take some time to study coding. Read documentation, study other people's code on Github, consider alternative approaches, and try to be conscious of which of Bloom's levels you're on so that you know what comes next.

Hopefully you'll find this tip helps you to learn to code more effectively, and to know there's a lot more to learning to code than just building.

If you enjoyed this article and want to more content related to web development, design and learning then follow me on Twitter at http://www.twitter.com/danielcranney.