- Listen on Apple Podcasts
- Listen on Google Podcasts
- Listen on Spotify
- Listen on Pocket Casts
- Listen on Castro
- Listen on Breaker
🎙 About the episode
Personal branding is something we often mention on this podcast. However, it is also something many developers don’t prioritize.
In today's job market, having a strong personal brand is vital for success in the tech industry. Personal branding involves crafting a distinctive image and reputation for yourself, setting you apart, and ensuring you get noticed rather than ignored. When others appreciate your work and projects and understand your capabilities, they may approach you with enticing job opportunities or freelance projects. A hiring manager at a company you applied for will, for sure, google you. Wouldn't it be great if you could control what they see?
Also, by maintaining a personal brand, you’ll be more visible to your peers - which will help you create or find community.
In this episode, we’ve compiled advice from multiple experts to help you get started with or further develop your brand as a developer. Get ready for actionable advice from Gary Simon, Cassidy Williams, Josh Comeau, Shawn Wang (Swyx), and Madison Kanna!
- What is a personal brand (02:22)
- Why you should have a blog (04:02)
- Allow yourself to iterate (04:34)
- Why you shouldn’t rely solely on social media (06:27)
- What can you do if you’re not good at design? (07:21)
- Community break with Jan The Producer (16:40)
- Why you should blog about your learning process (18:54)
- How to streamline your content production (23:46)
- How can you do all this while actually learning without just becoming a content creator? (26:24)
- Different ways of learning in public (28:10)
- How to organize your portfolio projects and talk about them (30:52)
- Putting yourself out there is intimidating, BUT (33:19)
- Start small and just write (35:50)
🧰 Resources Mentioned
- The Coding Career Handbook by Swyx (30% discount applied when you use this link)
- Learn in Public by Swyx
- Josh's book, Building an Effective Dev Portfolio (it's FREE!)
- Podcast: Becoming a six-figure freelancer, with Gary Simon
- Podcast: Homeschooler, College Dropout, Developer and Master Networker: Crush Your Career with Madison Kanna
- Podcast: How to Create a Web Dev Portfolio That Both HR and Other Developers Will Love, with Josh Comeau
- Podcast: Ace the job interview with Cassidy Williams
- Podcast: How to make your own luck with Shawn Wang (Swyx)
🔗 Connect with Gary Simon
🔗 Connect with Cassidy Williams
🔗 Connect with Josh Comeau
🔗 Connect with Shawn Wang
🔗 Connect with Madison Kanna
⭐️ Leave a Review
If you enjoyed this episode, please leave a 5-star review here and tell us who you want to see on the next podcast.
You can also Tweet Alex from Scrimba at @bookercodes and tell them what lessons you learned from the episode so that he can thank you personally for tuning in 🙏 Or tell Jan he's butchered your name here.
Shawn Wang (Swyx) (00:00):
The prototypical action is to write, is to write tutorials, is to write blog posts. Just basically try to write for yourself like three months ago. Don't try to establish thought leadership, publish the Great American novel, or break the industry. You'll get there. Just warm up first.
Alex Booker (00:16):
Hello and welcome to the Scrimba podcast. On this weekly show, we talk to both new and senior devs as we go on the hunt for actionable tips to help you learn to code and get your first dev job. Today, we're talking about personal branding. Now, personal branding, it's a concept that often comes up on this pod. However, it's also something many developers do not prioritize. We agree that getting better at your craft as a developer is important, but all our most successful guests say the same thing, which is that it really helps your chances to be successful if you are proactive about surfacing and demonstrating your craft, your achievements, and expertise.
In today's job market, a personal brand is one of the things that can really set you apart. So what is personal branding exactly? Well, you're going to get lots of actionable and approachable examples in this episode, but in summary, it involves crafting a distinctive image and reputation for yourself, setting you apart and ensuring you get noticed rather than ignored. A personal brand helps you get noticed because it gives others a chance to discover and appreciate your work and once they understand your capabilities, they might just approach you with an enticing job opportunity or freelance project.
If you had no brand or blog or anything like that, they could never discover you. Of course, if you're going on the outbound, actively applying to jobs on LinkedIn, for example, a personal brand can be a big help there as well. Know that the hiring manager will for sure look you up and then your personal brand will be the first thing they see that gives you an impression about who you are and what you do, and as we all know, first impression counts. That's why in this episode, we've compiled advice for multiple experts to help you get started with or further develop your brand as a developer. You are listening to the Scrimba podcast. Let's get into it.
Gary Simon (02:22):
A brand, just let's take a step back and look at it from a macro perspective. A brand is visual, but it doesn't have to be. It could be a person, it could be a spokesperson, it could be something you smell. There could be smells associated with certain brands, it could be audible. So it's really an all encompassing term.
Alex Booker (02:42):
That is Gary Simon. Gary is a designer, developer, and Scrimba teacher who once grew his freelance business from around 36K a year to 100K a year. Back in the early days of the pod, he came on to teach you how to do just that, and one part of it, you've guessed it, is building a personal brand online.
Gary Simon (03:05):
When it comes to somebody who's in the tech industry who's a designer or coder who wants to establish their own brand, well, what does that brand mean? Well, it's open to interpretation, but for your personal brand, you just have to ask yourself, what is it that makes you unique and how can I put it together in a package that personifies who I am as an individual? Do you have a color scheme for yourself? You don't have to necessarily.
Could your brand be really focused on your personality? Maybe you're really unique. Dev Ed on YouTube, he's a really unique guy and he puts in magic tricks in front-end development tutorials, so that's a part of a brand. Me personally, I don't think there's anything interesting about myself, that's for sure. I think I'm just, I'm hardcore in my consistency since 2014 and I've been uploading twice a week and I haven't stopped since.
Alex Booker (03:54):
Gary's focus is on YouTube, but you don't have to start there. Working on your personal brand is as easy as setting up a website or blog.
Gary Simon (04:02):
I personally advocate, whether you're a designer or a coder or front end or backend, you have a blog of some sort where you can write articles and you can write about your experiences, and that's a hard thing to be consistent about because I do portfolio reviews essentially and I do them live on my YouTube channel. I'll notice if there's a blog section, I'll click on it and the last post was from five years ago. So it's hard to keep up with, but if you can show that you can write and maybe you're doing tutorials even, that will build trust.
Alex Booker (04:34):
Now I know what you're thinking, but Alex, I'm just learning. I don't know what to write about. Well, here's the thing. It doesn't have to be perfect the first time around. Your blog or personal website can evolve with you. Madison Kanna is a developer and creator of Code Book Club. She's created a great community in its own rights and on her website, she shares actively about what she's learning, but if you went back just a few years, her website would look completely different.
Madison Kanna (05:04):
My mom actually bought madisonkanna.com when I was nine years old.
Alex Booker (05:09):
Madison Kanna (05:10):
And yeah, my parents really impressed that upon me at an early age that the internet and these online courses and having a personal brand were going to become really valuable over time, and so I remember even when I was 16, I was started blogging and thought it could be really important in the future. The blog that I had, it has since been deleted because it was absolutely random things. I went back and looked at it and it was talking about how I love to play Neopets every single day of my life.
Which doesn't sound like someone set up for success, but I was blogging about all the games I was obsessed with playing. I was blogging about dinosaurs at one point. I had a blog where I talk about how I'm interested in crime, which sounds very odd now that I think about it. It was vague about how I think crime is really interesting. I think it was because I wanted to go into being an FBI agent, I believe, but it vaguely sounds like I'm almost interested in breaking the law, to be honest. So lots of random things and from there, I worked on refining it over time.
Alex Booker (06:08):
We will talk more about what to write on in a few minutes, but first, we should address the other burning question. What should your website even look like? What if you're not a designer anyway? Can you get away with not building a website but just working on your social media presence or your GitHub profile?
Josh Comeau (06:27):
I haven't seen the results of spending a lot of time to put a lot of work in making your GitHub profile read me serve the same function. I imagine it could. It certainly doesn't have to be a portfolio site. What you want is that ability to hook someone in, tell a story about who you are, our what you're doing.
Alex Booker (06:41):
That is Josh Comeau. Last summer, he was on the pod to teach you how to create a portfolio website that both HR and other developers will love. By the way, take notes because he will give you lots of useful design resources.
Josh Comeau (06:56):
When you're talking about LinkedIn, you are beholden to the way LinkedIn structures things. Maybe you can rearrange the sections, but even if you can, you can't add two pages worth of content to a project without them tucking it behind a read more expander, and one of the cool things about building your own portfolio site is you can really tailor it to highlight the stuff you want to highlight, guide people through in the way that you want to. There's a design challenge there, which I know is tricky for a lot of developers.
Alex Booker (07:21):
What do you do if you're a developer, but you're not good at design?
Josh Comeau (07:24):
So the easiest thing is to steal something, and let me very quickly caveat that, steal it ethically. Find three or four sources of inspiration. Even actually, what I encourage people to do, template builders like Wix or Squarespace, you could use them, although I think you may as well build it yourself if it's good practice for the skillset you're trying to develop, but you can copy their templates because a lot of their templates are quite nice. Just rebuild it and try to change a few things. You don't want it to look like an exact clone because if anyone recognizes it, it's not a good look. Plus, you're building something custom.
You want it to look a little bit custom, but yeah, I think the quickest solution to building something that looks pretty good is to find three or four different sources of inspiration and take the layout from this one, the colors from this one, the typography styles from this other one. You still need to think a little bit critically in terms of trying to figure out if it looks good or not, but it's much, much, I don't want to say the term easier because it's still not easy, but it is less daunting than starting from a blank HTML file and trying to come up with something that looks professional. That at least gets you like 75% of the way there.
I wish we lived in a world where when you create a portfolio site for a development job, the design in terms of the UI design shouldn't matter because you're not applying for UI design jobs, but I think it's human nature that if you have two people applying and one of their portfolio sites looks really professional and well-designed, that influences people compared to another one that is choppy and looks as amateurish as you would expect for someone that doesn't have design skills designing a website, but yeah, no, I think that's, in my experience, I think that it has worked the most, two or three sources of inspiration and combining them to build something that still doesn't look too much like any of them, but still looks pretty professional.
Alex Booker (08:58):
I'm not a designer, I'm a developer and I've relied on that strategy for a long time. It's a great way for you to feel inspired and get started and only over time can you develop your own aesthetic style and creative ideas by which point you will be a designer. Do you have any advice on how to either improve your intuition when you're designing or at the very least, seek feedback that can help you make the tweaks you need for it to look cohesive and pleasant?
Josh Comeau (09:23):
The ideal case is if you have designers in your network, you can pinging them and be like, "Hey, can you critique this for me?" Of course, not everyone has that privilege. I like that you used the word intuition because that really is such an important thing and even if you're of the attitude that I'm a developer, I'm not a designer, I don't want to spend time learning a skill that isn't development, you might be surprised by how helpful a little bit of design intuition is as a front end developer specifically because when you work as a front end developer, you'll be given a design in Figma or Sketch or something like that. That design is never going to be...
At best, it's a 75% of the way that, and what I mean by that is if you're lucky, you'll get mobile, tablet, and desktop and you'll be given loading states maybe, but it's up to you to figure out how things should flex and grow and scale between those three fixed sizes. It's super common that designers will omit or forget to include loading states and error states. What happens when the data in the mock-up, which is all these small and nice little names, when it encounters real data where some people don't have a name field, some people have a name that's 125 characters. How do I fit that into the design?
Those are design questions and if you can build a bit of an intuition, it really helps with that because the alternative is every time you hit one of these situations, you have to pinging the designer and say like, "Hey, I'm stuck here," and then you're blocked waiting on them to get back to you and maybe they're not there right now, especially with everyone working remotely. They might be in a different time zone and they might not see your message until tomorrow. It's to the point now in my own career where I've never done any professional design work and I've never trained as a designer.
But I've built enough of an intuition just from working in development context and also as a developer with side projects needing to design them because I don't have a designer, that I've built up enough of an intuition now that in most cases, I can take an educated guess about, okay, especially if you understand the context behind the designs like what model the designer is using, you can say, okay, this is what I imagine I should do and you can unblock yourself and maybe 20% of the time, I'll get it wrong and the designer will say like, actually, we should do this instead, and that's fine. I can go back and change it, but because I have pretty good confidence in what I'm doing, I can just keep rolling with it.
Now in terms of how to develop that intuition, the honest answer is it just takes some time and if you're hoping to build something in the next couple of months, that's not really an option, but I would say start looking really critically at the things that you use every day. Pay attention to spacing. Pull up three or four different websites that are similar to yours and see how they spaced things and how it feels to you. I've noticed a lot of the time that font sizes and spaces are the things that are all over the place on developer portfolios. So if anything, you just steal those elements. Come up with your own layout, come up with your own colors, but then just steal the font size and the specific number of pixels between the headings and the paragraphs. That'll make such a big difference.
Alex Booker (12:04):
You're saying that a really great design tip is when in doubt, be consistent. Same fonts, same padding, same line heights. If you have images, maybe put them all in rectangles or in ovals. Try and use a consistent color palettes.
Josh Comeau (12:17):
Yeah. And just to make sure what I said is clear, steal the spacing from something else that you think looks good and there are tools that you can use like xScope is one. PixelSnap is one I discovered recently. It's a macOS exclusive, but what's cool about it is you toggle it on and then using contrast, it's able to draw the distance between two elements. So you move your cursor between the heading and the paragraph and it shows you there's 72 pixels between these two things.
Granted, with typography, it's a little bit tricky because it's giving you the distance between the bottom of the characters in the heading and the top of the characters in the paragraph, and on the web. There's like built-in spacing. You can't then take that 72 pixels and slap that in padding or margin, but yeah, that's be as precise as you think you can in this. Have your site next to some other site and then visually try and make sure that the spacing looks pretty close to identical because spacing in particular is just one of those things that it takes forever to build an intuition and no one's going to notice if you steal the spacing from some other site if everything else looks different.
Alex Booker (13:13):
You can't pattern that. Another good utility for non-designers is a font pair, which gives you Google fonts that pair well together. Another piece of advice I could share, I don't think ambitious developers want to hear it, but sometimes the right thing to do when you're not good at design is to actually lower your ambition a little bit. It's very nice and exciting to look at an awesome portfolio and think, mine needs to look like this to be competitive, but probably, you're looking at the portfolio of somebody with far more experience.
And what often happens in my experience helping new developers is that they underestimate what they can do in a couple of weeks, and what that leads to is analysis paralysis, procrastination. It never really gets done or you have to cut so many corners. It would've been better if you went with something in quite a minimal style. Do you think that if your portfolio doesn't look very good, I sometimes wonder if it hurts you more than it helps you because at the end of the day, every company is looking at you as a potential web developer? They're going to assume it's your best work, even though it might not be a fair thing to assume.
Josh Comeau (14:16):
It's a great question and I imagine it could. It makes sense to me. It probably depends on the company too. Like I mentioned earlier, there's two audiences you're appealing to. You're looking to appeal to developers and to HR folks. I would expect that when a developer is pulled into the hiring pipeline and told like, "Hey, we have this candidate. Here's their information, here's their resume, here's their portfolio site," maybe a developer would be able to look past that.
And if the content is really good, it still helps you more than it hurts, and I think the advice that you gave about keeping things minimal, it's true. My own blog is maybe a decent example of this. I put lots of little details in, but this is the third or fourth version of my blog. My first iteration did not look anywhere near as good as the one now.
Alex Booker (14:55):
Great word by the way, iterating, because the thing about developers is that we iterate on websites. It's not like a book or a movie. When it's done, it's done. The whole point is that you're meant to iterate on it.
Josh Comeau (15:06):
Alex Booker (15:06):
When does it make sense then to use a template? I certainly get that a template is a double-edged sword. On one hand, you're trying to stand out and if you're using a generic template, there's a chance you may be in the same cohort of applicants easy enough to mistake, and that could be a bad thing, but also if you're not particularly design orientated or maybe you're in a pinch, a template can be a great thing to lean on. What's your advice?
Josh Comeau (15:30):
I think it gets back to the idea of finding two or three templates that you like and mixing them together because it's true. There are probably three or four, in fact, when I was doing that thing where I asked for portfolio sites on Twitter, there were three or four people that had an identical website. They all just took the same source inspiration and copy pasted, or maybe they re-implemented it, but either way, it looked like pixel perfect, and you don't want that. That's not great. I meant to mention earlier, one of the reasons to focus and follow your advice on building something a little bit more minimal is that you don't need it to stand out.
You don't need it to be the most beautifully designed portfolio. That's not really the goal because you're applying for developer roles. You just want it to be well-designed enough that the design doesn't bring it down, that doesn't call attention in a bad way to it. Ultimately, it's probably not the worst thing in the world if you take a template and just run with it, but mix two of them together and make it a little bit unique. You also want to include some of your personality. If you're a particularly colorful or serious person, it's fine to make tweaks to let it be a little bit more personal to you, but the goal is just to make sure the design gets out of the way so that you're not distracting from the content, which is the important thing.
Jan Arsenovic (16:40):
Coming up, you have a website. Now what? First, I'd like to read some of your tweets about the podcast. Wait, Twitter changed its name to X yesterday. Are we still calling them tweets? Don't get me wrong, I don't think I want anything to do with your exes. I barely want anything to do with my own exes, even though my mother really likes one of them. I don't know which word to use. Are we X-ing now or are we still tweeting, but on the website, it's called x.com? I'm really confused. Anyway, on the platform formerly known as Twitter, Kasha Walsh wrote at Booker Codes.
Hello, just wanted to say thank you so much for the Scrimba podcast. It is so motivating and informative. I have to say that it keeps me going when I doubt myself. Thank you. Thank you for the kind words and good luck. Daniel at Mr. Giles1 is sharing his progress through 100 days of code. On day 53, he wrote got contact info from friends and family of two senior devs who are open to advice regarding the tech job search. Made some progress with free code camp and enjoyed the Scrimba podcast. Yeah, it's great seeing that people are doing 100 days of codes during the summer as well.
I kind of thought that everybody will be taking a break until September, but apparently, I was wrong. If you're doing 100 days of code and you're listening to the Scrimba podcast along the way, tweet about it, or sorry, X about it and join the community, and if you're feeling really supportive, please consider leaving us a rating or a review in your podcast app of choice. Currently, we have 4.9 out of five stars based on 73 ratings across different platforms, so come on. If you're enjoying the podcast, help us get to five stars. We're so close, and if you write a review, I will read it on the show, I promise, but for now, let's talk some more about personal branding.
Alex Booker (18:54):
So you've decided to make a website. Great decision, by the way. You've bought a domain, installed a blogging engine like WordPress or Ghost. Maybe you're just using Dev2 and you figured out what it all looks like. Now you only need content. Of course, your project should go there, but maybe that's not going to be enough. We've already talked about blogging. Many people think that they can only blog about the things that they are experts in, and that's probably why many developer blogs are very rarely updated. We're here to challenge that notion. Shawn Wang, also known as Swyx, is a writer, speaker, developer advocate, and a firm believer and big proponent of learning in public.
So instead of learning something in private and waiting until you're an expert, Swyx argues that you should talk about stuff while you are learning them and create what he dubbed a learning exhaust. You can write blogs, tutorials, or cheat sheets. You can ask and answer things in the Q&A format on Slack Overflow or Reddit. If you want, you can start a newsletter or even draw cartoons. Maybe if you're super brave, speak at a meetup or conference. Whatever your thing is, make the content you wish you had found a couple of months ago. Swyx keeps an almost daily dev blog written for no one else but himself. If anyone else finds it, that's just the bonus.
Shawn Wang (Swyx) (20:19):
It's a fundamental change to the way that you prove your interests and your skills. The traditional job hunt is done through, hey, I need a job now. I'm going to look at the available opportunities on a job board. I apply, I try to serialize my experience down to a single page resume, and then you hope that the other side has the deserialization algorithm to decode that, hey, you're actually someone worth interviewing, and a lot of people don't even make it past that stage, and I think that's a very weird funnel or a weird narrow waste in the whole relationship of your personal growth and the company's view of you.
And I think it's just better if you can find a way to broadcast what your interests are, build your skills in public, have people follow along, and when they have something that's suitable for you, they come to you instead of you going out to them. The business world is very familiar with this. It's called the concept of inbound marketing rather than outbound. By creating content, by sharing, these are the things I'm an expert in or you're building expertise in. You're not necessarily an expert yet, but you're just building expertise and as people come across things, they think of you because at the end of the day, all you need to do is just be first to mind on a particular topic and people will naturally reach out to you and that opens you up, actually.
Alex Booker (21:32):
Swyx has written a book, it has an entire chapter about this, and you can still get 30% off using coupon code Scrimba 30. There's a link in the show notes.
Shawn Wang (Swyx) (21:43):
There's a figure floating around that 80% of the jobs that are exist out there aren't actually formally advertised first. They just get sent out to friends, family, people already in the company. The only way you get those kinds of opportunities is by having some sort of reputation and learning in public is the best way to achieve that. The other thing that I think is underappreciated by people, people are very scared of what if my mistakes are out there and people think that I'm an idiot and I'm exposed? Everyone's been where you have been. You're not special in that way that you're especially bad at this. Everyone started out somewhere.
As long as you show the capability of growth, that's actually an even better quality than just coming out of the womb knowing everything. So I think some amount of humility and being able to diverse your identity from your work, when people criticize your work or when you can step back and look at your past work and say like, okay, it was bad for these reasons, that's how you know you've grown as a professional, as an individual, and finally, I think that the feedback loop involved in learning in public is very important to me in a sense that I will try my best to ship by a certain deadline, but I will ship so that I get feedback from other people and that feedback fuels the next thing.
And that helps you break the loop of just continually working on a side project and never shipping, which is a very familiar experience with a lot of developers. You try to reject perfectionism in favor of shipping and doing your best and then iterating after you've shipped based on the feedback that you get from other people, and people are incentivized because you respond to them, and if you are shown to be a good collaborator, then they will work with you in future projects as well, but also, once you've got gotten something wrong in public, you'll never get it wrong again because it's so embarrassing.
I think a lot of people, when they say they want to create content or they want to learn in public, they talk about how they want to give back to the community like their contribution is such a gift from God, and it's really not. Sometimes it is. Sometimes look, your contributions, as long as they help one person out there, it's very appreciated, and sometimes it doesn't have to come from an expert because they're so burdened by everything. Sometimes the best communicator of that knowledge is someone who just learned it because you can remember how it was like to not have that.
Alex Booker (23:46):
Cassidy Williams, CTO at Contenda refers to learning in public as feeding two birds with one scone.
Cassidy Williams (23:54):
So in terms of the content that I make, for example, let's just say I am doing a live stream and I might build a demo of some kind. As I'm building the demo, I'm engaging with people, I'm talking with people about how I'm building it and explaining some API or something, and I'm deploying into Netlify making it work. Then I might take that demo and put it on GitHub so that way, it's open source for people to see. Then I'll write a blog post that explains how that demo actually works. Then I might give a talk or two on how the demo works, how I built it and that sort of thing, and then I might record a podcast about that specific project.
And so it's making one specific piece of work, but being able to just use it a ton to make a bunch of other pieces of content. I code a lot, but a lot of times, it's very similar types of projects, but I'll reuse certain types of code, certain types of ideas, and then build a bunch of content around those ideas. I think a lot of the stuff that I do can really help people who are early in the industry because it's all about learning in public and being vulnerable in public and putting your name out there, and there's plenty of blog posts out in the world that say learn in public.
And so all it really is is as you learn a topic, write it down, whether you're tweeting it, putting it on LinkedIn, putting it in a blog post, putting it somewhere, just make sure that someone knows that you learned about it, even if it's just one person, and slowly but surely, as you are learning different things and building different projects and growing, you could use the hashtag 100 days of code on Twitter. As you put up all of this stuff, you might be able to write blog posts on dev.to. Heck, you might be able to make a screencast on Scrimba.
As you do all of these things, more and more people will start to notice the skills that you have, and when you are applying for a job, you have a track record and so when someone starts to Google you or as they're looking at your resume, you can say, look at this series of tweets, look at this series of blog posts, look at these projects that I've built, look at these screencasts that I've made, that sort of thing, and because you have a paper trail of all the things that you've done, it shows that you haven't just been farting around, took an online course, and now you're trying to get a job. You've been learning over time and people know about it and there's evidence of it all over the internet.
Alex Booker (26:18):
Okay, but how can you make sure you're actually learning in public and not becoming a full-time content creator?
Shawn Wang (Swyx) (26:24):
Learning is best when it's informed by you actually trying to do things, not trying to get likes, and people can really smell when you are just trying to be a full-time influencer. Sometimes it works. I think definitely, the numbers will skew accordingly that way, but you are selling yourself out in a certain way and the people who look for true authenticity will really detect that, and ultimately, how many people are you really going to work with in your life? Maybe probably under 500, let's call it that. You don't actually need that wide of a base. You just need a very strong relationship with high quality people that you have a really fulfilling time working with.
So the people who aim for hundreds of thousands and millions of followers, these are just faceless masses that you'll never meet and they bother you anyway. Don't optimize for the lowest common denominator content because they're not going to add materially to your life in any sense. I definitely try to correct against this full-time creator bias and try to encourage people to work on real projects. In fact, as much as I'm known for Learning in Public, I have another chapter which people don't talk about called Learning in Private, and the first thing it says in there is most of the time, you should not be learning in public.
And that's true because nobody wants to see you livestream every second of your day. They just want to see the best, the aha moments and the today I learns, and that, you can definitely provide as learning exhaust. I just want to make it as automatic as breathing. You don't really think to breathe. Well, now you do because I just talked about it, but when you learn something, your automatic reaction is to note it down somewhere for yourself, for other people who are following along on your journey, and that's why I talk about interns of learning exhaust and this is borrowed from a TED Talk I saw on creative exhaust, which is a similar concept for designers and artists.
We talked a little bit about forms of learning in public, so I think blog posts and tweets and stuff like that are really slow engagement forms. There are four kinds of learning gears. This is another concept which I talk about in the book, and that's a very low level gear of exploring. You're not really committed to any direction yet and you're just blogging out as you go along. It's more for yourself than for other people, but if you want to, you can kick it up a notch to other gears, like connectors are people who try to connect different domains and to try to connect ideas. So you start putting out more polished pieces of content like tutorials and cheat sheets and workshops and talks.
And these are longer term commitments on the order of weeks and months where you build something that's a lot more polished and a lot more condensed to give real value for people who are coming across the topic for the first time, and that is not something where you're learning as you go. That's something where you sum up everything that you've learned and you present it in a more polished form, and that polish actually matters a lot for people who are confused by all the nuance and the false starts sometimes. Sometimes you think you've learned something, you go down one direction and you're like, oh no, I have to go back. The polish is where you cut off all those false starts and you present in a smooth path, just like how Scrimba presents the smooth career path.
In reality, it's never as easy or as well-defined as that, but because by defining it for other people, you provide some kind of blessed learning path that other people can at least base their journeys off of and that's very powerful as well. The highest form or highest gear, which I tend to drive people towards, is this miner gear where you struck gold and you're just digging deeper and deeper into that topic that you know is valuable to other people instead of having to put yourself out there. I don't have to show up on podcasts anymore. I don't have to apply to speak at a conference.
People will come to join you because they believe in your mission and you are doing something that no one else is doing. So I really look up to people like the builders, the people who founded Scrimba and was his co-founder, the people who start open source frameworks like Evan Yu at UJS, these are people who are just building their thing and everyone comes out to help them. So it's a form of learning in public that is just very mission driven and no longer very broad. You could be doing a thousand other things and you probably could be making more money doing other things too.
But you're just so driven and so keen on making this idea into reality that you just drop everything to do this one thing. I've just drawn a path from this extreme breath where you go a mile wide and an inch deep as an explorer and you can step it up eventually as you narrow in on what you're focused on into a miner where you just have found the thing that you want to be known for for your entire career, and just do that and be that person and be that expert in the world that everyone looks to.
Alex Booker (30:52):
So with all this in mind, what should your new website look like, and if you also display your portfolio projects on your website, what is the best way to present them? Here's Josh.
Josh Comeau (31:02):
There's two audiences you're appealing to. You're looking to appeal to developers and to HR folks. The layout that I like that I think ticks all the boxes that I personally think are important. I like to have some sort of hero, some sort of main thing that you are shown when you first load. Often, that can include a photo of yourself if you're comfortable with that, your name, and then some brief, maybe four or five sentence description of who you are, what you're looking for, and this is where I think you can have a bit of your personality shine through. You can really make this custom to the sort of person you are and the sort of work you're looking to do, and below that, I like to have projects, and typically, what I like to do is I like to have either a grid or a list where you have, this part is fairly typical.
Maybe you have a screenshot or a logo or something, the project name, a short description, but then critically, a link to view more information about it because I think every project should have its own page and that page should go into deeper detail about how the project works. In general, I think you should have between two and five projects. You don't want to put everything you've ever made on that because realistically, people are going to look at one, maybe two things, and they're going to pick randomly. If you built a calculator in half an hour and it's your 17th item in the list, that might be the only thing someone sees, which is not great. So yeah, two to five, something like that, projects and the thing, and then below that, you can have contact information.
There's ways to find projects that are a little bit more personal to you, and then when it comes to describing them in the page, you can talk about why you decided to build this thing, and it doesn't have to be Shakespearean quality. It doesn't have to be literally the same way that a fiction book would be. It just has to be a few paragraphs that talk about what is this thing, why did you build it, what did you learn building it, and I know that's another question that's hard for people to learn because it's part of development. We all hit random error message that we have to Google and find solutions for.
If we were building a to-do list application, then there are parts of that that are difficult. How do you track the state across this application? How do you manage when you tick the thing? How does it get updated? Even if it's not a novel problem that you're solving, you can still talk about your approach and especially if you had any refactoring, if you built something and then you realize later, there's a better way for me to build it, that's like the perfect thing to put in this page because that's like gold in the eyes of the developers that are coming and looking at this and trying to figure out if you'd be a good addition to their team.
Alex Booker (33:19):
Maybe by now, you're convinced in the power of creating a personal brand, learning in public, and sharing your progress. It's incredibly exciting, but we accept it can also be a little bit intimidating. That's when I like to remember Cassidy's advice, which is that you should never be afraid of not knowing something.
Cassidy Williams (33:37):
It's nerve wracking to put yourself out there. I don't know if you've ever spoken with Brandon West. He's a DevRel professional. He's written books on this and stuff, and he actually just did a tweet this morning where it said the difference between a developer and a senior developer is that the senior developer says I don't know more. It's a very backwards thing to think about at first, but the most senior developers I know and the most senior folks in their careers that I know are the ones who are willing to say, "I don't know. I haven't thought about that," and then they ask enough questions to get that answered for them and move on.
And when you're a junior developer, it's very nerve wracking to do that because you're trying to prove yourself and you're trying to be that person where you can move ahead in your career and be on the right track, and if you ask too many questions, they might think that you don't really know what you're doing, and I think once you get to a certain point in your career, you just stop caring about what people think and you just go for it. I remember not just in the public development world, but in academia and stuff, I would occasionally watch presentations from PhD students and master's students.
And stuff for their thesis, and the people in the audience who were the most senior and tenured professors, they were the ones who asked the most questions every single time consistently. I had to force that into my brain because when I was first in the industry, I wanted to be like, I wanted to be in charge. I wanted to prove myself, and so I didn't ask a lot of questions and I do think that slowed me down in general. Sometimes even myself, I'll be thinking, I should know this. I should know this. Oh my gosh, I've been coding for so long and I don't know this, but people Google things all the time. People look at Stack Overflow all the time.
Alex Booker (35:20):
And if all of this still sounds like a lot, just start small.
Shawn Wang (Swyx) (35:24):
The prototypical action is to write, is to write tutorials, is to write blog posts. Just basically try to write for yourself three months ago. Don't try to establish thought leadership and publish the Great American novel or break the industry. You'll get there. Just warm up first. As you have that regular writing habit, you figure out the stuff that you're good at and the stuff that other people are interested in.
Understanding where you can be relevant to other people's interests is probably a skill that just needs to be developed over time. If you focus too much on others, then you will be very burnt out because there's nothing internally that's keeping you going, and if you focus too much on yourself, then no one else externally has any incentive to care what you say. So you need to balance it a little bit with a bit of yourself intersection with others. That's definitely a balancing line that sometimes I miss it and sometimes I really nail it, and it's really wonderful and gratifying when you nail it.
Jan Arsenovic (36:26):
I'll be redoing my websites over the summer and I know I'll be using a lot of tips from this episode even though I'm not a developer. That was the Scrimba podcast, episode 125. This episode uses clips from previously published interviews. If you'd like to listen to the full interviews, I will link all of them in the show notes. If you made it this far, subscribe. We are a weekly show and you can find us wherever you listen to podcasts. The Scrimba podcast is hosted by Alex Booker. You can find his Twitter handle, sorry, his X handle in the show notes. There is no way this is ever going to sound good. This episode was written and produced by me. I'm Jan, the producer, and you can also X at me if I have butchered your name in the mid-roll. Thanks for listening, and we'll be back next Tuesday.