Forem: Sam Julien

How to Finish What You Start

Sam Julien — Tue, 29 Dec 2020 00:18:04 +0000

Tell me you've done this before:

Get an amazing idea
Buy a sweet new domain
Tweet about your awesome new project
git init
Um...uh...do some planning?
You know what, I'm really busy right now.
I really need to work on that...
(Secretly abandons dreams)

Why do we do this!?

The simple answer is of course that having ideas is way more fun than seeing them through. That would be adequate if it wasn't so discouraging to repeat this cycle all the time. It starts to creep from "I have a bunch of unfinished projects" to "I'm just not the kind of person who finishes things" and that can be really disheartening.

In this article, we're going to talk about finishing what you start. We'll talk about:

Mindsets that block us
Slimming down your project list
How to move more to the done column (hint: it's not "work harder")

Let's dig in!

Mindsets Blocking Us from Finishing Projects

Like most behaviors, un-finishing (a word I just made up) stems from our beliefs about ourselves. Here are three that I've wrestled with over time:

Fear of failure: I'll never succeed. I'm not good enough.
Fear of success: What happens if this takes off? What if I get 1 million requests per second and I didn't plan for that? What if people call me a phony?
Perfectionism: I have to make this perfect before anyone ever sees it.

Any of those resonate with you? These three have definitely kept me from hitting the publish button or starting to build out an idea I had.

What do we do about this? I could sit here and give you logical arguments as to why each of these mindsets is wrong. The problem is that we're not logical with ourselves when we feel these things. I'm never able to out-argue my emotions. My brain can rationalize any left-field self-loathing that comes my way if I'm in the wrong headspace.

What helps overcome all of these mindsets is action, which translates into experience.

If you start getting some wins under your belt, you'll feel less like a failure.
If you do rocket to success, you'll learn how to handle it and how to ask for help from people who've been there. (And if someone calls you a phony, you'll deal with it and move on with your life.)
If you start shipping things a little bit earlier than you feel comfortable, you'll start realizing that you are your harshest critic -- and end up helping a lot more people than you realize.

We believe a lot of stories about ourselves that we've told and re-told a million times. Some of them are accurate, but most of them aren't. Arguing with the story doesn't work very well, but living out a different one will change the way you see yourself.

To that end, let's dig into the practical and help you rack up some wins.

Ideas vs. Projects

The first step to finishing more of what you start is reducing your idea backlog. Repeat after me:

Not every idea you have needs to be executed.

Put another way: Not every idea needs to become a project.

Some ideas are good, some...aren't. What you need is a good way to capture these ideas and decide which ones are worth working on and which aren't.

You can get really sophisticated with this and build a system around it, but for now, why don't you just open a text editor and write out a list of every unfinished idea or project you have? (Or just set a timer for 15 minutes if you're a modern DaVinci.)

Triaging Ideas

Do you have your list of ideas and projects? Great. Now you need to process them. For each project, you're going to give it one of three outcomes:

Drop it: It seemed like a good idea at the time, but it's just not, like the Nintendo Virtual Boy. Just let these go.
Defer it: Possibly a good idea, but you don't have the time or resources to work on it right now. Put these in an Ideas Archive with your notes, links, and your most recent thoughts about the project (e.g. "I don't know enough about the Go ecosystem yet to know if this is worth doing."). Your Ideas Archive could be in text or Markdown files or an app like Notion, Obsidian, or Evernote. Don't overthink it; just get started.
Do it: A good idea that also has the potential to either be profitable, build an audience, help a lot of people, or take you to the next level of your career.

Try to narrow that big initial list down to just a handful of viable ideas. You're looking for the ones that you have the time and resources to work on right now. Not all at once, just at all; if you were to pick one, it might feel a little overwhelming but not impossible.

[Source]

(Okay, in truth I actually kind of liked the Virtual Boy, but I think it was because as a 10-year-old kid it seemed futuristic and cool. How was I supposed to know it was a flop?)

JPS: Just Pick Something

Okay, so let's say you've got a clean list of 3-5 solid ideas. They seem equally valuable with regard to profit, career growth, fun, or impact. How do you pick?

The best thing to do here is the JPS strategy: Just Pick Something. Throw a dart at the list, randomly generate a number, or play pin-the-tail-on-the-idea. Just pick something. Why? A few different things might happen when you pick something and start working on it:

You might start working on it and kinda hate it. Hate might be too strong. Maybe you just get bored of it or it just doesn't "spark joy" like you thought it would. That's some helpful data. Just drop or defer the idea and move to the next one. Now you know!
You might use it as a training ground to learn a bunch of skills. Sometimes a project isn't a dud, but it's also not a huge success. That's okay too. Getting practice setting up an app or landing page, building an email list, writing, or making architecture decisions are intrinsically valuable, regardless of the topic. Even if your original idea never takes off, you're still better off for trying.
You might come to love the project and use it as a springboard for other ideas. I didn't make my ngUpgrade course out of a passion for large scale refactoring. 😅 I made it because it was a way I could help other people escape some of the pain and suffering I went through. But a funny thing happened: I became passionate about that work. Suddenly people were coming up to me at conferences thanking me for saving them a bunch of time and headache. I started bonding with students and became emotionally invested in their success. This led to other opportunities like consulting and speaking (including a life-changing trip to Finland). All of that came from picking an idea in front of me that had good potential and following through with it as best I could.

You may be thinking, "But Sam, if I pick something that I end up disliking or fails, didn't I just waste a bunch of time?" That depends on how you big you make the project.

Tiny Experiments: Reducing Your Scope

Now that you've picked something, it's time to reduce its scope so you can actually ship something into the world. Take the dream and scale it way down to a Minimum Viable Product. This works equally well for content and dev projects, by the way. A few examples:

Dream: A global AirBnB for dogs
- MVP: Basic website, forum (Discourse), and payment system (Stripe)
Dream: Ultimate guide to full stack TypeScript apps
- MVP: A single article on setting up Express with TypeScript
Dream: Learn Golang
- MVP: Build and deploy first tiny app

So there you have it: the secret to getting more done is lowering your standards. 😅 No, no, there's a reason for this. Scoping down projects is all about validation. Remember when I mentioned risk? Let's talk about that.

Validating an Idea

Your goal with a new project isn't to get 100k users, make a million dollars, or change the planet. Your goal is to validate your idea with a few people. This might mean comments on some content, a kind message from someone, or a few people (who aren't related to you) buying a product or service you put out.

You're looking for quality over quantity here, because if something resonates with or helps a few people, it will likely scale to bigger numbers as you put more effort into creating and promoting the project.

Validating an idea saves you a lot of time in the long run. Imagine secretly building a massive project or piece of content only to have it flop. This happens a lot and it's very hard to learn from these. Was it the topic? The format? The way you marketed it? The platform you used?

Validating tiny experiments lets you get feedback and improve. If your tiny experiment gets zero traction, you could tweak a few things and try again or you could drop or defer it.

Improving What's There

Once the idea is validated, you can take the next steps: build the next feature, write the next article, or update and improve to release the next version. As you continue to build a body of work in an area, the results will compound. You'll be able to cross-reference material you've created, build a network of people who are interested in the same topic, and establish yourself as a credible source and helpful community member.

I used this same "validate and iterate" process to write Getting Started in Developer Relations. I had a hunch that a book like that would get a good response. Rather than agonize over every decision to create a perfect book, I time-boxed the initial production to 2 weeks. Granted, I have a lot of writing and product experience at this point, so I wasn't totally starting from scratch, but I was able to get something I was proud of out into the world and see what kind of response it would get. To my delight, it's been a great response!

Now that I know the idea is valid, I am working on a revised and expanded version that incorporates feedback I've gotten from readers.

You could also choose to abandon a successful experiment. Maybe you got what you wanted out of it or it wasn't as fulfilling as you thought it would be. Either way, you gave it a shot, created something, and grew.

How to Go Deeper

This "tiny experiment" framework is helpful everywhere, not just with dev or content. I've used it for everything from nutrition to home improvement projects.

If you're curious where this kind of thing comes from, there are a few answers, but one I'll leave you with is called construal level theory in social psychology. This is basically saying (as I understand it) that the farther away something is (whether physically, psychologically, chronologically, or otherwise), the more abstract it appears. This is why we don't plan for retirement soon enough. It's also why "start a 1 million user SaaS" isn't a great project; if you've never done that before, you have no idea what the steps are to get there. It feels abstract and complex so you'll likely abandon it. Here's a great article on that subject by a research scientist named Jude King.

Try this framework out and see if it works for you. I've used it in all kinds of areas of my life, not just developer or dev rel projects. As always, I'd love to hear if it's helpful for you and how you've added your own spin to it!

This article began its life as an issue of the Developer Microskills Newsletter. Each week, I send out a practical, actionable way to improve as a developer and developer advocate. If you found this article helpful, head over to the sign up page and hop on!

Where to Start with AWS as a Developer

Sam Julien — Tue, 27 Oct 2020 16:02:56 +0000

This article originally appeared on my website. Check it out for more dev tips and practical career advice for switching to tech and getting into dev rel.

AWS (Amazon Web Services) is massive. At the time I'm writing this, there are 175 different services on AWS! This surface area is bigger than most things you might try to learn as a developer. So where do you get started? How do you start chipping away at this complex elephant, but do it in a way that's practical?

I'm a few months in to my AWS journey and I wanted to share what concepts and resources I've found helpful so far. I resisted getting into AWS for a while because of its complexity. Any time I would log into AWS, my eyes would glaze over and my head would spin.

I realized, though, that ignoring AWS for much longer will be to my detriment. AWS is dominating the hundred billion dollar cloud infrastructure and computing market:

Source

Because of this, AWS certifications are in very high demand. I decided a few months ago that it's time for me to step up and at least get the Cloud Practitioner certification, and probably others like the Solutions Architect Associate.

Big AWS Concepts for Developers

Let's lay down a couple of definitions to help you as you progress in your AWS education.

First, what are cloud computing and cloud infrastructure? In short, this means that instead of you having to physically set up servers and networks in your garage or at your company, you "rent" these from Amazon. Everything you might want to do to run a website — the hardware that runs the server, the database, the storage that holds the frontend and static files, and the domain name configuration — can be done using AWS's networking and computing resources.

Why does this matter? The main reason is scalability: the ability to grow based on demand. AWS alleviates both the cost and logistics of scaling a service or business. Imagine you're running an online store for dog toys on a single server in your garage (you probably bought it on eBay). Suddenly, Thoughts of Dog tweets about your store and your traffic spikes by twenty times as millions of people try to buy your bespoke artisan chew toys. What's going to happen? Most likely your server will crash due to that much demand. You're frantically searching eBay for another server and some networking equipment, but it will likely cost you a couple thousand bucks and several days to upgrade your server or add additional servers to your network. Ouch! (Incidentally, a show that demonstrates this dilemma perfectly is Halt and Catch Fire, which is about startups in the 80s.)

Services like AWS, Azure, and Google Cloud Platform came along and revolutionized the industry. Now instead of needing to buy a brand new server, you can click a button and immediately grow your infrastructure. Even better, you can automatically grow and shrink your infrastructure as demand for your site or service fluctuates. This helps keeps costs more predictable and spreads them out over time instead of all at once with big hardware purchases.

Key AWS Services for Developers

When approaching AWS as a developer, there are a few of the core services that you'll likely encounter right away, so here's a quick overview of those:

Lambda: Serverless functions are kind of a gateway for developers into AWS and cloud infrastructure. In AWS, Lambda is the service that runs these functions. Serverless functions let you perform calculations or access databases without having a physical server.
S3: S3 stands for Simple Storage Service. This is where you host static files such as HTML, images, or videos.
Route 53: Route 53 is where you set up DNS for domain names. "Route" is a reference to US Route 66 and "53" is a reference to TCP or UDP port 53, where DNS server requests are addressed.
EC2: Elastic Compute Cloud (EC2) is where you run servers. If you're looking to run an API or a traditional web app using something like Node or Nest, this is what you want. EC2 costs can add up quick, so be careful experimenting with these.
RDS: RDS stands for Relational Database Service so this is where you'll set up databases such as MySQL, PostgreSQL, and Microsoft SQL Server.
DynamoDB: DynamoDB is Amazon's No SQL solution similar to MongoDB.
Amplify: Amplify is a platform for building full stack apps quickly. The Amplify Framework consists of 3 components including libraries, UI components, and a CLI toolchain, while the Amplify Console is a static web hosting service.

These are the core services I would focus on as a developer getting started with AWS. There are many, many more services relevant to developers, but getting a handle on the basics of these will get you quite a long way.

AWS Pitfalls for Developers

The two main pitfalls you might run into as you learn AWS (other than its sheer complexity) are billing and identity and access management (IAM).

AWS is not free to use, though there is a free tier and some services are free. Usually these costs are minor for short periods of time, but beware: if you run through a tutorial and then forget to clean up after yourself, you might face a big bill at the end of the month! Be sure to know what costs you're incurring as you do tutorials and try to shut down and delete anything you don't need when you're finished. AWS also lets you create billing alerts that will email you when you've hit a threshold. Here's a great egghead collection on AWS cost management that will help a lot.

The other really sticky area in AWS is security. Identity and Access Management (IAM) in AWS is extremely complex. There are many layers of permissions for each service, user, and group. Most tutorials will help you navigate the basic set up that you will need to get things done. Be careful that you're not leaving yourself open to big vulnerabilities as you learn. Not only does that open the door to data theft, but it could also result in huge bills if someone gets a hold of your root account. This doc is kind of scary, but you're going to want to get familiar with security best practices in AWS little by little. At the very least, secure your root account and enable MFA.

For the sake of both billing and IAM, you will likely want to avoid using your employer's AWS account to learn. If your job is the motivation for learning AWS, work with your company on creating a sandboxed account with a given budget.

Overview of AWS Certifications

While not all certifications in tech are created equal, AWS certifications are extremely valuable. They're designed to minimize false positives and fairly rigorous, so employers know they can use them as a solid benchmark of knowledge. This means they can add some zeroes to your paycheck and set you apart from the average developer.

There are many different AWS certifications, so let's break down what the options are.

The Cloud Practicioner exam is considered a Foundational exam recommended for people with 6 months of fundamental AWS knowledge. It's high-level and not super technical, but gets your feet with AWS.

From there, there are three Associate level exams, recommended for people with 1 year of experience solving problems and implementing solutions using AWS. These exams have broad scope but shallow depth and break into three paths: Architect, Operations, and Developer. The three exams are:

From there, there are two Professional certifications, recommended for people with 2 years of comprehensive experience designing, operating, and troubleshooting solutions using AWS. These exams have broader scope and are quite deep. The Architect path remains, but Developer and Operations combine into DevOps. The two exams are:

There are also six Specialty exams, which are very narrow in scope but very deep:

I decided to get some of these certifications as a way to guarantee that I will actually set aside the time to learn some AWS and have something to show for it. My plan is to get the Cloud Practicioner and then the Solutions Architect Associate. Why not the Developer Associate first? Well, my understanding is that the Solutions Architect Associate is more comphrensive than the Developer Associate, and thus it's easier to get the Developer Associate after getting the Solutions Architect Associate. It also sets you up to get the Solutions Architect Professional, which is extremely difficult and highly coveted (and thus should come with a big pay raise!). The SA-P requires the SA-A, so it makes sense to go that route. I'll update this article when I've got some results.

AWS Resources for Developers

There are boatloads of resources for learning AWS out there. Some are geared towards infrastructure and networking folks, some are geared towards database admins, some for security teams, and others towards developers. Here are the key resources I've been using and a variety of others I've found useful.

My Essential AWS Resources

I've found myself relying pretty heavily on these resources in my own AWS journey:

A Cloud Guru: A Cloud Guru is hands down the single best resources out there for learning AWS and just about any other cloud technology. I am honestly blown away. Just the AWS Certification Preparation Guide is worth the cost of admission. I'm working my way through the Developer Learning Path and about halfway through the Cloud Practitioner 2020 course. I've also used A Cloud Guru a ton for work whenever I've needed to look up terms or concepts I don't understand. I had a big annoying run-in with VPCs and private networks and A Cloud Guru seriously came to my rescue.
Cloud Newbies Discord: This is a Discord server founded by Hiroko Nishimura, creator of AWS Newbies (which is another great site full of articles, books, and exam tips). It is immensely helpful to have a welcoming and friendly community of people with whom to learn. The server has different channels for different cloud technologies and certifications, and the community ranges from total beginners to industry experts. I can't recommend it enough!
Blog by Danny Steenman: Danny Steenman is an AWS consultant and is putting out some amazing resources on AWS. I have his complete guide to passing the Cloud Practicioner exam bookmarked and refer back to it regularly.
egghead resources by Tomasz Łakomy: Tomasz Łakomy is a big inspiration for me to go on my own AWS journey. I've been working my way through the egghead lessons and courses he's been making on AWS (like this course on the Cloud Development Kit and this collection on the serverless application model).

Other Helpful AWS Resources for Devs

Here are some other very helpful resources I've found for learning AWS. I don't refer to these as regularly, but that's partially because my focus is on the Cloud Practicioner exam right now.

AWS Cloud Practitioner Essentials: This is the official training course from AWS. It's free, but it's pretty dry and the course player isn't very sophisticated (you can't speed it up or slow it down, for instance).
AWS Resources: A curated list of AWS resources to prepare for the AWS Certifications by Leonardo Federico.
What is the best resource for learning AWS?: Somewhat click-baity but useful article compiling AWS certification prep courses.
The Burning Monk: Fantastic site with a bunch of resources on serverless by Yan Cui
Official YouTube channel of AWS Serverless
egghead resources by Nader Dabit: Nader Dabit is pretty incredible, and he has tons of great lessons and courses on egghead about things like Amplify and AppSync.
Full Stack Serverless by Nader Dabit: This is Nader's recent book on serverless. I haven't read it yet myself, but I mean, it's Nader, I'm sure it's amazing.
Awesome DynamoDB: A handy list of resources for getting up to speed on modeling, operating, and using Amazon DynamoDB.
The DynamoDB Book: Highly recommended book by Alex DeBrie.
AWS Amplify Getting Started Guide: Great tool for getting up and running quickly with Amplify. Pick your platform and get a full stack tutorial from set up to deployment!

Conclusion

In this article, we've talked about how to get started learning AWS as a developer. We've covered big AWS concepts, key AWS services for devs, common pitfalls, and a whole host of resources. I hope you've found it all helpful! I'm still a newbie (hooray for learning in public!), so reach out to me on Twitter if I've missed your favorite resource or if you've found anything particularly useful.

If you're trying to level up your developer career through writing and speaking or hoping to become a developer advocate, hop on my email newsletter and check out my book Getting Started in Developer Relations.

See you next time!

Managing Time as a Developer Advocate (Without Losing Your Mind)

Sam Julien — Fri, 22 May 2020 22:35:44 +0000

I moved from regular full stack web development (C# and JavaScript, mostly Angular) to the world of content, developer relations, and developer advocacy in August 2018 when I joined Auth0. It's a lot of fun, but no one tells you just how much stuff there is to do. At any given time, I could be:

Writing a blog post
Answering questions on Twitter, Slack, Discord, or various Discourse forums
Making videos, either as a side hustle or for work
Figuring out how to integrate Auth0 with X language or Y framework
Building and improving programs like Auth0 Ambassadors
Collaborating with other companies on content
Streaming
Building a talk
Applying to events
Giving a talk (whether in person or online)
Appearing on a podcast
Working with other teams in the company (like the SDK team or product marketing teams) to provide developer feedback and improve the product

It can be dizzying! Without some good systems in place, it would be incredibly easy to work all the time. In fact, that's how I was starting to feel as I finished my first year. I felt like someone could wake me up in the middle of the night and my first response would be to start typing at an invisible computer or give a talk to the chickens.

I'm about 18 months into this and I feel like I'm finally starting to get some traction on prioritizing and being productive without losing my mind. So, in this article, I'm going to write out what's been working for me lately in my unending quest to balance life and dev rel. I don't pretend to have all the answers here, but I do hope I can save you some time.

My favorite way to write about what I've been learning is by first laying out some "cloud level" overarching principles that I've been noticing and then getting down to the nitty-gritty "street level" strategies and tactics that are working for me. As always, this is the stuff that has worked for me. Adjust to suit your own needs and personality!

Note: I'm just going to use the term "dev rel" from here on out for convenience, but this could be any iteration of developer advocacy, evangelism, content, community, or anything else. Think of it as a synonym for "that part of being a developer that involves building relationships and creating content," whether that's your full time job or a side gig.

Principles for Dev Rel Sanity

As I've moved through this last 18 months, I've picked up on some high-level principles that are making my life better. Think of them as signposts along the road: they don't tell you exactly how to get to your next destination, but they point you in the right direction if you pay attention to them.

Principle 1: Dev rel is a new set of skills to learn — embrace it!

When you first transition to dev rel, it can be incredibly overwhelming. Most of the time, the reason we have moved into dev rel is because we were reasonably good at our engineering jobs but wanted to do more teaching and community-building. Suddenly, we've gone from "competent engineer" to "brand new developer advocate" and that sucks. This brings me to the first principle I want you to remember: dev rel is a new set of skills you can learn.

You are once again a beginner! You're back at square one (or square zero since we're all nerds here). If you feel totally overwhelmed or like you suck at your job, this is not because something is wrong with you as a person — it's because you need to learn and practice a new set of skills! Once I realized that, I felt so much better. So, first and foremost, cut yourself some slack (not Slack)!

The real magic comes when you not only accept that reality, but learn to embrace it. It's not that often in life that we get to learn new skills (though as developers we are incredibly lucky in that way). New skills mean new opportunities for creativity, new ways of looking at things, and new relationships. And that feeling of discomfort and discontent? That's growth as a human! Growth is good!

Principle 2: Focus on shipping and improving instead of waiting for perfection.

Perfection is the enemy of getting things done, but this seems to be especially true for dev rel. It's really easy to start a dozen projects, blog articles, video course outlines, and open source libraries — it's way harder to finish them. Why is that? Often it's because we like the idea of a hypothetical, perfect version of something more than the reality of the hard work it takes to execute something. When we go to work on that project, we get so overwhelmed by the disparity between our Perfect Vision and the blank page that we give up and go back to daydreaming.

This is a great way to get fired. It's way better for your job and your mental health to build and ship something — no matter how small — so you can start getting feedback, achieving some results, and improving on it. I love how Amy Hoy and Alex Hillman call this stacking bricks.

A good rule of thumb here is to ship something when it's 80% done and you're stll a little bit embarrassed about it. You can always improve on it later!

Principle 3: Don't try to automate too quickly.

I don't know if this is a developer thing, but I have a tendency to overcomplicate things and try to automate them way too quickly. This usually comes from a desire to be efficient or elegant in my implementation so I (naively) add (unnecessary) complexity. I'm sure you know what I'm talking about: after six months or a year, you come back to the code you wrote and realize you can drastically simplify it. Why is that? It's because you know what's important and what's not due to experience.

The same is true with dev rel. My first response to being overwhelmed was to TRY EVERYTHING and THROW EVERYTHING AT THE WALL:

Download all the productivity apps!
Set up complex email filtering!
Buy all the gear!
Over-engineer systems to automate everything!

That was a quick road to burnout because I was giving myself way too much overhead. Instead, what I've learned is to go slow now in order to go fast later. I needed to slow down and figure out what was bringing the biggest return in order to find the ways I could systematize and automate it.

Incidentally, I went through this exact same cycle when I was learning about camping, hiking, and backpacking. I overcomplicated things and, over time, watched as the gear I needed eventually shrank to exactly what I needed, when I needed it.

As you venture forth in dev rel, look for those three signposts to keep you on the right path:

Be kind to yourself and embrace that you're learning new skills
Focus on shipping and improving
Resist premature automation

Strategies for Managing Time as a Developer Advocate

Okay, so we've got some principles. Let's get down to the street-level implementation for daily work.

Strategy 1: Determine your priorities.

Given that we could be doing a million different things at literally any time of day or night, it becomes impossible to do everything. You have to create some sort of decision matrix or rubric for prioritizing. If you've got a boss, I'd highly recommend you talk this out. Define priorities and "big wins." When Kim Maida was my boss, we did just that, and here's what we came up with.

Prioritize projects that:

Other people depend on (e.g. that internal tool that other people need)
Involve collaboration with other team members or internal teams (a lot of developer advocacy work goes here)
Involve collaboration with other companies or create those opportunities (streams, joint blog posts, open source collaboration, etc)
Create opportunities for other people to learn or advance their career (programs like Auth0 Guest Authors run by Kapehe and Auth0 Ambasadors)

Notice the trend? It's other people, which is really what this whole job is about. I had lunch with Jason Lengstorf in Portland a few months back and he gave me the exact same advice: collaborate as much as possible. Dev rel can be extremely isolated at times, especially when working remote and traveling alone. Collaboration not only dramatically increases your impact (and thus helps more people), it also keeps you from losing your mind.

Of course, there are tasks you must do alone:

CFPs, building solo talks
Experimenting with new tech
Working on your "personal brand" (I hate this term because it's so overused, but here I mean your personal site and email)
Creating most types of content
Learning new things to keep your engineering skills sharp

How do we prioritize and schedule all that? I'm glad you asked!

Strategy 2: Block out your schedule.

Being remote and mostly autonomous can be great, but it can also lead to a sort of paralysis as you become solely responsible for your scheudle. I wrote in my article Surprises in My Switch to Remote Work that it's kind of like getting rid of the governor on an engine.

Here's what I've figured out so far (and I'm still learning).

First, I make all meetings 30 minutes by default if I can help it. If it's going to take longer than 30 minutes, it's more of a brainstorming session. Nine times out of ten, 30 minutes is plenty of time to hash out who needs to do what to make progress. The rest can happen asynchronously on Slack or via email.

I've also started time-blocking my calendar roughly every Sunday night. Generally I have three types of blocks for working on projects:

2 hours: dedicated focus time. I find that the difference between "completely overwhelmed" and "I know the next step" is nearly always 2 hours of focused work.
1 hour: maintenance. This is stuff like documentation, program maintenance, or tasks I need to get done.
30 minutes: admin or communications. This is the stuff I'm terrible at, so I book it in 30 minute chunks to stay focused and knock things off of my to-do list.

When it comes to actually deciding where to put things, I follow the "big rocks" approach:

Anything that involves other people, whether meetings or high priority collaborative work, I prioritize 4 days per week from 9 am to 2 pm.
We have Thursdays set aside as "no meeting days" on our team, so I use that day to do anything totally solo.
I do that same type of solo work in the afternoons from 3-5:30, especially admin or communications stuff. I do have an advantage here because I'm further west than most of the company, so it's pretty rare for me to even have a meeting after 2 pm PDT anyway.
I do side hustles like making egghead videos and Thinkster courses from about 7:30 - 9 am every day. Your mileage may vary, but I can't do creative work at the end of the day.

It's not a perfect system, since, with team members around the world I'll have the occasional 7 or 8 am meeting which wins over side projects. But it's good enough to produce results consistently.

Notice that I'm working from 7:30 am to 5:30 pm every day and I take an hour for lunch with my partner — I am not working 60 hours weeks! I try really hard to stick to this when I'm home since when I'm traveling for conferences I basically work for 72 hours straight other than sleeping. I block out as many distractions as I can during my normal work hours and then get on with my life.

Strategy 3: Repurpose content to prefer depth over breadth.

One of the best lessons I've learned so far is to use your content in multiple places. This can mean giving a talk multiple times, but it can also mean splicing and dicing that talk into blog articles, emails, videos, or anything else. Every time you iterate on that content, you can improve it based on feedback you're getting. For example, I noticed I was getting a lot of questions in my main NgRx authentication talk about where to store tokens, so I added a slide for that. So far, I've found Twitch to be a great proving ground for conference talks, videos, or articles.

I know some people are hesitant to re-use talks, but I think that goes away fast when you start doing dev rel full time. The idea that you can make a brand new talk — which take me about 30-40 hours to build, I don't know about you — for every single event is not realistic. Trust me, I tried to do it this first year and it was very stressful! The other thing I've noticed is that audience overlap is very rare, and even the few that see the same talk twice don't remember everything from the first time you gave it. I'd much rather polish something repeatedly and give a really great version of a talk than keep testing out raw material. It's honestly better for everyone.

There's a hidden lesson here other than just content re-use, though. In dev rel, it can be really tempting to chase the latest and greatest tech, endlessly running on the buzzword hamster wheel. Some people do this really well. It seems like they come out with videos on a new framework or library within minutes of a release. (They have a secret, though: they've spent time building a system with low friction. More on that next.)

This type of content can grab attention in the form of views, likes, and retweets (which is a necessary part of any type of marketing, really), but it's actually not the most important long term play. The folks creating the content know this, but until you know the secret, it's easy to think that your main goal in this field is chasing followers and becoming popular. Remember: popularity is not the same as impact, which is your real goal.

The invisible, long term game is actually one of quality and depth. This leads to greater success both in positively impacting other people and in revenue (or whatever you or your company chooses to measure). With the insane amount of content being created every day, there is a massive flight to quality. People can totally tell when you phone it in versus when you take the time to do your research and help people solve real problems. If you look at the people who are truly at the top of this field, you'll notice that they do both: they are great at moving fast on popular topics, but they also genuinely provide deep knowledge and value.

I'll give you two examples from my own work so far as I slowly carve out my path.

First is my ngUpgrade course Upgrading AngularJS. I spent all of 2017 pouring my heart and soul into this thing and released it in early 2018. It was my first ever video course and I was terrified to put it out in the world. Looking back now with my current experience, there are things I would change about it. The videos aren't HD, I didn't have nearly as good of an audio setup, and I've learned a ton about writing good copy, email marketing, and creating accessible content. Yet, to this day, it is still an order of magnitude more successful than anything else I've done in terms of positive impact and revenue. I still wake up to emails thanking me for making something so comprehensive and detailed. I was at a conference in Las Vegas in 2019 and someone from Norway came up to me and thanked me for saving his job!

Why is that? It certainly wasn't because of how fancy my technology was or how great my marketing was (especially because I'm kinda terrible at self-promotion). It's also not a particularly hip topic. Looking back, I can understand that the reason it has worked so well is because I stumbled onto an extraordinarily painful problem in my day job and set out to make the thing I wish existed to the absolute best of my ability. And people are still using it and getting value from it! I'm getting ready to do a big update to it based on what I've learned, but that core fact will remain: deep problem solving is the key. The rest is just gravy.

The second example is a little less dramatic. It's an article I wrote called The Painfully Shy Developer's Guide to Networking for a Better Job. I put a lot of time and care into that article and had a lot of experience to back it up. I went deep into a painful topic I had experienced myself. I still have yet to write something that has gotten as much traction, except maybe for my first article on authentication in Gatsby. I've even reposted the Shy Dev Guide in other places and it still crushes my other writing.

I hope those examples are encouraging for you. Spend less time spinning on the Hamster Wheel of Content Doom and go deeper. To be perfecty honest, I've learned this lesson after spending way too much time on that wheel myself and realizing I needed to go back to where I started.

Strategy 4: Increase throughput by fine tuning your systems.

This last strategy is only for when you've been following the signpost of resisting automation to the point where you've finally identified some true bottlenecks in your work. What you need then is not increased output, but increased throughput. What's throughput? It's the rate of production. You need to be able to move faster.

For some reason, Amy Hoy's writing has an uncanny ability for me to crystallize something that's been on my mind and cause me to take action. At the beginning of 2020, I had sensed that I needed to make some changes to my creative process but I couldn't figure out what it was. I was starting to feel like I needed to double the hours I was working, but I knew that was pretty much impossible (at least if I wanted to have a life and a happy relationship). I read Amy's ebook "Slay Your Schedule" as part of her 30x500 course and it finally clicked. I didn't need more work hours, I needed to increase my throughput by optimizing my workflow and systems.

Here are some examples of that I've done recently:

Getting a better A/V setup (a mic stand, a better audio interface, fixing some resolution issues) in order to reduce the friction of recording videos. This also drastically reduces my editing time. (If you want recommendations on gear, I basically just do whatever Joel Hooks tells me to do.)
Adding a trackpad to the left of my keyboard to speed up editing.
Automating meeting notes creation with Shortcuts.
Rebuilding my site with Gatsby so that I can quickly write and publish articles that have a nice, accessible reading experience
Using apps like Focus to block out distractions.

Note that you don't need any of this to be successful or happy. This is just icing on the cake that is letting me move faster. Plenty of people write amazing words or code on an old computer. I made the entirety of Upgrading AngularJS on a Dell laptop with a cheap microphone. I didn't know the first thing about automation and I did just fine.

But, when you see people who seem to be producing content faster than JavaScript frameworks can come out, it's probably because they've taken the time to build systems and optimize them. That's where I'm trying to be right now, so that's where I'm focusing.

In summary, be kind to yourself and others.

We've covered three principles:

Be kind to yourself and embrace that you're learning new skills.
Focus on shipping and improving.
Resist premature automation.

And four strategies:

Determine your priorities.
Block out your schedule.
Repurpose content to prefer depth over breadth.
Increase throughput by fine tuning your systems.

I hope you find this helpful. Overall, remember that it takes about 6 months in any job to learn the landscape, and mastery of skills takes years. And, of course, remember that you are not the sum of your content production. That's a really weird system of judgment created by marketing and has nothing to do with your value as a person. Make stuff because you love it, or make it to pay the bills, but don't feel some obligation to conform to some arbitrary production standard.

If you like stuff like this, head over to my website and sign up for the newsletter. I write about my journey as as self-taught developer on a constant quest for self-improvement.

You have a secret superpower for getting a job.

Sam Julien — Wed, 11 Dec 2019 23:22:58 +0000

I'm building a community over at GetAJobIn.Tech for self-taught developers & bootcamp students looking for their first job. This is the second email my students receive on my newsletter.

In the last email, I told you that getting your first job in tech is a system, not a straight line. I also mentioned two pieces of that system: Sharpen Your Skills and Take More Swings. We'll get to those soon, but they involve the stuff you probably already think of when it comes to getting your first job in tech: learning to code and applying to (and interviewing for) jobs. In fact, they're the bookends of the system:

Sharpen Your Skills
???
???
Take More Swings

Today, let's talk about the second one (drumroll please): Learn in Public.

I'm not gonna lie, this one really excites me, because it is basically a superpower you don't know you have. One of the things that most paralyzes beginners (actually everyone, myself included) is called "Impostor Syndrome." It's that feeling you have when you think, "Ugh, I still have so much to learn. How will I ever be good enough to get a real dev job?"

That feeling is totally normal (and I'll have a whole email on it soon), especially if you've just gotten rejected for another job because of "lack of experience."

Learning in public is the key to keeping Impostor Syndrome at bay. Instead of hiding your junior status or trying to BS your way through an interview ("Oh yeah I totally know what GraphQL is..."), you wholeheartedly embrace it and share your journey with the world.

This might be on a personal blog, a Twitch channel, YouTube, a podcast, or something else entirely. We'll cover tactics for this in the next email. For now, imagine that every time you learn something, however tiny, you write a tiny blog post about it. It doesn't have to be fancy or sophisticated (you can always edit it later). Just a TIL (today I learned) that you can write and publish quickly and regularly.

Check out the benefits of doing this:

You have a written record of what you learned for yourself to refer back to (and trust me, you will)
You have proof of your active learning for employers
You're building your personal brand online
You're helping others who might be in the exact same spot you are

These are all so powerful. For example, a good employer looking to hire a junior developer should care most about your ability to learn, not about your current knowledge base. Your tiny blog proves this. And you really never know who else you're going to help with your writing (or podcasting or streaming). It's good to pay things forward!

Okay, so now you know the big secret: learn in public. In the next email, we'll look at specific tactics for how to do this.

If you're curious about the rest of this series, head over to GetAJobIn.Tech and sign up for the newsletter. I'll send you a series on the 3 Surprising Keys of Getting a Job in Tech to get you started, as well as the continuation of the series above (and no spam, ever). Feel free to write me back and tell me how you're doing and what you're working on. You got this! 💪

Finding a Tech Job is a System, Not a Straight Line

Sam Julien — Wed, 11 Dec 2019 23:03:45 +0000

I'm building a community over at GetAJobIn.Tech for self-taught developers & bootcamp students looking for their first job. This is the first email my students receive on my newsletter.

One of the things that self-taught folks or bootcamp students struggle with is that constant struggle of wondering, "Can I really do this? Can I really switch to tech and get someone to pay me money to write code?" I've been there.

See if you can relate to this: you've been learning to code for several months (maybe years!). You're ready for that first job. You perfect your resume, upload it everywhere you can think of, apply to a bunch of jobs, and wait. Only to hear...crickets. And then come the rejection letters. "Why are they rejecting me from a junior developer job for not having experience!? That makes zero sense!" Ugh. It's so discouraging!

You're not alone. You see, junior developers are stuck with The Experience Paradox: a lot of jobs require experience, but how do you get experience without a job? It turns out there's a way to crack this, and I'm going to teach you that as best as I can over these emails and blog articles.

The thing to remember about finding a job in tech, whether it's your first one or just a better one, is that it's a system, not a straight line. Getting your first job isn't a linear process like this:

Learn to code somewhere (freeCodeCamp, bootcamps, wherever)
Apply to a zillion jobs.
Get awesome job.
Live happily ever after.

It's more like washing your hair: lather, rinse, repeat. There are a handful of things you can be doing repeatedly over time to build up your skills, your network, and your personal portfolio to make you more and more attractive as a candidate. You see, learning to code is only one part of the process (I call it sharpening your skills). So is applying to jobs (I call this taking more swings). The problem is that not many people talk about all the other things you need to do to land that first job. That's why you're here!

As we get to know each other, I'll be sending you more resources on each of these parts of the system. In the meantime, though, I want you to know that the answer to the question "Can I really do this?" is a resounding YES! You totally have what it takes. If you enjoy programming, that means you're cut out to be a programmer. Plain and simple. Doesn't matter who you are, where you live, or what you look like. That's what's so amazing about programming!

Next time, I'll teach you the second piece of this system.

A Q&A on Speaking

Sam Julien — Sat, 09 Nov 2019 00:10:51 +0000

Today I did a live stream on Twitch of working on one of my upcoming talks. I also fielded a few great questions on getting into speaking, so thought I'd write them down here. The video is embedded at the end of this post, too, if you'd like to see some Keynote tricks and hear my spontaneous answers.

On to the questions!

What do you think was your gateway to being able to speak at conferences?

For me, it was speaking at local meetups first. I was fortunate that I was living in Portland in the middle of the "Framework Wars" when I was first getting interested in speaking, so there were tons of meetups and they were all desperate for speakers. There are still plenty of meetups all over the world, though. Find one and offer to give a talk. You don't need to be an expert; just try to teach one concept in about 25 minutes.

One caveat here: not everyone gets started with local meetups. Some people just jump straight into conferences. This was the case for my friend/boss (fross?) Kim Maida. So, don't be afraid to go big right out of the gate.

While creating your talk do you focus on a specific part of your subject or try to cover all the nitty-gritty about it?

One thing I've learned with building talks is that less is more. Most of us try to cram way too much into a talk. Try to only have one to three main points you want the audience to remember. If you're doing a step-by-step walkthrough, scale down the scope of what you're trying to demonstrate so people can follow without losing interest or getting confused. Confusion and boredom turn to frustration and you've lost them.

So is it more about making your subject accessible and the form of the talk? Trying to break the entry barrier or something?

John Papa once told me, "Any talk under 30 minutes is not about the code. It's about making people feel like they can do what you're doing." People can always go rewatch the talk, review your slides, and look at your sample code. What you're trying to accomplish in a typical technical talk is something like, "Hey, I learned this cool thing, you can learn it too!" There are exceptions to this, of course, but I find the best talks have elements of storytelling and discovery. Don't just tell me the steps to do something, walk me through the learning process.

Do you create animations/gifs for a complex flow/diagram to add more impact?

Definitely. Visuals help people learn. This took me a long time to build to because I'm not artistic by any stretch of the imagination. I learned a ton from doing joint talks with both Kim and Mike Ryan about visuals and animations. Keynote's UI is very counterintuitive, but it is capable of building beautiful animations.

To see some examples, watch me and Mike's groupBy talk from RxJS Live and basically any talk from Kim. Her talk on authentication at AngularConnect 2019 is a great example.

Before doing your slide, do you write down topics and what you want to show and explain or do you start doing the slides right away (and kinda creating the talk at the same time)?

Yes, but first I work on the code behind the talk. Explaining something and coding something are often very different, so I want to make sure I am teaching the way that I have thought through building the sample app, not by how I might casually explain something.

Once the code is done, I start by making a bunch of notes in an app like Ulysses and then building an outline. (Don't get hung up on the tool; I used Google Docs until very recently.) As soon as I have the basic idea of the flow of the talk, I start adding very basic placeholder slides. I literally mean black and white slides with the piece of the outline on them. This lets me start to visualize how I want the talk to flow.

Pro tip: don't jump to styling your slides too soon. Choosing fonts, colors, images, funny gifs, and all that are great ways to bike shed and distract yourself from the content of the talk. They are also extremely hard to change once you've got 70 slides, so wait until the talk is almost completely hammered out.

So you're writing down the structure/ideas for the topics you want to talk about then build the slides?

Exactly. I flesh out an outline and then build very basic slides to start structuring the talk.

What things you do once you have the first version of your slides? Rehearsals?

As soon as I have some semblance of a complete talk (structure and flow, but not necessarily a full talk and certainly not styling), I start practicing it. I am very liberal with adding slides in the beginning, because I want my visual cues to sync up with my teaching points. I'll start rehearsing and get a natural "feel" for when a slide is needed. This "feel" is usually driven by thinking about what I would want or expect to see. I like concrete examples, sample code (but not too much!), and visual aids, so I try to sense when those would help. If you find yourself talking about an abstract concept without an accompanying concrete visual, that's a "slide smell."

Do you have all your talks written out [word-for-word] in case you forget something (or managing time or stressed)?

The only talk I've written out word-for-word was my 5 minute ng-conf 2019 talk. Five minutes leaves zero time for "um," "uh," or rambling of any kind, and 1500 people is too many to mess up in front of. I painstakingly chose every single word of that talk and exactly what would be up on the screen. It is as close to perfect as it could be.

I basically never do that normally, though. I practice talks a lot to nail down how I want to word things. I have a tendency to ramble or repeat myself or talk in circles, so I choose my wording and practice it.

In the case that I need to remember to say an exact phrase, number, or credit someone specific — a critical detail — I will add it to the presenter notes. This is somewhat risky, though, as not all venues have a setup that is conducive to you seeing your notes while presenting.

Do you have time to check the equipment before your talk in the venue?

A conference worth its salt will have a tech check either the day before or the morning of your talk. Often they will also communicate with you ahead of time to find out what your needs are and how they can ensure your success. If they don't, don't be afraid to reach out to the organizers and ask questions. One specific tip: a "comfort monitor" is the magic phrase meaning a second monitor on stage to show your notes.

What are the main mistakes new speakers always do and should avoid doing?

The biggest mistake new speakers make is not practicing on camera ahead of time. Sitting in your comfy chair behind your keyboard is not even close to the same experience as speaking on stage, so we find that getting on stage for the first time causes us to do all kinds of crazy things. We move awkwardly, we're really self-conscious, we forget how to project. I found that I always swayed back and forth like I was doing lazy Jazzercise and held my hands at my chest. Short of practicing in front of people, the most effective way to beat this is to set up your phone or a web cam and stand up and practice in front of it (while it's recording, of course). Watch how your body moves, listen to your volume. Movements and tone have to be exaggerated for your point to come across. It will feel awkward and weird to watch yourself at first, but that's good. It'll pass and you'll see how you can improve.

What tips have you to stop thinking of what people looking at you are actually thinking when doing your talk?

Public speaking repeatedly tops the charts as people's number one fear, even over death and zombies. Jerry Seinfeld has that joke about how people would rather be in the casket than giving the eulogy. This means that your audience is overwhelmingly empathetic to your plight on stage. They want to see you succeed. I've seen speakers crash and burn and in some cases it made the audience love them more. The only way to counter this is to come up on stage and act like an arrogant jerk; that puts people in a combative mindset. If you're humble, genuine, and kind, people will forgive you for all kinds of mistakes.

Read more of my writing at samjulien.com. Want to hang out while I experiment with code from the farm? Follow me on Twitch. Questions? Hit me up on Twitter.

Automating Screencasting with Keyboard Maestro

Sam Julien — Fri, 08 Nov 2019 17:51:53 +0000

When I was recording the videos for Upgrading AngularJS, I was using a Windows 10 laptop. Every time I wanted to shoot a video, I had to remember to hide the taskbar, hide my other windows, open up my editor and browser, and probably other things I'm forgetting.

It was really tedious.

When I switched to Mac when joining Auth0, I started researching how to automate different pieces of my writing, coding, and screencasting process.

Enter Keyboard Maestro. Keyboard Maestro is an insanely powerful Mac application that lets you automate virtually anything using combinations of triggers and actions.

Want to open an app when you connect to coffee shop wifi? Done.

Want to hit a single key to launch your entire development environment — including resizing all of your windows and running terminal commands? Done.

Want to trigger an end-of-day routine at 5 pm every day to force you to stop working? Done.

Keyboard Maestro has become completely essential to my workflow. The biggest help to me has been with recording screencasts. I now have a single keystroke that:

Hides all applications
Launches my editor (Camtasia until recently, but now Screenflow)
Opens iTerm and runs a teach command, which is an alias to launch Visual Studio Code with special settings (light theme for accessibility, bells and whistles disabled, etc.)
Resizes the front window to 1280x720 and center it.
Opens Chrome and send it to localhost:8000 (I can adjust this depending on the project, but that's a good standard)
Resizes Chrome to 1280x720 and centers it.

Here's a quick video on how to do it. (Oh, the video also refers to Karabiner Elements, be sure to grab that.)

If you want to master Keyboard Maestro, there's no better tool than David Sparks' Keyboard Maestro Field Guide.

Let me know if this helps!

Read more of my writing at samjulien.com. Want to hang out while I experiment with code from the farm? Follow me on Twitch. Questions? Hit me up on Twitter.

Speaker Stuff No One Tells You About: Applying to Conferences

Sam Julien — Wed, 03 Jul 2019 23:04:22 +0000

This is the first of a series called “The Ultimate Guide to Speaking Stuff No One Tells You About.” Part 2 is about building awesome presentations and part 3 is about travel hacks, credit cards, and more. (Don't worry, they're on the way.) This article originally appeared on my blog.

I hate “hand-waving” in technical articles. You know what I’m talking about. You try to learn how to build a prototype with a new framework, or use a new feature of a language, or set up the latest and greatest build system, and the tutorial says this:

Do a couple of trivial things.
??? (“This is out of the scope of this tutorial…”)
BAM finished!

That drives me NUTS! The whole reason I’m on your stupid site is to learn all the stuff in part 2!

I find the same hand-waving happens in articles about technical career advancement. They seem to always end up like this:

I dunno, tweet some things?
??? (something something “hard work”)
INTERNATIONAL SPEAKER AND STARTUP MOGUL! Enjoy your Tesla!

I’m about five years into being a “professional developer” (my 7th grade HTML didn’t pay the bills), so like you I’ve been down the road of Googling “how to become a speaker” and “how to become a better developer.” It’s so frustrating! It feels like a game is being played around you and you don’t know the rules. You’re watching other people become “successful” (or so it appears on social media) while you feel stuck.

Frankly, I’ve ended up having to rely on advice from friends, coworkers, and members of the Angular community to get help on everything from applying to conferences to contributing to open source. That’s how I’ve deduced the rules of the game for myself.

As I start to turn the corner on achieving some modicum of success, I want to write down some of these “unspoken” pieces of advice. I’ll mix in my own lessons learned as someone who is probably just a few stepping stones ahead of you. It’s more or less of a continuation of what I started with The Painfully Shy Developer's Guide to Networking for a Better Job.

I’m going to start with getting into technical speaking. I realized the other day that my first conference acceptance was just over a year ago as I’m writing this, so all of the lessons and unspoken rules are fresh on my mind. I had been speaking at local meetups for a couple of years prior to that, but I’m still new to conference speaking. Since that first conference acceptance, I’ve spoken in Copenhagen, Denver, Helsinki, London, Orlando, and Salt Lake City, with Vegas and Delhi on the calendar.

In this article, I’ll cover some strategies and tactics to help you get started with technical speaking. You’ll also notice these three themes coming up a lot in this article: empathy, persuasion, and persistence.

We’re going to get really practical here, but first I want to take a moment to reflect on why we’re doing this in the first place.

Wait — why we are doing this again?

Do you feel some pressure to speak at conferences as the only way to achieve career success? With the advent of Twitter, “tech celebrity” is a real thing. It causes a lot of insecurity and career envy.

I want to give you some advice and encouragement here. The majority of talented, experienced developers never set foot on a stage. They may be terrified of public speaking, they may have better things to do like obligations to family, or they may just not want to. That is completely and totally okay. You don’t have to follow some Twitter-endorsed gilded path to career success. Do what makes you happy.

At the same time, I have talked to a lot of developers who have said to me, “I could never give a talk. I’m not good enough. I have nothing to contribute.” That is equally misguided. Let me let you in on a little secret:

The best technical speakers are not always the best engineers.

I know a lot of people who are better engineers than I am, whether due to experience, talent, or the fact that they lock themselves in a room and program for 16 hours a day (when do you sleep!?). Speaking is about story-telling, emotion, and breaking down complex concepts. You can be a walking encyclopedia of programming information, but if you can’t explain it in a way that’s relatable and interesting, it doesn’t really matter. If I stood up and read the entire ECMAScript spec to you, I’d be technically sophisticated but a terrible speaker.

Is there a level of experience needed with your subject matter? Of course. The audience can tell the difference between a junior and senior developer based on subject matter expertise. But the key is here in the framing, not in speaker capability. If you’re a beginner, don’t sign up to give a talk on how you’re an expert at something. Frame the talk as a story about something really awesome you learned or an idea you had while figuring something out. People love authenticity; they love it when a speaker is true to who they are and relatable.

It’s also a well-established truth that the farther you get from learning something, the more difficult it is for you to explain. This makes the beginner’s perspective incredibly useful. The more of an expert in something you become, the more you start to forget all of those quirks and rough edges that confused you as a beginner.

By the way, this remains true as you proceed in your career and is one of the keys to creating great technical content in any medium. You might be a beginner in JavaScript or web development today, but in five years you may be a beginner in machine learning or Swift. Maintain the “beginner’s mindset.” Approach new tech with wonder and let that wonder permeate you’re writing and speaking.

I love speaking because I love teaching. I always have, even long before I was a developer. I love breaking down complex concepts and empowering other people to be better at their jobs or advance their career. I didn’t get into speaking for fame or anything, I just have a natural affinity for it. You might not have that same affinity. Maybe you want to travel or you’re in it for the glory. That’s fine, just be honest with yourself about it.

This leads me to my next point.

Applying to Conferences is a Skill You Can Learn

Let’s get this out of the way. There are some people who do rocket to fame seemingly overnight. This is often because they’re controversial or have some magnetic level of charisma. It may also be because they’re in the right place at the right time or have some other “in” like family or friend connections. Despite the version of reality you see on Twitter, though, these people are in the minority. The vast majority of people do have to work hard and work a system (the one I’m teaching you), even when it appears they came out of nowhere.

Let me give you an example from my life.

I have a good friend who makes re-orchestrations of video game soundtracks. It’s a niche talent, but he’s fantastic at it. He released an album a few years ago based on a Zelda game and it went viral. Suddenly, tens of thousands of people were liking, listening, and buying his music. He did an AMA on Reddit and I’ll never forget one comment about how he was an overnight success. I couldn’t help but laugh, because what they didn’t know was that, years and years ago, he and I would hang out after school and compose music. We would spend hours learning audio software, trying out MIDI samples, and coming up with our own video game re-orchestrations. I had watched my friend practice his craft for over a decade before he saw any commercial success. Yet, to the general public, he “came out of nowhere” and was an overnight success.

Most of the time, it’s no different in tech, though it probably won’t take you a decade. There are outliers to this process, but you can’t use them as an excuse. Here’s the good news: applying to and speaking at conferences are skills you can learn and improve with practice over time. They’re not mystical or magical, they don’t require an amulet or spell book, and they don’t require a certain level of underlying talent.

With the philosophy laid down, let’s get into the nitty-gritty.

Crafting a CFP with Empathy

As you’re preparing your proposal for a conference, think about what the conference is looking for. Sometimes they will tell you outright on the CFP form, otherwise you can go back and look at previous talks to get a sense of their style. Do they tend to select more advanced talks? Do they select a few soft (catalytic) skills talks? You can use this information as you craft your proposal.

CFP means “Call for Papers” or “Call for Proposals.” These usually include basic biographical information, a title, and a description of the talk (often referred to as an “abstract.”

Let me give you one tip that is pretty much safe to assume for all conferences: conferences want to sell tickets. This means they want solid, educational, entertaining content from vetted speakers. Note that “vetted” doesn’t necessarily mean “experienced.” They want speakers who will be engaging, well-prepared, and not violate the code of conduct.

“But wait, how can I be vetted if I’ve never given a talk before?”

There are a number of ways you can do this. The best way is to start giving talks at local meetups and recording yourself giving them. Don’t worry about the quality. Get yourself a cheap tripod and prop your phone up. You can get as fancy as you want, but the idea is to get some recordings of you speaking that you can send to conferences in support of your proposal. You could upload them to your own YouTube channel and start building a public portfolio, or keep them unlisted and send them out to the organizers privately.

If for whatever reason you can’t record, at least start putting slides up publicly through Slides.com, SlideShare, Google Slides, GitHub, Speaker Deck (my favorite), or others. (We’re going to cover slides in depth in the next part of this series.)

Community involvement in general is also a good way to start being vetted by conference organizers. Engaging with community members and organizers in a non-creepy and helpful way will go farther you would think. Answer people’s questions on Twitter, Gitter, StackOverflow, and other forums. Promote other people’s work. Be positive and welcoming. These aren’t just mindless platitudes; they really work! Build a reputation as someone who is welcoming and helpful.

”I’m not an expert — how do I come up with a topic?”

As we’ve established, you don’t need to be an expert to speak on a topic that you’ve got experience with. But even beyond that, let me let you in on an industry secret: many great speakers submit proposals on things they want to learn about. You read that right. They will pick a topic, learn enough to write an abstract about it, and then, on acceptance, learn enough to write a talk. While preparing, the best speakers will also vet their content with subject matter experts to make sure they’re not way off base or promoting terrible practices.

You can greatly use this to your advantage. If you notice a trending topic and have an idea on how to present it, submit a talk about it.

Okay, you now know how to start thinking about your CFP. Let’s get into writing it.

Good CFPs solve problems; great CFPs tell stories.

When we first start applying to conferences, it’s natural to think of them as black-and-white, technical, and purely logical. This makes sense coming from engineers. The truth is that humans are story-driven. Good talks focus on solving problems. Great talks tell stories that change perspectives.

That being said, avoid “lessons learned” talks unless the conference specifically requests them. Literally everyone has these lessons. Usually, though, there is a germ of a good CFP in there. Take whatever the lesson was and turn that into the talk topic. Did you learn about how the shadow DOM works when you were working developing a complex UI? Change that talk from “Lessons Learned About the Shadow DOM” to “Using the Shadow DOM in Complex UIs.”

Let’s go one step further, though. Focus on tying a technical issue to a tangible result. People love to save time, save money, reduce bugs, increase sales and customers, and reduce the amount of code written or maintained.

Here are some good example titles that focus on benefits:

How to Save Time and Money by Planning Your ngUpgrade
How the Async Pipe Saved Us a Million Dollars
Cut Your Bugs by 50% with TypeScript

I made up the second two, but hopefully you get the idea. These talk titles show off a specific benefit. You can also catch attention by being surprising, unexpected, or contrarian:

You Might Not Need NgRx
“Can you imagine a future without zones?” (Zone.js is part of Angular)
Browser Versions Are Dead

Just don’t get click-baity or I will personally track you down and fill your car with pizza flyers (the coupons will even be expired).

The abstract is not about you.

Here’s another secret that no one tells you: your talk abstract is not about you. It’s not even about the technical details of your talk. It’s actually sales copy. Yep, you read that right. The talk description has two jobs:

Convince the organizers that this is a talk worth picking
Convince the audience to attend your talk at the conference (or watch it later online)

Don’t worry. You don’t have to make your abstract salesly, gimmicky, or corny. It does need to be persuasive, though. This means that your abstract should focus on the benefits of the talk and what the audience will learn. There should be a strong current of empathy running through your writing.

Let’s look at an example:

My talk is about using Jest for unit testing. I will talk about why to use Jest, define snapshot testing, and demonstrate how to set it up in both Angular and React projects. I will also show common errors to avoid when unit testing with Jest.

What do you notice about this? It’s not just dry and boring, it also uses the words “my” and “I” multiple times in just a couple of sentences. This example describes the what of the talk, but not how it impacts the audience. Take a look at this rewrite:

Do you hate writing unit tests? It’s okay, you’re not alone. There’s good news, though: Jest makes unit testing at least 30% less terrible. In this talk, you’ll learn what Jest is, why it’s awesome, and how it reduced my team’s bugs by 15% in the last year. You’ll also learn exactly how to set up Jest in a project, whether you’re using Angular, React, or something else. Finally, you’ll learn common pitfalls to avoid in snapshot testing to make sure you don’t waste time you could be using to write new features.

What’s the difference? This example has much more energy and humor. It’s also more specific about the benefits of the talk. Most importantly, it uses “you” and “you’ll learn” to talk directly to the audience.

If this feels unnatural to you, don’t stress about it. The more you write, the more you’ll start to find your voice. Keep a bank of your CFPs through GitHub, Google Docs, or an app like Ulysses so you can easily re-use phrases or entire CFPs.

Remember: it’s a numbers game.

When I was in finance, someone gave me a copy of Nick Murray’s book The Game of Numbers. This book is about financial sales, but has a fantastic thought experiment that is helpful in many areas, including speaking. Here’s my paraphrase of it:

Imagine a slot machine from a casino. It looks like any other slot machine, but this one is magic. This slot machine comes with a guarantee: after 10,000 pulls, it will (not might, will) pay out $100,000.

How does that knowledge affect your perspective on the slot machine? You’d probably stand there for as long as it took to get to 10,000 pulls, right?

It’s uncertainty that gets us to quit. We start on a project or goal full of enthusiasm, then somewhere along the middle of the journey we lose steam. Maybe we get rejected. Maybe we’re not seeing results. We give up, usually with some excuses or rationalizations (“I’m just not meant to be a speaker.”).

Approach speaking like you would approach that slot machine. Apply to as many meetups and conferences as it takes. If you’re a generally decent person and relatively talented developer, you will get there (not might, will). And, good news: it probably won’t take you 10,000 tries.

A Short Tactical Note on Finding Where to Apply and Tracking Submissions

There are several different web sites, apps, and GitHub repositories that track conferences for various languages and frameworks, so I’m not going to reinvent the wheel here. However, I want to give you a few practical tips to help you with this process:

Create a CFP spreadsheet to track all of your submissions. You can feel free to copy mine. I keep track of the conference dates, the submission deadlines, links to conference and CFP, and notes on what I’ve submitted. You can also use something like Trello for this. The tool isn’t important, it just has to work.
Create a separate CFP Deadlines calendar.
Keep your CFP abstracts in Google Docs or an app that has cloud-syncing like Bear or Ulysses. This will let you find ways of reusing and repurposing all or part of a submission. Never submit a talk only once! You can write a few solid proposals each year and submit them in various formats to multiple conferences. Sometimes, a conference will a unique talk, but they will make that clear. (These are usually the top-level conferences in each field like ng-conf for Angular.)
Write short first person and third person biographies of yourself and keep them along with a link to a solid headshot in the same place you store all of your CFPs. You’ll also usually need links to your web site, your Twitter and GitHub accounts, and previous talks, so make a doc that contains all of your “self metadata” for easy access when submitting.
Don’t shy away from lightning talk submissions of 5-15 minutes. These are not less important, less prestigious, or less valuable. In fact, I find shorter talks to be more difficult to write and more fun to deliver. Also, you’ve got better odds here: a lot of people skip over lightning talk submissions. They might be your ticket in the door!

Action Steps

Here are a few things you can do to get started on your path to speaking:

Create a CFP spreadsheet and deadline calendar.
Find three conferences to apply to in the next year and add that information into your spreadsheet and calendar.
Contact two local meetups about giving a talk.
Write your short biography and keep it in your app of choice.

Conclusion

I hope this guide has left you feeling empowered and inspired to tackle applying to conferences. Remember the key themes: empathy, persuasion, and persistence. Think about what the organizers are looking for and what the audience will love, show them the benefits of your unique perspective, and never give up. If any of this works for you, I’d love to hear about it!

Also, if you’d like to get more of this kind of thing, I’ve got a non-technical email newsletter called Quietly Ambitious. It’s a sort-of-regular note from me where I share career advice, highlight people doing cool things, and talk about what I’m enjoying and learning these days.Sign up for it here. (You’ll never get spam from me. Gross.)

The Painfully Shy Developer's Guide to Networking for a Better Job (Without Being Creepy)

Sam Julien — Mon, 01 Jul 2019 14:54:30 +0000

This article originally appeared on my blog.

Look, I get it. A bunch of web developers, recruiters, and vendors standing around in a room eating pizza or drinking beer and making small talk might sound like complete and utter death for you. There may be a million things you'd rather be doing. "Uhh, don't I have a dentist appointment that day? At least then I won't have to talk."

I get it.

I'm an introvert, too. I get drained by being around people and often need what my own mother called "cave time." Fortunately for me, I was forced to develop some networking skills and get very good at faking being an extrovert. Before I was a developer, when I was dirt broke, I got myself a job selling life insurance. The goal was to become a fee only financial planner, but I had to start at the bottom, and that meant sales. I had zero sales experience, and honestly had no idea how much I was going to be shoved out of my comfort zone.

I had no choice, though. If I stayed comfortable, I didn't eat or pay rent.

Lucky for you, you don't have to do that. If you're looking for a better job, though, it's a great idea to head to some tech events in your town or travel to conferences in order to build relationships with potential future employers. Sometimes great companies will contact you out of the blue, especially if you've become a high profile developer through an open source project or previous job. But when you're looking for your first or second or third job, you may not have that luxury - you may only be contacted by recruiters for jobs that aren't your first choice (to put it kindly). Most developers hate this side of things, and would rather do anything than interact with someone in real life in order to try to find work. It feels manipulative or scammy to them.

Here's the truth: you can get what you need from these events without being awkward or creepy. Whether that's job leads or important connections, there is a well-defined, time-tested way to accomplish this. It will push your limits, but it won't leave you feeling gross inside. And the more you do it, the better you'll get at it.

Our Goal

Our chief goal with networking events and conferences is simple: begin to build relationships with influencers at our dream companies. Who are influencers?

Senior engineers
Developer evangelists/community relations
Recruiters
Hiring managers

We want to meet these people in a way that is authentic and natural, and then follow up with them. Read that sentence again, because each piece is crucial - you are not trying to ask for a job at the event! You are starting to get to know someone and see if you're a good fit, then over time ask for their help.

Okay, but I'm terrible at this. How do I change that?

Any type of change consists of two components:

Your personal psychology
Your skill set

The former is the hard part. Your previous experiences of awkwardness or embarrassment (or maybe even downright humiliation) have pounded in your head phrases like:

"I am just no good at social interaction."
"I just don't have confidence."
"I am soooo socially awkward."

See how much "I" shows up in those? See how we identify with our experiences of pain or perceived failure? The major hurdle is overcoming those psychological barriers so you can start to perceive yourself as someone who is confident and in control of social situations. You may never enjoy them — and that is completely, 100% okay — but you will at least feel like you are competent. It's kind of like my relationship with jQuery. I've used it a lot and am in competent in it, but I will never love writing a bunch of $ statements and manipulating my DOM with it.

So how do we actually change the psychology? We do it with actions that produce quick wins as you are building your skill set. The truth is, social skills (sometimes called "soft skills") are just that: skills. And what are skills? A set of strategies, tactics, and processes you just learn, practice, and eventually master.

Think of Social Skills as a new programming language. There are a few core concepts to this language that may be new to you, but luckily, the syntax is actually way simpler than you might realize. The reason this subject seems so scary and overwhelming is that no one has taught you how to do it yet -- it has nothing to do with your intrinsic value as a person. And let me tell you a secret: sometimes the people who feel the least competent turn out to be the absolute best in this area.

Here are 3 core philosophies and 5 key tactics to becoming awesome at networking events.

Core Philosophy 1: Make Other People Feel Welcome and Accepted

People are honestly not that complicated. When you go to an event or a meetup, do you find yourself awkwardly standing around, compulsively looking at your phone? Do you feel alone or uncomfortable? The truth is, nearly everyone else is feeling the same way. When it comes down to it, people want to feel welcomed and accepted. Why else do people gravitate towards the people they already know at these events? Few people really relish being awkward at these things.

Here's the fun part: you can change that for someone else. Shift your thinking from how you are feeling to how others are feeling. How nice would it be if someone came up to you and just gave you a warm smile, said hello, and asked you a genuine question about yourself? You can be that person for someone!

Core Philosophy 2: Give First, then Give Some More

That leads us to the second core philosophy: come to these events with an attitude of giving. Instead of thinking (at worst) "Oh no, I hate these things" or (at best) "What can I get out of this?", think instead: "What can I give? Who can I help?" A weird thing happens when you start thinking this way - things go really well.

Back when I was new to financial sales, I had a very simple strategy for feeling less awkward. I'd scan the room to find someone who looked alone and uncomfortable (like me), and smile and introduce myself. Then I'd start asking them questions about their business. I'd make a mental note of this and repeat. When I came across someone who would be a good connection for anyone I had previously met, I would introduce them. It was as easy as this:

"Oh, you're a commercial real estate attorney? Have you met Jane? She's a commercial realtor new to the area. Let me introduce you."

If these are indeed genuine, valuable connections, both people will be really grateful. You can do the same in tech, whether by connecting contractors and team leaders, or just helping people make friends:

"Oh, you like hiking too? Ashley over there does too! You should totally be friends. Hey Ashley, this is Stephanie. You both like hiking, discuss!"

See how natural that was? Not weird, not creepy. Just fun - which leads us to core philosophy 3.

Core Philosophy 3: Don't Overthink — Be Genuine & Have Fun

If you're an intelligent introvert, you may have a tendency to overthink...just a bit (cough me cough). "What if I say the wrong thing? What if I look stupid? What if when I open my mouth I just start quoting Harry Potter?" You can relax. When it comes to social interactions, your tone and your body language matter way more than what exactly you say.

If you come across as fun, confident, and (this is important) authentic, most people will be glad to talk to you. Folks can spot being fake or scummy from a mile away, but that's most likely not your problem. We gradually want to build your confidence, but even your shyness can be an asset - many people will find this endearing, especially if you're just looking for friends.

The point with this one is to just do it. Overthinking will keep you from practicing, and practicing is what will make this easier for you and build your confidence.

Now let me tell you the surefire easiest trick to get started.

Tactic 1: Smile and Say Hi

Yes, it's really that easy. This has been my go-to opener for years with people. I walk up to someone, give them a warm smile, offer my hand out, and just say, "Hi, I'm Sam! What's your name?" If they've got a name tag, I'll ask something innocuous like, "What brings you here?" Like I said above, people love to feel welcomed and accepted.

Tactic 2: Ask Questions (How to Approach a Group)

Asking questions is also a great way to meet people. In Tactic 1 I suggested asking "What brings you here?" With both individuals and groups, you can also ask something totally inconsequential. The point of any opener, whether with an individual or group, is to simply break the silence and get the conversation rolling. Aside from something inflammatory or offensive (which honestly can be brilliant if done in the right way with a little humor), it almost makes zero difference what your opener is.

Let's look at an example. Let's say there's a group I want to approach — maybe there's a speaker with a few people gathered around that I'd really like to meet. Instead of awkwardly standing to the side of the speaker and eventually thrusting my hand in his or her face, I'd walk up to the group, stand for about 30 seconds to catch wind of the conversation, and then ask a question — either to the group or to whomever was the last person to speak.

Walking up to a group.

Person A: "Ugh I dunno, the build process you mentioned in your talk has given me so much trouble."

Speaker: Really? How so?

Person A: I just had so much trouble getting my scripts to minify.

Me: Oh yeah, me too! What do you think about Magic Plugin X? I tried to so hard to make that thing work and it just made me even more frustrated!

Person A: Haha, oh yeah, totally. I thought Magic Plugin X was okay, but Super Plugin Y was much easier.

When the conversation comes to a natural pause, I can then interject, "By the way, I'm Sam everyone. Oh, and Speaker, I really dug your talk. Thanks so much for that."

Note what I did not do: I did not shut down the conversation by trying to prove a point ("Actually that build process is completely superior due to the following technical reasons.") I also did not start a war ("THAT PROCESS SUCKS!"). Being contrarian can be useful, but only when done with humor. Starting arguments without smiling, laughing, and being playful will just isolate you. Would you rather a) be right or b) make friends and connections? (Hint: pick b.)

Tactic 3: Give Genuine Gratitude

I've had the opportunity to meet plenty of "tech famous" people: authors, teachers, core team members, and Googlers. This is the main way I introduce myself to all of them. The key here is always to be genuine. Take, for example, a "tech famous" core team contributor of your favorite framework. That person gets bombarded daily with mostly criticism and sometimes abject flattery. Any time I meet someone whose software I use or whose book I loved, I simply smile, shake their hand, and say:

"Hi, I'm Sam. I just wanted to take a moment to thank you in person for the work you're doing. It really makes my life easier every day."

Most of the time, especially in the tech world I've found, I can visually see their guard come down. They are used to either being yelled at for weird technical minutia (developers can be really awkward) or dealing with fans trying to take selfies with them. Just being authentic and showing gratitude can go a really long way.

You shouldn't have any trouble giving gratitude if this is somewhere you want to work someday. Outside of simply fame and fortune, you're probably interested in the company or the person because they've helped you in some way, either by making a tool or framework you use or because you just admire the brilliance of their engineering. Or, you may share a common social mission if it's a non-profit. Say something about that.

Tactic 4: Find Common Ground

Once you've expressed genuine appreciation, you need to master the art of finding common ground. Your best go-tos are always:

Hobbies (think board games or knitting)
Location (from the same small town in Ohio?)
School (same high school, same college, rival college)
Entertainment (here's your chance to talk about Harry Potter, or sports, or TV shows)

"Wait a second, Sam. This sounds like small talk. I hate small talk."

Well, okay, you caught me. This is small talk. But it's small talk with a purpose. You're trying to build a relationship with this person. You don't build a relationship immediately with BIG SCARY TOPICS like relationships or politics or religion. You have to get to know someone first.

Here are some examples (and remember: the goal here is to be authentic).

[after expressing gratitude]

Me: "I was just talking to someone over there about that new board game Scythe. Ever played?"
CTO: "Oh no I haven't. I love tabletop games."
Me: "Oh yeah? Any favorites?"
CTO: "I'm a huge Netrunner dork."
Me: [proceeds to joke about how complicated Netrunner is]

Boom. Easy. What if that person wasn't into games? Here's what I'd do:

Me: "I was just talking to someone over there about that new board game Scythe. Ever played?"
CTO: "Oh no I haven't. I hate those kinds of games."
Me: "Oh yeah? More of a real-life-games kinda person?"
CTO: "Yeah, I'm a big disc golf fan."
Me: [proceeds to joke about how terrible at disc golf I am]

Notice how I handled that. I very subtly pivoted the conversation by asking a very specific alternative question. I didn't just say, "Uhh, okay, what do you like to do for fun?" People don't like such broad questions because it leads to dead time in the conversation where they have to think. You always want to ask easy questions first to get them engaged, then follow up with jokes or questions asking for elaboration.

Also, notice that in both scenarios, I didn't just blindly agree with this person. I don't have to say anything like "OH I LOVE NETRUNNER!" or "DISC GOLF IS MY FAVORITE!" if it's not true. I can make a joke and laugh about it. You're just making conversation here with the intent of finding more out about the person, which you can use to follow up with them later. Humor and grace are very disarming to people, and can help make connections with just about anyone.

Tactic 5: End Gracefully

Never spend more than a few minutes in these interactions. You're not trying to figure out someone's entire life story, and you're not trying to get them to offer you a job. Sometimes things happen naturally - you might find yourself an unintentional BFF and end up going for drinks if it turns out you're from the same tiny town in rural America - but that is usually 1 out of a 100.

The key to ending a conversation gracefully is to have a natural out. You also want to be the one to end the conversation if possible. If this person is in high demand, don't be that person who holds onto them for an awkward amount of time. I have seen this a lot at tech conferences, and it's just plain awkward for everyone. Usually the in-demand person is trying as hard as possible to be polite, and their captor is totally oblivious to how much time they're hogging. Don't do it. Take a few minutes to get to know the person, and then say something like this:

"Hey, it was really great talking to you for a minute. I've got a few other people I want to be sure to catch before I take off. I'd love to keep in touch, though - do you have a card?"

I know, I know, we're in tech and people don't often carry cards. That's okay. The point is not the medium itself, the point is that I asked them for a means of following up. Do not just hand them a card or tell them your Twitter handle. They will never follow up with you.

In response, they'll say one of three things:

"Sure, great meeting you too. Here it is."
"I don't carry cards, but tweet at me sometime."
"Uhh, you know, I never check my work email anyway." <-- This is them politely telling you to buzz off.

Their response will either be 1) positive, 2) ambivalent or just being polite (the "tweet at me" response is sometimes just that), or 3) politely or impolitely refusing depending on their own level of social skill. If it's number 3, don't take it personally. Just smile, shake their hand, and wish them well. Either your approach was a little off-putting or their personality just didn't jive with yours. Just relax and note it for the future. I've had this happen too, sometimes with the very people I thought I'd get along great with.

Numbers one and two require follow-up work, and that's our last tactic. Before we cover that, one pro tip: as soon as you can after meeting someone, write, type, or dictate basic information about that encounter. Don't overthink the method; use Google Keep, Evernote, a tape recorder — anything to remember their name, their company, and the areas of common ground you found.

Tactic 6: Follow Up (No one does this!)

Following up is the single most important tactic here, but it requires the most skill. You have to learn how to follow up without being creepy or too persistent. Luckily, this is pretty straightforward.

After a few days, but no more than a week, contact them in their preferred medium. It's this easy:

Subject: Great meeting you! [keep it simple]

Hi Susan,

Just wanted to send you a quick note to say that it was great meeting you at the Famous Tech Conference last week. I bet that Michigan weather is a tough adjustment after all that sunshine. [something personal about them].

Take care, [courteous without being creepy]
Sam Julien
P.S. My friends are still trying to convince me to play Scythe, but I hear it's even more complicated than Netrunner. I'm doomed. [callback to whatever common connection you made]

Notice I'm still not asking for a job or anything. I'm still building the relationship.

If they don't respond, that's fine. Not everyone has time to respond to every single email. Hopefully, they'll respond in a friendly tone with similar banter. If not, don't sweat it.

At least a week after this exchange, it's safe to make your first foray into the job-hunt with this person, though it helps to continue to build the relationship. Ideally, you want to build these connections long before you actually need a job or before the company posts a job. Sometimes you don't have that luxury, though, and you need to act quickly. If that's the case, your second email is fine for this. The key here is to keep it light and be outcome-independent. Be tactful and not over-bearing, and frame it asking for advice and help, not as demanding they give you a job.

Here's how:

Hi Susan,

I saw on Twitter that SusanTech is looking for a new JavaScript developer. [be direct but truthful]

I'm thinking of applying myself since you seem super happy there - is there anything in particular I should know about the application process or the job that's not on the posting? [use your head here, don't ask dumb questions that are answered elsewhere]

Thanks so much; hope you're doing well and not buried under all that snow! [light-hearted and friendly!]

Cheers,
Sam Julien

The goal is always to have this person be your ally, and to truly want what's best for you and for them. You are not looking for them to just do you a favor, nor are you trying to look desperate. Also, and perhaps most importantly, you are not building the relationship with them to simply get a job. Think bigger than that: you may be able to help them with something down the road, or you may both end up working at a different company together later on. Also, never underestimate the positive impact simply being a friendly, positive person has. People appreciate that.

So, the key to following up is outcome independence - you're asking for some help or advice, but you're applying anyway, and the results of the job decision have no bearing on your relationship with that person.

There are many nuances to the follow-up and relationship building process. Just get started for now and refine your process over time as you get better.

Action Items

We've covered a lot of ground in this guide. Here's what I want you to do this week:

Pick out 1-2 events in your city you can go to in the next 1-2 weeks.
Find a friend or co-worker to go with you if possible. That person doesn't necessarily need to stay by your side the whole time, it's more about having some accountability to go.
At the event, talk to 3 people using the philosophies and tactics I describe above. Don't worry about the outcome, or even if the people work where you want to work. We're just getting you some practice. If this still freaks you out, here's a different goal: say hi and introduce yourself to just 1 person you don't know.
Capture what you learn into Google Keep or a similar easy system.
Within a week of that event, send friendly follow-ups to each person who showed either a neutral or positive response.

Oh, one more thing. Reach out to me and let me know how it went - what went well, what was tough - and any other topics you'd like to learn about.

Also, if you’d like to get more of this kind of thing, I’ve got a non-technical email newsletter called Quietly Ambitious. It’s a semi-regular note from me where I share career advice, highlight people doing cool things, and talk about what I’m enjoying and learning these days. Sign up for it here. (You’ll never get spam from me. Gross.)

Good luck — you can totally do this!

How I got more done faster (without wanting to die) in 2017

Sam Julien — Fri, 14 Jun 2019 03:19:56 +0000

A personal retro for 2017 I posted originally on my blog.

I began 2017 standing at the edge of the Grand Canyon and making a decision to be wildly optimistic and obnoxiously grateful, both publicly and in my own mind. I let that dazzling beauty work its way into my heart and decided to let that moment dictate the rest of the year. It worked - but not just for my own well-being. I received lots of messages and kind words over this year about how badly people needed that, how my positivity has "kept them going." It is hip to be cynical and to be paralyzed by despair, but despair never motivated anyone to change. I decided to opt out of that bullshit, to stop being beholden to all of my untested delusions of failure and to focus on what's under my control - and do so with gratitude.

With that decision came a big year for me, one filled with love, adventure, and learning. I finished my wilderness survival program, built my first video course (200 screencasts and counting) and fixed several physical problems. I'm starting 2018 much healthier than 2017 (despite a back injury that threw me off track for a bit). I am still on a journey to becoming the best version of myself, and I still have a long way to go, but I am learning tons along the way and documenting my progress.

There's one pattern that kept repeating this year, whether it was in my career, my health, or my relationships. I've been calling it The Feedback Loop, and it looks like this:

Do something.
Do it quickly.
Do it consistently.
Adjust and repeat.

Let's break this down piece by piece.

Do something.

The first thing I've learned is to actually do something. Literally anything. Don't just sit there planning and scheming and living a fantasy life. Pick something you're going to do in any area in which you're trying to improve. Not a hundred things, not three things. Just one thing: one new habit, goal, or project. The key is to make it specific, measurable, and something you can act on.

Bad example: "I'm going to write a book someday." (No you won't. At least not like that.)

Good example: "I'm going to write every day for 90 days."

Bad example: "I'm going to get healthy this year." (What does that even mean? No you won't.)

Good example: "I'm going to do strength training 4x/week for 30 days."

"But Sam," you might be thinking, "what about all the other stuff I want to do? What about all my grandiose plans?" I get it. Two things really helped me this year with that: singular focus and being in the present.

Ditch the multi-tasking.

First, I had to let go of multitasking, both on a micro level (doing two things at once) and on a macro level (trying to accomplish two goals at once). Until recently, I've always lived with this delusional idea that multitasking is somehow superior to singular focus. We're primed to think that way now that we're tethered to screens all day long. It turns out that's just wrong. We're not built for that. We're built to achieve one goal at a time. Back in the day, you couldn't build a shelter and hunt an animal at the same time. That was never going to happen. You had to do one thing at a time. And, speaking from experience, building a shelter takes a freaking long time and a ton of energy, so hunt accordingly. See exhibit A of a fire shelter I built with five other people last year over about 6 hours:

I also found that it's easier to eliminate stuff from your life than to magically free up more time in your schedule. You've probably heard of something called the Pareto Principle: that 80% of results come from 20% of effort. When I decided to build my tech education course, I had to start cutting my commitments to free up more time. In America we have this obsession with DOING ALL THE THINGS and saying yes to EVERYTHING, no matter how much we dislike it or how little it actually yields results for us. I had to cut the stuff I was only doing because I thought I was supposed to. You can read more of the nuts and bolts of this process in The 4-Hour Work Week. It's good content, though I've said before I always get a little cringed out by Ferriss' Silicon-Valley-Playboy-tone in his books. Get past that though and extract the bits that are useful. For me, learning to cut out the things not yielding results has been a big help.

Stop lying to yourself.

You've eliminated the cruft, but being in the present is also a huge part of this. I've had to learn to get myself grounded in reality, not my mind's grandiosity. I don't know about you, but I lie to myself all the time. To get a clear sense of what I should be focusing on, I have to start by forcing myself to live in the present and admit where I actually am, not where I want to be. Once I am grounded in reality instead of my dreams, I can identify the next step. How do I do that? By looking at my results, not my intentions. If I want to write a book, but haven't written more than a sentence in the last 5 years, I'm living in a fantasy. If I want to own a restaurant, but haven't worked in a kitchen, I'm living in a fantasy. You have to crawl before you can walk, and you have to walk before you can run.

So, to sum up: cut out stuff that isn't making you happy, ground yourself in reality, and then pick your One Thing in an area you want to improve. Once you've done that, you can hurry up and fail.

Yep, you heard me.

Do it quickly.

I have always been a chronic over-thinker, a classic case of Paralysis by Analysis. I always have way too many good intentions or good ideas that turn into nothing. I've noticed that problem in my friends too, particularly the ones that would score high marks in both intelligence and compassion. People like us want to help the whole world or to do something perfect and brilliant - but that is exactly what keeps us from acting. We're afraid of doing it imperfectly and besmirching some bullshit, perfect image of ourselves. Here's what I've learned this year: taking action on one idea (no matter how simple) is worth more than writing out a whole book of ideas.

But how do we do this? How do we get out of the quicksand of thinking too hard because we're afraid of failing? Instead of over-thinking in order to avoid failure, we have to take action quickly and fail fast.

Let me repeat that. Instead of avoiding failure, run to it. Fail as fast as you can in your One Thing.

Failing fast is the key to the Feedback Loop, because taking action deflates the lies we tell ourselves. It's way easier to see this in the physical world than in the world of ideas. If I lie to myself about being able to deadlift 500 pounds, the second I actually go to the gym and load up the weight that balloon is popped. It's the same for all those other identities we hold onto: writer, musician, artist. Are you actually a writer? Or do you just fancy yourself a writer because you won some awards in high school?

But say you set a goal to start writing 750 words a day, and you do it for 90 days. Lots of things might happen in those 90 days. You might fail to write your book. That's okay: you might get the inspiration for a totally different book, or attract an offer for a guest blog post. You might decide that it actually takes 1000 words to get you in the zone. You might find that writing at 6am is much better for you than 10am. You might have just done enough to turn on the creativity spigot to really write that book this year.

But guess what? Now you're a writer again. Not just in your head. Not just in your dreams or your memories of being young, but in reality. None of those things can happen until you put words on the page.

I wanted to get into tech education. I had all kinds of dreams of what that would look like, but hadn't done anything yet. Then I partnered up with two people and made a huge commitment to produce content. It turned out to be way harder and much more work than I thought it would be: I had about 200+ screencasts I needed to make. Fortunately for me, I had given up my free will by making this commitment, and people were counting on me to live up to my word. So how could I could possibly tackle it?

Like a good Perfectionist, I started by over-thinking it. I tried to meticulously plan out the curriculum and the sample code. I did anything I could to avoid actually doing the work, until my business partners said to me: "Dude, just make 5 videos for us by the end of next week so we can see you're actually serious." Guess what? I made the 5 videos. They kind of sucked - the volume was too low, my pacing was wrong, and they took me forever to make. I learned so much in the process, though, that it cured my overthinking inertia. I was off and running. The next week I made another 5 videos for my partners that were a little bit better. I found the process to be a lot like woodworking. You can plan up to a point, but then you start making cuts in the wood, gluing things together, and making mistakes, and the project takes on a different, more complex shape than you ever could have planned for in your head.

And then I made 5-10 videos every week for six months - which brings us to our next point.

Do it consistently.

When I was going to PT to fix my knee, I had this one seared into my brain. Consistency - sticking with the exercises day in, day out, especially when I didn't feel like it - was the number one factor in my improvement. It wasn't the big dramatic movements. It was the slow, controlled exercises that I did over and over again. With my diet, it wasn't a week of good decisions, it was a year. With learning how to camp and survive in the wild, it wasn't one tough night. It was camping every month, whether in wind, rain, snow, or sunshine, that taught me the biggest lessons.

When it came to making the screencasts for my course, I committed to making at least 2 videos a day, every day. Some days I could only get 2 done, others I would get 5 done. Just like with physical therapy, it was slow and difficult at first. At first, I had to trick myself into getting started after working at my day job by promising myself I would record at least 30 seconds of video each night. (This is a useful mind-trick, by the way. Try it with flossing - promise yourself you'll floss just one tooth every day and see what happens.)

Gradually, I got more efficient. I started learning editing tricks with my video software and keyboard shortcuts with my code editor. I got more confident in my narration and instruction. I got better at my day job writing code because I was hyper-focused on making these videos the best they could be. It took about a month of consistent action for this to start happening for me, but when it did, it paid off in spades.

When I hurt my back this fall, I went back to the same PT for a session or two, but the prescription was the same: 4-6 weeks of exercises, 3+ days/week. Slow, consistent, methodical healing. It worked, but I had to put in a lot of time and work consistently.

Adjust and Repeat

We've already touched on this part a little bit. Whether you're writing for 90 days, making 200 videos for a tech course, or following a specific exercise regimen, you're going to gradually improve and refine over the course of doing your One Thing.

I like to take it a step further than that and make it more structured with a defined timeline or end point. For health or lifestyle habits, I do 30 or 90 day increments. It takes about 30 days for me to adapt to something new, and 90 to really start seeing results. For projects, I use a different milestone. With my video course, I had defined a course "module" as a unit of teaching material, so each module I stopped to do a review.

In software development, we have something called a Retrospective at the end of each development cycle. This is a formal meeting and process where we review the work we've done and how we can improve going forward. You can make your personal Retrospectives as loose or as formal as you want, just actually do it. A lot of people skip this part (as do a lot of software teams), but it's my favorite, because I get to see how far I've come. I evaluate the following:

What's working?
What's not working?
What's my next goal?

Let's use the example of writing again, since that's fresh on my mind as a personal goal. Let's say I've done a 90 day experiment of writing every day. I can go back and look at which days I've missed, which days I was really flowing, and surrounding events. I might notice things like:

I write best in the morning after I've done some reading.
I missed more Saturdays than any other day.
The days I was really writing well were when I wrote over 1000 words.

From there, I can adjust course and start another experiment. Instead of writing 750 words a day, I'll aim for 1200 words a day. I'll rearrange things on my Saturdays so that I'm more likely to get my writing done. Maybe I've had an idea for a book, so my goal is to write a chapter a week for 8 weeks and re-evaluate.

At the end of the day, these self-improvement experiments are just that: experiments. Or even more fun: games. For me, it's not drudgery to try to get better (even though the daily grind might feel that way). My goal is to be slightly better today than I was yesterday, and however I need to gamify that to make it happen, I'm fine with.

The secret sauce.

We've reviewed the pieces of The Feedback Loop that I've learned this year, but there's a secret weapon that has kept me going: optimism. Optimism is not just hippy-dippy feel-goodery, it is a powerful tool. I made a choice last year to be exceptionally, obnoxiously grateful and positive. This wasn't because everything seemed rosy and perfect. In fact, it was the exact opposite in that moment. I was being told the sky was falling and I was discontent with my own path. I made the choice to be positive as an experiment. What did I have to lose? It's not like deciding to be grateful could make anything look worse.

It's easy to dismiss gratitude and optimism as hand-wavey and the emotional equivalent of sticking your head in the sand. That's not what I've found. I've found that I'm able to look harder at my problems, to allow myself to stop lying about where problems are and how bad they may be. I'm not beaten down by fear and uncertainty, I'm coming from a place of abundance and strength. So, when a setback comes up, I practice looking at it straight in the eye and trying to learn from it. That's not to say I don't get grumpy or frustrated. Bad stuff sucks. I was really pissed off at myself when I hurt my back. I hated being immobile and needing help from people. Even so, once I was done throwing my tantrum I looked for (and found) the lesson in it.

Let's go.

2017 was a good year for me, and not just because I finally admitted how much of a genius Kendrick Lamar is or started listening to Run the Jewels. I started this process of becoming a better version of myself towards the end of 2015, and amped up in 2016 by learning as many new skills as I could. Last year, I put it all together and started noticing The Feedback Loop. I'd love to hear your own experiences on the journey to becoming the best version of yourself.

Oh, one last thing. The ability to fail quickly and act consistently is a skill in itself, and one I'm practicing every day now, but I couldn't do it without surrounding myself with people who are supportive, positive, and encouraging. In this bizarre time in our society where we're so disconnected, get yourself a handful of like-minded people. Create a tribe of folks around you who are all striving to be their best, who look out for each other. In the age of social media and information overload often accompanied by media hype and despair, I find it increasingly important to have community in the real world, right in my backyard.

Now get out there - we've got work to do.

A Guide to Angular 8's Differential Loading

Sam Julien — Wed, 12 Jun 2019 17:57:56 +0000

TL;DR: Angular 8 is here! Learn all about one of its coolest new features: differential loading. Differential loading lets you serve up different bundles to different browsers and make your application even faster!

Angular 8 has only been out for about a week at the time I’m writing this, but there’s already been 17,000 “What’s New” articles published. Rather than throw my own take on the pile, I’ll refer you to the official Angular release announcement but here are the high points:

No, Ivy isn’t ready yet (it’s an opt-in preview).
No, Bazel isn’t ready yet (it’s an opt-in preview).
Builders allow you to extend and customize the CLI. For example, you’re now able to deploy to Firebase and other providers from the CLI.
There’s improved support for web workers, such as the ability to generate them from the CLI and use them in your application.
Rather than using the “magic string” syntax specific to Angular to do lazy loading, you’ll be able to use the standard import() syntax. You can even perform this automatically for your app with the angular-lazy-routes-fix tool.
The new unified location service improves migration from the AngularJS $location service.
The Angular team has created a simplified Getting Started Guide.
There’s a new Deprecation Guide to assist users with updating Angular.
Differential loading is turned on in the CLI by default.

In this article, I want to dive into that last one: differential loading. What is that? Why does it matter? What do I need to do about it (if anything)?

Continue reading 📖