DEV Community: Anthony M.

babel_fish - real time language translation

Anthony M. — Sun, 14 Apr 2024 21:47:15 +0000

This is a submission for the Cloudflare AI Challenge.

What we built

Douglas Adams came up with the idea of the Babel fish in Hitchhiker's Guide to the Galaxy. It's a fish that, once you've stuck it in your ear, allows any language to be translated to you in real time.

babel_fish is a real time language translation app built with Cloudflare, Svelte, and multiple language models. The app allows you to share a room with your friends in different languages. All messages get translated to your chosen language in real time!

@alicelovescake and I thought this would be a perfect app for trying out the fancy new Cloudflare Workers AI!

Demo

Le code

Frontend

The Svelte application contains the frontend code as well as all of our API endpoints interacting with the language models.

amorriscode / babel-fish

A real time translation app

babel_fish <><

This is a submission for the Cloudflare AI Challenge.

babel_fish is a real time language translation app built with Cloudflare, Svelte, and multiple language models. The app allows you to share a room with your friends in different languages. All messages get translated to your chosen language in real time!

This repo contains the Svelte frontend which includes API routes for interacting with the AI. The chat engine is handled by the backend.

Built with:

💅 Svelte
⚙️ Cloudflare Workers
🤖 Cloudflare Workers AI
📣 ElevenLabs

🚧 Requirements

An ElevenLabs API key
A running version of the backend

🛠️ Development

Note: wrangler is used to run the dev server so we have access to Cloudflare Workers AI

Create an .env file and fill in the variables

cp .env.example .env
Clone the frontend

git clone https://github.com/amorriscode/babel-fish
Install dependencies

npm install
Run the wrangler dev server

npm run…

View on GitHub

Backend

Our web socket backend uses Cloudflare Workers and Durable Storage. It's a simple logic engine that powers the chat rooms.

amorriscode / babel-fish-ws

Chat engine for the real time translation app babel_fish

babel_fish <>< ws

This is a submission for the Cloudflare AI Challenge.

This repo contains the websocket backend that powers the babel_fish frontend;

Built with:

⚙️ Cloudflare Workers
📦 Cloudflare Durable Objects

🚧 Requirements

A paid Cloudflare account to use Durable Objects

🛠️ Development

Clone the repo

git clone https://github.com/amorriscode/babel-fish-ws
Install dependencies

npm install
Run the dev server

npm run wev

View on GitHub

Journey

Tired: trying out one new technology during a hackathon
Wired: trying out tons of new technology during a hackathon

I've been admiring Cloudflare from afar for a while now. I love what they've been doing with Pages, Workers, and now AI Workers. This hackathon finally gave me a good excuse to play around with the platform!

Aside from all the fancy tooling Cloudflare provide, this was also my first time using Svelte (sorry Rich!). I actually really enjoyed the experience. I'd love to spend more time writing Svelte; I have a lot left to learn.

So... AI?

We used a ton of Cloudflare's available AI models to build babel_fish.

@cf/openai/whisper for voice-to-text
@hf/thebloke/mistral-7b-instruct-v0.1-awq for language detection
@cf/meta/m2m100-1.2b for language translation

Since a true Babel fish doesn't produce text we also used ElevenLabs for text-to-speech.

Challenges

We only had a single day to work on our project. The tight timeline and all new tech made it an exciting 24 hours.

The biggest challenge of this project actually ended up being the backend audio processing. With the initial POC, user messages weren't transcribed and sent over the wire until they were completely finished speaking. We were able to improve this by using AudioWorklets. Now we regularly check for gaps in a user's message and periodically process and broadcast messages.

The rest was easy because Cloudflare and Svelte made it so. 😎

Thanks to @cloudflaredev and @thepracticaldev for putting on this hackathon. If you're interested in this kind of thing, come work on experimental AI projects with me at Stripe!

<><

12 Products in 12 Months

Anthony M. — Sun, 02 Jan 2022 19:38:29 +0000

It's been a while since I've built anything for myself. One of the reasons I consider myself a "product-focused engineer" is because of my passion for building. Programming has enabled me to create something from nothing. Its turned me into a builder.

My partner and I have been talking about doing an ambitious project for 2022. We've decided to build 12 products in 12 months.

Why?

There are a lot of reasons I'm excited about this project. The first one was mentioned above.

I'm a builder. Creating things excites me. It makes me feel alive. I love everything from naming products, designing logos, writing bits of code, and setting up deployments. Every bit of the process is a fun way to flex my creativity. It brings me joy.

My partner is a computer science student. She's been developing her coding skills for some time now. Although we've collaborated before, she's grown a lot in the past 6 months. Now she's ready to take on bigger projects! For her, it'll be a great way to practice the skills she's learning in school and in her internships. It'll help her flex the programming muscle. It's a unique way for us to spend more time together.

I suck at marketing. I'm not great at design. The whole product life cycle is something I'm interested in. This project will be a safe space for me to play in areas I don't get to do as often at work. I'll be consuming a lot of product resources and seeing where we can take our products.

Timeline

We're making one product every month.

Some people I've told have criticized the project. You can't build a business in a month. You can't build a good product in a month. Tell that to Pieter Levels.

Either way, that isn't why we are doing this. We aren't setting out to build billion dollar startups here. We're looking to build skills, be creative, and to have fun. I do hope some of our products end up being useful for ourselves (and others!) but that would be a beneficial side effect.

At the start of each month, we're going to pick the product we want to build. We have a giant list but we're also open to suggestions! Once we've decided on the product, we'll break down our MVP and write tickets for work to be done. There's flexibility here. We're basically just going to use Kanban as we build throughout the month.

At the end of each month, we'll each reflect on what we've learned. Where did we fall short? What did we have the most fun doing? And of course, we'll post on Product Hunt.

Following Along

We've setup a public Notion page where you can follow along. This is where we'll do our planning. You can see each product, the scope of the MVP, and our tickets as we work through them.

We also plan to stream on Twitch every Sunday at 12 PM PST! This is will just be a fun way to interact with others. If you want to cheer us on, ask questions, or shit talk us, you can do it there. My guess is we won't have any viewers but it's just going to be another fun way to engage with the project. It should also add some aspect of accountability to the whole thing.

Our First Project

Today we decided on our first project, Poke! Poke is a personal accountability system. You setup recurring goals on the platform and get reminded about them via text message.

For example, if you want to go to the gym three days a week, you can add a reminder in Poke to message you on your gym days. Poke will keep track of when you accomplish your goals or when you've slipped up.

I've been thinking a lot about building platforms that interact with users by sending them text messages. I use Messages on my phone more than anything else. Don't be surprised if we build other text-based things later in the year.

This project is extremely ambitious. There's a good chance we don't even build 12 products. Some of our ideas could barely be described as products, others could be startups in their own right. A lot of people will doubt the value of this project or our ability to succeed. In the end, I don't care about any of that. I'm excited to be building. I'm excited to be giving myself permission to be creative just for the heck of it.

The last few years have been taxing on all of us. This project has me looking at 2022 with hope and excitement. I hope you find something to make you feel the same. I can't wait to get started.

I can't wait to share the journey as we make our way through 12 products!

Obtaining Your Ideal Software Job

Anthony M. — Fri, 24 Dec 2021 21:27:55 +0000

Finding a job is stressful for everybody. The standard tech interview doesn't help, does it? I've sent out a few emails over the past few years detailing my approach to the job search as well as some resources I use. I decided to write about it here so I can share it easier.

Finding Companies

The first thing I do when I know I'm ready to make a move is build a list of companies I'm interested in. It's hard to know what a company is like from the inside but it's important to me that I believe in the product.

Since I'm interested in smaller companies, I like to look at startups. Working at a startup can be risky. To mitigate the risk, I start by looking at companies on websites of venture capital firms.

I try to build out a spreadsheet of 50-100 companies. This list can be pruned over time too. Applying for jobs has always felt like a numbers game to me so it's nice to have a starting point.

What you look for in a company is likely different than what I'm looking for. The important thing is you build a list of companies that align with your needs and interests.

Practicing Daily

Given the current landscape of software interviews, it's a good idea to practice solving algorithms. It's extremely common to whiteboard a problem solving question during the process.

If you want to avoid whiteboard interviews at all cost (I don't blame you), you could look at companies that hire without whiteboard interviews.

I'm not particularly gifted with algorithms. Throughout the interview process I'll try to complete one to five algorithms a day. I really like practicing on Binary Search. LeetCode is a popular alternative full of common problems you'll see in interviews. If you're looking for more educational content, YouTube has tons or you could use something like AlgoExpert.

Being consistent will go a long way here. Do as much as you can daily. Even if it's a only single question, it'll help you in the long wrong.

Once you're ready to start interviewing in person, you can book a mock interview. It'll help you gain some confidence. I've never done this but I think it would've helped me. I once cancelled an algorithm interview 30 minutes before it was supposed to start because I had a panic attack.

Having a Portfolio

This might not be necessary but I love me a good portfolio. I've had interviews where people brought up something I wrote about on my website. It's a nice way to break the ice and connect with the folks on the other side of the process.

Having your own website makes it easier for folks to get another lens into who you are as a developer. Josh Comeau has a great resource on how to make an effective portfolio.

Keep in mind this is optional, but it can be a fun way for you to express yourself and tinker with smaller coding projects.

Fresh Perspectives

One of the things I like the most about reading is that I get the perspective of other people. There is a lot of content available online related to job interviews. Here are a few resources that I've found helpful:

The Tech Resume Inside Out
- Having a great resume is extremely important in the age of job screeners
The Little Book of Big O
- A great book for grokking time and space complexity
De-Coding the Technical Interview Process
- This book covers the entire interview process from start to finish
The Coding Career Handbook
- From the job hunt to becoming a senior engineer, this book covers the entire career path

If you're up for it, you can read Cracking the Coding Interview. That book bored the heck out of me so I found alternative resources. In the end, if you're expecting algorithms, reading won't prepare you better than practice.

Being Patient and Picky

As long as it's financially viable, I try to spread out my job search as much as I can. Finding companies, practicing, and interview is a lot to do at once. In the past, I've ended up doing 10 interviews in a single week. It's exhausting. If you're working on top of all of this, you might need to take up meditation as a habit.

If time is on your side, then you can be picky too. Rank your company list by your desire to work there. Start by applying to your top companies. Get through those then keep plugging along until you get an offer you're happy with!

I know that being patient and picky is a privilege that we won't all have. If you need something fast, don't feel bad if you end up leaving after a short period of time because something better came along. The job hunt is about finding a place to work where you feel fulfilled. You always need to do what's best for you.

Finding Your Process

The job search has always been a stressful experience for me. Building my own process around the search has helped me control my nerves. I even have fun with certain parts of the experience now.

This probably won't be the last time you apply for jobs so developing your own process will make it easier next time you have to do it. Hopefully some of the resources I've shared are helpful for you!

If you have any questions or comments, feel free to reach out to me. Good luck with your search!

Rest vs. GraphQL: A Critical Review

Anthony M. — Wed, 18 Aug 2021 16:06:09 +0000

Originally posted on the We Watch Tech website

This week at work, an engineer proposed that we start putting effort into ensuring our backend endpoints follow RESTful practices. The team was excited by the idea. Our endpoints don't currently follow any spec, RESTful or otherwise. You never know what you're going to get.

This proposal reminded me that I've had a talk on my YouTube watchlist for a while. An opinionated, critical view comparing REST and GraphQL. I've enjoyed the GraphQL developer experience in the past. I may be susceptible to shiny object syndrome, but there's clear pros to using GraphQL... right?

REST and GraphQL aren't actually the same thing. Z points out that REST is an architectural style while GraphQL is a language and framework. One is more like a suggestion while the other strict and tangible. Both of them help us create a communication layer between our distributed systems. Or, as Z suggests, we'll call them API paradigms for now.

A World of Constraints

One of my favourite parts of Z's talk is when he talks about constraints. When making any technical decision we should be looking at the constraints of our system. It seems obvious but defining your constraints can be quite challenging. They're bound to evolve as your systems do as well.

No matter what solutions we decide on, our choice should always a be a function of our constraints. Z gives a great example of someone who builds a colonial home simply because they like colonial houses. Well, those houses were built because of colonial constraints. Just because you can do something doesn't mean you should.

Constraints Imply Properties

Whatever constraints we build into our system, we can derive certain properties.

Having a decoupled client and server implies two codebases that can evolve separately. Having a stateless server implies that your server is reliable and scaleable. Having a stateless server decoupled from our client will ultimately give us a codebase with reliability, scalability, and evolvability built in.

Properties of Distributed Systems and Ecosystems

So, if constraints imply properties, what properties should we care about? This will also depend on your situation. Z does suggest a few properties to consider.

Distributed System Properties

Performance
Scalability
Simplicity
Modifiability
Visibility
Portability
Reliability
Discoverability
Type-safety
Developer experience
Cost effectivity

Distributed Ecosystem Properties

Community
Tooling
Ecosystem maturity
Resources
Enterprise readiness

For any system you're architecting, you'll want to pick the properties you care most about and optimize for those. It's rare that any one solution checks all the boxes.

Every team is going to have different types of constraints. From business (customer or product requirements) to cultural (resources or knowledge). They will also be optimizing for different properties. Because of this, there will never be a clear winner for arguments like REST vs. GraphQL.

That won't stop us from arguing about it though, will it? Let the battle commence!

The Weigh In

There are two contenders in this fight. REST is old. Tried and true but starting to show its age in the ring. GraphQL has a spring in its step. But sometimes rookies make simple mistakes. This is what Z has to say about the pros and cons for each solution.

REST

Pros

Scales indefinitely
Great performance (thanks HTTP2)
Tried and true
Affordance-centric (API is expressed as structured messages)
Server-driven
Decoupled client and server

Cons

Huge barrier to entry (difficult to master, etc.)
Challenging mindset shift from SOAP to REST
Poor (or no) tooling for clients
No framework or tooling guidance
Requires discipline
Even hard for experts to get it right
Hard to keep consistent
Hard to govern

GraphQL

Pros

Easy to start with
Easy to produce and consume
Lots of hand-holding
Contract-driven
Built-in introspection
Easy to keep consistent
Easy to govern
Closer to SOAP

Cons

Ignores problems of distributed systems
Queries can be suboptimal
Bikeshedding age old solutions (caching, etc.)
DIY scaling and performance
Ignores hard work done by HTTP (POST for everything!)
JSON all the things
Lack of ecosystem maturity

The Clear Winner

There isn't one. Both of the options have plenty of pros and cons. Like everything in the world of software, there are many ways to skin an eggplant.

If you're looking to make a decision between REST and GraphQL, it might not be an easy one. Start by narrowing down the properties that are most important to you and work your way back.

Where REST Wins

If you're looking to build a system for the long term. REST isn't a new idea. It's been battle tested. There are standards built around important things like authentication, caching, and rate limiting. It has scalability in mind.

Where GraphQL Wins

The communication between your frontend and backend are simple. Or if you want a data-driven approach to the API paradigm. Also, the developer experience is pretty darn enjoyable.

So-Called REST

All of the information covered this far is useful, but it wasn't the most mind blowing for me. You probably don't have to search to hard to see a lot of this covered elsewhere on the interwebs.

One of the cons Z listed for REST piqued my curiosity. It was the fact that there is a huge barrier to entry. I've seen "RESTful practices" used a lot in my career so far. I thought I knew REST. It turns out, I've seen more so-called REST than anything else.

Here's a quote written in 2008 by Roy Fielding(he created REST by the way):

What needs to be done to make the REST architectural style clear on the notion that hypertext is a constraint? In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period. Is there some broken manual somewhere that needs to be fixed?

I've never actually seen a REST API that reached level three on the Richardson Maturity Model. One that has true discoverability and uses hypermedia as the engine of application state.

But does that matter?

Z argues that GraphQL is far better than a so-called REST API. The proposal at work this week was for a so-called REST API and I'm not mad about it. We're optimizing for properties like simplicity, portability, discoverability, and developer experience. In our current system, those properties are sadly lacking.

There's a lot of tooling out there that makes REST more accessible these days too. From the OpenAPI specification to things like Flaks RESTful.

Even with that in mind, I can't help but think about GraphQL. Can we optimize for the properties listed about while solving other problems clients face like slow and spotty internet?

Microservices

When mentioning microservices, I was surprised to hear Z recommend REST. He says it is almost as if they were born to be used together. What about gRPC? Or an event-driven architecture? I think there's more to the story here.

No Contest

This talk hasn't made me more confident in my ability to implement a RESTful API. It hasn't shown me that either option is the obvious solution for my API communication woes.

We will forever have to decide between many options to solve our problems. Framing these decisions based on the constraints and desired properties of our systems will always lead to better results.

Even though there's no clear winner to this fight, there are a ton of great resources about REST, GraphQL, and APIs. Here are a few worth looking at:

*I never thought I'd be reading API guidelines from a shoe/fashion company. It turns out they have a decent amount of open source projects!

Convergent Evolution

Anthony M. — Tue, 18 Aug 2020 19:11:51 +0000

I originally published this on We Watch Tech. It's my side project that helps me think more deeply about great tech talks.

Have you watched a good talk lately? Let me know!

This talk came on my radar when Shawn Wang tweeted about it. He said it was one of his favourite talks from React Rally 2017 so that seemed right up my alley.

I'd be lying to you if I said I knew much anything about Elm. I've heard of it, sure. But that's about it. So what better than an introduction from the creator himself?

Evan takes us through a comparison between React and Elm. I am familiar with React, so the comparison helped me a lot.

Convergent Evolution (Who Did It Better?)

Before we get into the React/Elm comparison, Evan introduces the concept of convergent evolution. So what is that exactly? It's the independent evolution of similar traits in different organisms.

In the wild we can compare birds and bees. Both of these organisms have wings. They both can fly but the similarities mostly stop there.

As developers we often look at two similar things and start to ask ourselves, which is better? We look at the implementation details and we start to pick sides. Evan prefers to take a step back and look at the design as a whole. How well do the features serve the overall design?

Elm vs. React

While the folks at Facebook were being inspired by XHP, Evan was working on his thesis. They separately came to a lot of the same conclusions. Convergent evolution. One is not necessarily better than the other. Remember, it's not about the implementation details.

So let's take a look at some of these converging ideas.

Style

React, or at least JavaScript, uses a syntax that is similar to C. Evan makes a good point when he says they chose to onboard folks with familiarity. People are comfortable with the syntax so it makes it easier to adopt.

Elm uses a syntax that is more like ML (Meta Language). There was a deliberate choice in the style. It fit better with the overall design of Elm. The tradeoffs for onboarding with familiarity were worth it for Evan.

During the talk I saw Elm code for the first time and it wasn't much like any programming language I'd seen, or at least worked with. While I do prefer the C-like syntax (because I'm used to it) there is a nice comparison with JavaScript on the Elm site.

Virtual DOM

A virtual DOM is a tree of custom objects that represent a real DOM. We utilize a virtual DOM because we can manipulate these custom objects much faster than we can manipulate the DOM itself. We can change our virtual DOM and then use a reconciliation algorithm to update the real DOM with just the changes we've made.

Both React and Elm are able to incrementally update the DOM because of this technique. It allows us to build our reactive user interfaces. Elm boasts better performance because of how it does diffing. The purity and immutability helps—we'll touch on that later.

I've seen a lot of complaints about JSX. If you're in the anti-JSX camp, perhaps you'd prefer to play with Elm. There's no special syntax when it comes to working with Elm's virtual DOM! It's Elm all the way down. I don't mind having HTML in my JavaScript but I can understand the appeal.

Unidirectional Flow

It's very common to see unidirectional flow in React. It's encouraged. In Elm, it's a first class citizen. Legend has it that early Elm programmers kept seeing the same patterns in their code. The unidirectional flow naturally arose from the language itself.

In the Elm Architecture you can clearly see the unidirectional flow. It's a very functional pattern. Inside of Elm there is a model. It captures all the details about your application as data. We also have the view. This is a function that outputs your HTML. When users interact with the HTML, messages are sent and an update function handles changing the model.

At Facebook they were using a similar architecture pattern called Flux. The popular library Redux even got inspiration from Elm.

Both of these patterns have similarities. André Staltz has written a great blog post about unidirectional architectures so I recommend you give that a read. A major difference between Flux and the Elm Architecture is the fact that everything in the Elm Architecture is hierarchical. Components aren't just on the "View" layer.

Functional OOP

The unidirectional flow is a very functional pattern. In React however, we can almost think of components as objects. They hold their own local state. They have methods for updating that state. This can lead to some OOP patterns that simply can't exist in Elm because it is a functional language.

Immutability

Immutability is another area where Elm simply shines. When your data cannot be changed it is easier to write programs that behave as we expect. This leads to more maintainable code. In Elm's case, it also makes it very cheap to determine if two things are the same. Combined with purity (functions always return the same output, given a certain input) this lets Elm applications avoid extra work. That's one reason Elm is so fast.

React will let you use any style of data management you want, including mutation. That means these performance benefits don't come baked in. There are tools to help with this but again, Elm just makes it simple and pleasant to work with.

Static Analysis

The last thing we'll look at is static analysis. With React there isn't much to talk about. If you are familiar with linters that's just about the best you get with React.

Elm is a language so there is so much more to offer you out of the box. The compiler is an assistant. It helps you find edge cases you might have missed. The compiler will even give beginner friendly hints!

A Tale of Two Organisms

I'm really excited to take a closer look at Elm and see what it has to offer. The compiler looks extremely promising and there are a lot of other wonderful features (like enforced semantic versioning). The ecosystem seems very tight to an outsider. I think the opinions of Evan have shaped a language with great features that keep the big picture in mind.

Some might argue that it's unfair to compare a library to a language. That said, it's an interesting comparison. I've always found it fascinating when scientific achievements are made at the same time across the globe. I love when different ideas are shared, remixed, and discussed within the tech industry.

Birds and bees might fly differently but there is no way you can argue that flying isn't good. React and Elm achieve similar things in different ways. Neither is necessarily better than the other; just different.

Launch Day

Anthony M. — Mon, 09 Dec 2019 01:46:03 +0000

Earlier today I was reading a post that @kimmaida wrote at the start of November called 7 Tips for Career Advancement and Personal Fulfilment. I'm constantly thinking about how to improve myself and move forward. The article had great tips and it inspired me to write this.

Value Finishing Over Starting

Kim talks about setting personal goals. Earlier this year I set a big goal for myself. One that would solve a systemic problem I built in the past.

I love starting projects but rarely finish them. A lot of us are probably like this. Something new and shiny comes along and you jump on it. I'd been thinking a lot about creating instead of simply consuming. Because of this, I decided to start valuing finishing over starting.

What does this mean? I simply wouldn't commit to anything big until I finished what I was currently working on.

This mentality allowed me to finish building my new website, launch my first Chrome extension, and start studying computer science at an online university.

Halfway through the year I set out on my biggest project yet. To develop an online platform for mental health.

Write With Wrabit

Tomorrow that project is finally going to be announced on Product Hunt. Since Kim mentions sharing wins and celebrating milestones I thought posting here would be okay.

I'm incredibly proud of the product I developed. Users get to build a daily writing habit in a simple online editor. The more they write, the more we donate to mental health research.

The product will never make me rich but it might make a positive difference in the world. That is what makes me proud about it. That is why I wanted to write this post.

This feels like the biggest win of my life. 🎉

Why Mental Health?

When I was in high school, I suffered from depression. I dropped out of high school and told myself I would never make it to 25. I felt terribly alone and afraid to get help.

Thankfully, somehow, I was able to find tools (meditation, writing) that got me to where I am today.

I know a lot of us are suffering. I kept trying to think of ways I could help. Eventually I thought of Wrabit. A platform to help write daily. A tool to explore the feelings inside you. Something to give people the confidence to express themselves unedited.

Launch Day

Tomorrow is launch day. I've done the best I could to make the MVP what it is today. It's been in progress for 38 days and is completely open source.

It's not the best code I have ever written. I didn't use test driven development. I took shortcuts so that I could make sure I launched the thing. Again, finishing over starting.

With all that being said, I have never been more proud of myself. This is just the beginning.

Thanks for taking a look and I hope to share more of the journey with you in the future!

19 Takeaways From React Conf 2019

Anthony M. — Sun, 27 Oct 2019 17:11:03 +0000

Originally posted on my personal blog

Well React Conf ⚛️ is officially over. There were a lot of great talks, human beings, activities, and of course food. I'm still digesting the whole event but, as far as conferences go, this has been the best one I've attended so far.

The developer community can often be intimidating. The volunteers and organizers did an incredible job making everyone at the conference feel welcome. I was impressed at the lengths they went to make us all feel like we belonged. There were even some introvert activities on the second day. Have you ever painted a minifigure (think Warhammer) at a conference? I have now! So for all those involved, thanks!

This post is going to be a reflection of some of my favourite React Conf takeaways. Every single talk was worth watching, so I recommend you check out the recordings for day one and day two. I've included timestamps to all the talks at the bottom of the post.

You might be surprised by some of the items on the list. I was too! Not everything is technical but there is a common thread weaving throughout.

1. Developer Experience In Service of User Exeperience

After Tom Occhino said it, I couldn't stop thinking about it. I couldn't stop seeing it in all the talks. I realized what I love so much about developer tools and the frontend.

React aims to create a developer experience that allows us to easily learn to do powerful things, to launch and iterate by being productive, and to scale the software we make. These things alone make me like React. I feel like Facebook is doing a pretty good job on delivering.

What is the point of all this though? Well, that's simple. It's to serve the user experience. We do what we do so that we can make our users productive. We should aim to help them get what they want done in elegant ways. Although what we help them achieve may not always be simple behind closed doors, it should always feel that way to them.

Because React is a gateway techhnology with 63% of JavaScript developers using it, the team are taking things like community very seriously. They have adopted the Contributor Covenant and are welcoming criticism. As a community we should be able to accept criticism without having to defend ourselves. Elbert Hubbard said "To avoid criticism say nothing, do nothing, be nothing." What React is doing, and why, is important. This will naturally draw in criticism and allow the technology to grow. It will allow us as a community to be better.

2. Accessiblity and Performance and Concurrent Mode, Oh My!

Have you ever had issues with focus while using React? I have. Focus is really important for many reasons. It helps people navigate their way through a page. This is extremely important for people who don't use a mouse. This topic will come up again later, but it was nice to see the React team wanting to make accessibility baked in.

One of the things that got me thinking the most during the conference was performance. Facebook has to deal with performance issues that most of us never will, but the lessons they have learned can still be used to make the user experience better. It doesn't matter how fast a page loads if the perceived performance is slow.

An example of this is selective hydration which Yuzhi Zheng explained during her talk. You may have heard of Suspense as well, which will improve user experiences all over the web.

Concurrent Mode

Imagine making a filterable list tied to a user input. With React, you'd probably have to debounce or throttle your updates to the list unless you're okay with jank.

Concurrent Mode will enable React apps to be more responsive by giving React the abiility to interupt blocks of lower priority work. This allows things like user input to get more priority over things like re-rendering a list. React will be able to work on several state updates concurrently. This will help us remove jarring and too frequent DOM updates. It will also allows us to give priority to interactions like hover and text input. We know that users expect these to be handled quickly or else they will feel laggy.

The React team have shared many examples of concurrent mode patterns that I recommend you check out.

3. CSS-in-JS-at-FB

I was interested to hear Frank Yan announce that Facebook is building their own CSS-in-JS library. At first I thought, don't we have enough of them? This gave us an opportunity to learn more about some of the problems Facebook faces at scale and the creative ways they are solving them.

Maintaining CSS can quickly get out of hand. Let's look at the following example:

.blue { color: blue; }

.red { color: red; }

<span class="red blue">
  Which color will I be?
</span>

In this example, it would be nice if the text would be blue. That class comes second in the class declaration so we should be able to expect it to take precedence. But it doesn't. The .red class comes second in the cascading style sheet so that's what we end up with. If these classes were in different style sheets, the order in which they are loaded in the page would matter.

This problem might seem simple with such a naïve example but it can get out of hand quickly. Facebook has aimed to resolve things such as specificity wars, themeability, and accessibility with their new library.

A couple of interesting specifics from the talk:

Developers can code in pixels but have their work compiled in REMs
They have created safety by implementing type checks (catch and fix typos, detect and remove unused styles, avoid cross-browser pitfalls)
Display accessibility errors to developers

Components can have default styles that can be overidden (including type safety!)
Rules are deduplicated which allows smaller CSS files (Facebook went from 413kb to 74kb in their recent frontend rewrite)

Atomic CSS

Each class creates a unique property value pair. This is used to optimize the components

.c0 { color: blue; }
.c1 { color: red; }
.c2 { font-size: 16px; }

// Generated Component (Pre-Optimized)
const styles = {
  blue: {color: 'c0'},
  default: {color: 'c1', fontSize: 'c2'},
};

function MyComponent(props) {
  return (
    <span className={styles(
      'default',
      props.isBlue && 'blue',
    )}>
      Hello World!
    </span>
  );
}

This example shows how the CSS is atomic. It also shows how the color of a span could be set with props. However, this code gets optimized further.

// The styles block is no longer needed
function MyComponent(props) {
  return (
    <span className={styles(
      (props.isBlue ? 'c0 ' : 'c1 ') + 'c2 '
    )}>
      Hello World!
    </span>
  );
}

At of these things are extremely interesting and I look forward to them releasing their library in the future.

4. Data-Driven JavaScript

Have you ever wondered how to make your pages feel faster? Become interactive sooner? Of course you have! Ashley Watkins has too. She really got me thinking how I could use adjust my data-fetching approach to make a better user experience. I had already started to get excited about Relay but she added fuel to the fire.

Phased Code Splitting

You can bet the folks at Facebook have been working hard to ensure their FMP is as fast as possible. One of the ways they are doing this is "Phased Code Splitting".

With this approach, you can take a single blocking download and deliver it in phases. For example, if you consider the Facebook post, you could break it into 3 phases.

Loading
Display
Analytics

Each of these phases can have their own code fetch and render. All the data required for the FMP can be fetched at the same time the loading phase fetches its code.

Time to First Meaningful painted

To make your user experience as good as it can be, you should be thinking about first meaningful paint. This is basically how long it takes for the primary content to appear on the page. There are many metrics you can look at and measure to improve your load times, but FMP sticks out.

Relay allows you to make streamed queries with GraphQL. This will allow you to mark certain data as critical and other data as less critical. You can then get the most important stuff from the server first and show that while fetching the rest of your data. With this approach, you can render content as it arrives!

Data-Driven Code Splitting

This one blew my mind a bit. Relay is powerful, no question there. Relay has a new feature that lets you expand your queries to express which component code you need to render specific data types. 🤯 You can think of your code as data. As the server is resolving your GraphQL query, it can let the client know what component code it is going to need to download so it can get it faster!

Ashley's talk was pretty incredible and she promised that these things are just the beginning. I haven't used Relay yet but I'm excited to get started and I bet you will be too (especially when you hear more about what it can do).

5. Solving World Hunger

Day one started of with a great group of talks from people that work at Facebook. They were exciting from the technical perspective. We got to see a lot of upcoming features in the ecosystem to help us improve the user experience.

Tania Papazafeiropoulou switched gears a little bit to educate the attendees about world hunger and a cool product she's working on called OLIO. It helps people share food instead of wasting it and its powered by, you guessed it, React.

It was upsetting to find out that 1/3 of all food produced is wasted. On top of that, we could solve world hunger with just 25% of food waste from the US, UK, and Europe. These sobering statistics make solving world hunger possible and it was awesome to hear about a team working to do that.

This talk didn't get me hyped about new React features but it reinforced what makes React great. React (and React Native) enabled Tania's team to build out their product quickly and start making a positive impact.

6. Making REST Feel Better (and Safe)

RESTful APIs aren't a new hot 🔥 concept. They were formally defined in 2000 and have been used with success since then. That being said, REST does have some things that make it challenging.

Facebook answered these challenges with GraphQL. GraphQL gives us an understandable definition of our data. It gives the client the power to get only what it needs. This is a pretty great way to get faster render times as you don't have to download as much data!

Tejas Kumar summed up the differences quite nicely (see his talk for more depth):

REST

❌ No formal spec
❌ Guessing games (will an unallowed request respond with 400, 401, or 404?)
❌ Meaningless conversations
❌ No contractual agreements

GRAPHQL

✅ Formal spec
✅ No guessing games
✅ Meaningful discussions (things that impact users)
✅ Strong contractual agreements

Many of us love GraphQL but sometimes it isn't an option for our APIs. Tejas and his team have developed a tool to take some of the pitfalls away from REST. It includes code-generation from Swagger and OpenAPI specs.

I don't believe I do Tejas justice but his talk left a lasting impression on me. Seriously, go watch his talk!

7. Under React's Hood (Building a Custom Renderer)

If you've ever given a demo of something you coded before, you know it often goes wrong. Sophie Alpert took the risk and educated us on what it takes to build a React renderer.

I don't consider myself a React expert (yet 😅). I have never looked at the React codebase. I always assumed it would be beyond me. As I continue to learn and master React, I will continue digging deeper and will eventually get to the codebase itself. Sophie made it seem a lot less intimidating as she built her own custom render in real time on the React Conf stage.

Other than learning how awesome Sophie is, I feel like I came away with a small understanding of how React renderers work. She didn't leave me scratching my head. Everything was explains simply but also demonstrated clearly. What more can you ask for from a live coding demo?

May the Demo Gods forever be in your favour Sophie!

8. Localization (It's Important!)

As a native English speaker, I have to admit that localization isn't the first thing that comes to my mind when developing a product. Thankfully I am aware of this and am going to take it more seriously in the future.

I think localization often gets missed because we focus on users who are just like us. There is no reality where your users will be exactly like you! That is why we need to do user testing, get user feedback, and be more inclusive to all types of humans.

Last year, Nat Alison asked the question "is React translated yet?" When she originally posed the question, the answer was no.

Why does this matter? Well, Nat put it pretty nicely. If React is only accessible to English speaking people, how many people aren't able to use the tools to build amazing products? How much are we losing out on by only having English speakers shape our digitl world? Only 20% of the world's population speaks English. If we don't help others use React, we all suffer!

It is incredible what Nat and thousands of people have accomplished in the last year. There is still more work todo and you can help if you are bilingual!

9. The Accessiblity Marathon

Just like localization, accessibility can be difficult. You have to think differently when you are developing for accessibility. You have to think about a broader audience, about people who might be different than you. Sometimes that is difficult but we can all do it.

Running a marathon 🏃🏻‍♂️ is another example of something that can be difficult. According to RunRepeat, 1,298,725 people finished a marathon in 2018. They didn't wake up with the ability to do that. They started small and worked their way up to it.

That's how we can approach accessibility. Taking an approach like this will remove some of the feeling of overwhelm if you are starting from square one. One of my favourite things about React Conf was learning about software development, and the world, from new viewpoints. Brittany Feenstra was one of the people who helped me expand my perspective and I want to think more about accessibility going forward.

I'm not going to complete the accessibility marathon over night but I can do a little more each day going forward. Thankfully, there are a lot of good tools to help me along the way.

10. You Don't Need Redux (Right?)

In 2019 there are many different ways to manage React state (even vegetarian friendly options).

With so many options out there it can be hard to know what is the right choice. Unfortunately the right choice will depend on you. Just remember, developer experience is in service of user experience. Knowing that, I liked to approach my state management by going as simple as possible and changing as I outgrew my original decision.

I am very happy that React has so many options built within it now. With Context and Hooks, you can do quite a lot without ever needing to pull in another dependancy.

In order to move fast and break things, you have to be willing to throw out work you've done before. You need to fall in love with the refactor and move past decisions that worked for you when your product was different. I think the many options for React state reflect this. Some of the options require a lot of boiler plate, some don't. Some are baked in, some aren't. Pick what feels right for you now and adapt later if you need to.

11. Time Travel To 1999

The last talk of the day had me interested from the title alone. What was it like to program in 1999? I was only nine years old then. Some people were coding by nine. I was not one of them. 😢

This talk was another one that really needs to be watched. Lee Byron delivered a well-polished gem. He walked us through a time when PHP and the LAMP stack were the go to tools for web development. For those that weren't coding in 1999, he explained the evolution that lead Facebook to develop tools like React, GraphQL, and Relay. For those who were coding then, nostalgia.

I have always respected the engineering work done at Facebook but this talk put everything in perspective. Working with React has felt like a privilege and now I know where that privilege came from. I'm inspired by the work people like Lee have and continue to do for the community.

12. Even Dev Tools Are About UX

The theme of the conference continued to be elaborated on as Brian Vaughn kicked off day two. If you build things with React, you've likely used the React Dev Tools. They have definitely helped me dig myself out of messes I've created.

The React Dev Tools got a full rewrite that gives us:

Better performance
New API support
New UX features

See, even the dev tools focus on great UX!

I was impressed by the changes the team made to help navigate unfamiliar projects. Although you may thing of code you never touched as unfamiliar, we all know that even our own code can seem foreign with time. We can now see how prop flow through components, filter our component trees, deeply inspect components, and use hooks with the dev tools. One of the other things I loved seeing was the suspense toggle. That's a feature that seems extremely simple but will quickly become invaluable.

Along with shared profiling, the new dev tools make it easier to find why things rendered. There are similar tools out there but now we can get insight on your renders directly in the dev tools.

There are a ton of other great additions and I recommend you go explore them for yourself.

13. Suspenseful Data (Relay is Awesome)

I think I'm probably late to the Relay party. In fact, I'm late to the GraphQL party. In my side project I have been using GraphQL and I really enjoy it. After this conference I'm looking to explore Relay and take advantage of the power the combo provides.

React Suspense wants to enable us to show some of a UI without waiting for all of it to become ready ⏱.

Let's take a look at a basic example of a component that shows a loading state (using Suspense) when it is fetching data:

const Composer = (props) => {
  const data = useQuery(graphql`
    query ComposerQuery {
      me {
        photo {
          uri
        }
      }
    }
  `, variables);

  return (
    <div>
      <img src={data.me.photo.uri} />
    </div>
  );
}

const Home = (props) => (
  <Suspense fallback={<Placeholder />}>
    <Composer />
  </Suspense>
);

In this example we have a Composer component that fetches a URI to my profile picture and then displays it. You can see in the Home component that we have wrapped Composer within a Suspense block. Then, while the data is loading, Placeholder will be rendered. This pattern can be thought of as Fetch On Render.

Using this pattern, the loading sequence will be as follows:

As you can see, this allows us to easily handle data loading. We can provide a better user experience by falling back to a loading component, like a placeholder or spinner.

The pattern above already provides a lot of benefits and flexibility to do cool things. However, the Facebook team didn't like that you had to render to figure out what data the component needs. In order to get over this, they have started to use a pattern they call Render As You Fetch.

Essentially, to enable Render As You Fetch, the Facebook team has decomposed useQuery into two pieces. It is separated into preloadQuery and usePreloadedQuery. What exactly does that mean?

`preloadQuery`

This API will fetch data and give a reference to the results. It doesn't give you the actual data.

You would call this API in the same event handler that would display new UI. For example, if a user clicks on a link that will trigger navigation to a new page, the event handler where we handle the click will use preloadQuery. Hovering over something to open a tooltip would be another example of where you'd call this API. The onHover event handler would call preloadQuery.

`usePreloadedQuery`

This API takes the results of the preloadQuery call. It doesn't actually do any data fetching itself. It looks at the current state of the preloadQuery. If it is ready, it displays the results. If it is not ready, it suspends. If the query has failed, then we can throw an error.

No matter what happens, usePreloadedQuery will never trigger a new fetch. This makes it efficient and predictable.

Using these two APIs instead of useQuery will provide a loading sequence that looks like the following:

I definitely recommend you listen to Joe Savona explain the concepts I've summarized above. He does a better job and gets more in-depth. This was one of my favourite talks because I'm excited by the possibilities this pattern enables and can't wait to try it myself.

14. React is Fiction

Jenn Creighton gave my favourite philosophical talk of the conference. She background in creative writing. Creative writing has always been something I loved. Like Jenn, I once fantasized about becoming an author. There was a concept she explained during her talk that translates to coding in an interesting (and unexpected) way.

Show, don't tell

Let's look at two ways to convey the same meaning (courtesy of Jenn).

She is tired.

Her footsteps are heavier than before, the weight increasing as she trudges towards the bed, collapsing face-first onto the mattress.

Same idea, right? She is dead tired. Which one is more powerful? Well that's obvious. As software engineers we often fall into the pit of telling. We abstract, abstract, abstract away until we are DRY 🌵 as can be.

Most of the time, I do try to avoid repetition in my code. The principle makes sense but, like the rules of writing, sometimes we need to break the rules of software development. Let's compare two different pieces of code achieving the same result.

const Nav = ({ links }) => (
  <nav>
    {
      links.map(link => (
        <Link to={link.to}>{link.name}</Link>
      ))
    }
  </nav>
);

const Header = () => {
  const links = [
    { name: 'Home', to: '/home' },
    { name: 'Settings', to: '/settings' },
  ];

  return (
    <>
      <Nav links={links} />
    </>
  );
}

This seems like it will work great, but what if we want to add a nav item that is an action? For example a login button.

  const links = [
    { name: 'Home', to: '/home' },
    { name: 'Settings', to: '/settings' },
    { name: 'Login', to: '??' },
  ];

Our Nav component doesn't handle this edge case. We could easily implement a method for it to handle it but this could easily get out of hand. We could refactor the Nav component to look something like this:

const Nav = ({ links }) => (
  <nav>
    {
      links.map(link => {
        return link.to
          ? <Link to={link.to}>{link.name}</Link>
          : <a onClck={link.onClick}>{link.name}</Link>
      })
    }
  </nav>
);

This would work but how many edge cases will we cover before it becomes harder to reason about our Nav component? We could rewrite the Header component another way.

const Header = () => {
  const links = [
    { name: 'Home', to: '/home' },
    { name: 'Settings', to: '/settings' },
    { name: 'Login', to: '??' },
  ];

  return (
    <nav>
      <Link to="/home">Home</link>
      <Link to="/settings">Settings</link>
      <a onClick={onSelectLogin}>Login</a>
    <nav/>
  );
}

I've simplified the example that Jenn delivered in her talk but I think it gets the point across. The second Header component is much easier to reason about. The abstraction didn't provide much benefit even though we might be repeating ourselves now. If we wanted to add an Icon component into one of the links, we don't have to handle all the edge cases in a Nav component anymore, we can just add it where we want it.

Jenn also quoted a great Neil Gaiman quote that I can't resist sharing.

Remember that, sooner or later, before it reaches perfection, you will have to let it go and move on and start to write the next thing.

I've been practicing getting to good enough while I've been building Wrabit, a mental health writing platform. Sometimes it makes me feel like less of a developer. Sometimes it makes me feel lazy. In the end, I'm going with what I can easily understand, what I can ship, and what I can always refactor later.

As Jenn said, refactoring is not failure. Her talk weaved creative writing with programming so elegantly, I'll definitely be watching it again.

15. UX-Driven Fluid Animations

I haven't gotten around to making too many animations. I envision a future where I take awesome UI designs from Dribbble (animations and all) and build them out for practice. Animations are definitely delightful bits of design porn, but we need to keep the user experience in mind even with these.

Like most of the talks, Alex Holachek got me thinking in a new way. I love UI interactions. They make me feel warm and fuzzy inside. When looking at them, I'm guilty of not considering all of the users.

How to the fancy animations work for someone using a Nokia 6? At $283.97 CAD from Amazon, I could afford that many times over before the new iPhone. I'm guessing a lot of other people are in the same camp.

Alex helped me remember to think more about the average. Average phones, average data speeds. Build for average and high end will always be fine.

Also, event.preventDefault() will do bad things to your scrolling.

16. Iterating on Real Experiences

If you couldn't tell, there was tons of variety in the talks this year. Luca Demasco kept things fresh by showing us the process of iteration as he developed the Wick Editor with Zach Rispoli.

The Wick Editor is a free and open-source tool for creating games, animations, and anything else your mind can come up with. When Luca showed off the current version, I was really impressed with the UI. It seemed intuitive and had plenty of functionality. That wasn't always the case.

Luca and friends got to where they are today by constantly iterating. They didn't just iterate for the sake of iteration either. They brought Wick into many different environments (schools, libraries, etc.) and brought the interface in front of many different users (beginner, intermediate, young, old). They took a laser focused approach and gathered feedback that helped make Wick what it is today.

The honesty in the process inspired me as I think about how to iterate on my own product. How can I launch something quickly and iterate with intention? I don't have that experience so sometimes the confidence escapes me but its a process I'm excited to take. Seeing people like Luca share his experience encourages me and I'm grateful for the honesty that was shared by everyone during the conference.

17. The Complexity of Simple Things

Do you use react-select? No? You probably do but you just don't know it.

The component has over 18k stars on GitHub. It has 1.5 million downloads per week. That's a lot.

You might not think that one simple React component could be all that complex. You would, of course, be wrong. Jed Watson has developed a React component that is beautiful and serves its purpose well. It has plenty of functionality and works great out of the box.

Jed travelled a long (and sometimes arduous) road to get react-select to where it is today. He shared great insights on what its like to develop a massively popular open-source project. He also showed how simple things can often be quite complex.

I was inspired by Jed when he showed off the evolution of react-select to v2.0. He reiterated the importance of refactoring and the wonderful things you can accomplish if you stop chasing perfection.

18. Beautiful Transparency

Government spending is an important topic. We deserve to see where our tax money is going so that we can keep the government accountable.

Lizzie Salita demonstrated that government websites can be performant, easy to use, and beautiful. I was actually quite surprised when she demoed the USAspending.gov spending explorer. Compare that to the Canadian version and you'll get an example of how much React can shape the user experience.

I'm slowly starting to get my feet wet with regards to politics. While I have always tried to stay informed enough to vote, there is so much more I can do. Having tools like USAspending.gov in your hands makes it easier and more interesting. I think we should continue to develop tooling like this to enable everyone to stay informed so that we can all be involved in shaping our future.

19. Wonder-Driven Development

The last talk of the conference really blew my mind. Like Alex Anderson, I am a big fan of space 🚀. Alex has built an insanely complex starship simulator called Thorium.

The Thorium simulator empowers many organizations like the Lion's Gate Space Center to provide STEM-related activities for all kinds of people. These space centres allow students to grow through group activities that are highly interactive and educational.

There have been more than a few presentations and people at React Conf doing highly inspirational things for good causes. Alex's work sticks out because his passion leaks out of every word he says. He loves what he is doing and is an extremely talented engineer. He's using the technology available to him to build great experiences for kids and adults alike.

My favourite take away from Alex's talk (it's going to take me a while to fully digest it) is the concept of wonder-driven development. Have you ever wondered about the possibilities of technology? What about what you are capable of? 🤔

These types of questions drive us to build fun, enjoyable, and truly beautiful experiences. These types of questions allow engineers at Facebook and companies all around the world to shape our world with technology.

I've learned so much from everyone I came across at React Conf this year. I'm grateful that I was able to attend and am feeling full of wonder and excitement.

I can't wait to see what that wonder drives me to develop!

As I mentioned before, these are just a few of my takeaways. There were many libraries, techniques, and philosophical ideas shared throughout the two day conference. I wish I could have captured them all! If you go next year you'll know what I mean.

If you'd like me to expand on any of these ideas I'd be more than willing to. Reach out and let me know!

Finally, it would be a crime not to mention Devon Lindsey. She gave us laughter, candy, and introvert activities. The conference wouldn't have been the same without her.

Le Talks (With Timestamps)

For your viewing pleasure, here is a breakdown of the two day conference. Watch all the talks and follow the speakers!
️

Day One

Day Two

Write your way to health

Anthony M. — Thu, 10 Oct 2019 15:20:15 +0000

Growing up my environment taught me that strong men don’t cry. I was taught that counselling is for the weak. Talking about our problems leads to judgement and isolation.

It turns out not talking about my problems lead me to isolation. I cried a lot when I was in high school. I hated myself and was looking for an escape. After a few failed attempts, I started to look for help. I turned to books, podcasts, and meditation. I’ve been adding tools to my toolbox for the past ten years and now I’ve decided to build my own.

Whether you are struggling with mental illness or not, building a healthy relationship with yourself is extremely important. Self-reflection and journalling have been shown to have many benefits ranging from mindfulness to sparking creativity. I’m building a product that helps you build a daily writing habit, one small step at a time.

With Wrabit, you can proudly express your unedited self. Writing helped me when I wasn’t ready to talk and it might help you too. Although Wrabit isn’t free, portions of the membership fees get donated to mental health research. The more you write, the more we donate.

Write your way to health with Wrabit 👇🏻

https://writewithwrabit.com

What to do — and how to find success — after a coding bootcamp

Anthony M. — Sun, 27 May 2018 01:13:30 +0000

This article was originally posted on Medium.

It’s almost been two years since I graduated from the Lighthouse Labs Web Development Bootcamp. If you’re reading this, you probably already know that a coding bootcamp is an intensive program that teaches folks a little bit about software development. I say a little bit, because bootcamps are usually short, but they really do enable you to grow into a new career if you put in the work.

Plenty of people have discussed the pros and cons of attending a bootcamp (For example, on Quora, Reddit, and Medium). Should you go? Is it better than a computer science degree? Maybe, maybe not. I’m not here to talk about that.

I want to talk about what to do after a bootcamp. How will you succeed?

For me, I didn’t want to leave success to chance. I quit my job and with a small amount of savings, and I was finally ready to become a real software developer.

My journey was hard, but I like to think that I’ve been successful coming out the other side. The success came from the work I put in during and after the bootcamp. Success can be yours as well — all you have to do is put in the work.

Here are the things I did to get to where I am today.

Start applying to jobs early

I started applying to jobs somewhere around three weeks before graduation. During my bootcamp, I started to get an intense fear that I wouldn’t find a job after bootcamp. This fear helped me decide not to leave it to chance. I started spreading my résumé like wildfire. 🔥

Leading up to graduation, I had already applied to 50 different positions. Did they all respond to me? No. Did I get interviews with most of them? No! The majority of them didn’t even respond to me, but guess what? I got a job before I graduated.

Applying for jobs is a full time job. This step is essential. You need to cast your line and get your name in front of as many people as you can. You’ll see this theme carry throughout the rest of this article.

My favourite place to apply for jobs has always been AngelList. I like the user experience of their website. It’s clean, simple, and there are a ton of companies using it. Plus, who doesn’t like Naval Ravikant? Other than that, LinkedIn, Hired, TripleByte, or even Craigslist could help.

Go to meetups

I’m going to preface this part by saying that I’ve got an INTJ personality. Being in large crowds of unknown people makes me feel like I’m being pulled to the bottom of the ocean. Small talk with strangers is one of the most difficult things for me to do. But pushing through this struggle allowed me to realize the true potential for meetups.

If you haven’t been on Meetup.com, you should take a peek. If you have access to a relatively large city, I am willing to bet that there are endless possibilities for meeting folks on that website.

Remember when I told you to get your name in front of as many people as you can? This will help. People remember faces, good conversations, and fun events. Quite often there will even be job boards where you can share your email!

Pick a couple of meetup groups that you find interesting and are related to tech or software development. Put yourself in these social environments once a week. You will find plenty of people to exchange numbers with. Add them to your LinkedIn. Reach out to them later.

Bring your best elevator pitch!

Volunteer

Volunteering is something that I will always find valuable. We don’t have much time on this planet, so why not give back a little of what you’ve been given? So many people helped me during my journey through bootcamp. I decided I wanted to give this back to others.

There are tons of volunteer opportunities that you could find. The most valuable ones are probably related to the tech meetups you find. They will enable you to meet a lot of people while helping out the community.

Eventually, once you feel comfortable, I’d suggest finding some opportunities for mentorship! Help people learn to code. You never know whom you might end up helping through the process.

No matter where you volunteer, it’s a good opportunity for making others aware of who you are. Another bonus: it looks nice on your résumé.

Practice, practice, practice

There is only one way to get better: practice.

There are a very large number of options when it comes to practicing your hard skills. Practicing solving problems with algorithms is a great way to flex your mental muscles. You might even need to end up solving some of the same problems in the real world.

This type of practice gives you two important ways to learn.

The first one is clear: you really have to learn by doing. You’re never going to get good at math just by reading about it, and coding is the same.
The second is more subtle, but is easily just as important. Read other developer’s solutions. They will likely be better than yours in the beginning. That’s a good thing!

Solve, decode, iterate.

Build

One of the challenging things about bootcamp is, all of your classmates will have the same projects as you. You’ll want something to showcase to help distinguish yourself to potential employers.

Do you have a problem that you’d like solved? What about your friends? Your mom? Ask them. Then build it.

It doesn’t matter what you build. Just build something! Your passion projects will be a great conversation starter at all of the meetups you go to.

Contribute to open source

This is probably one of the most intimidating suggestions. Are you good enough to contribute? Will people even want your help? Yes and Yes! No doubt about it.

Open source projects need all of the help they can get. You may not be able to program their next big feature, but there are plenty of ways to get involved. Do you like doing design? Do you have a passion for documentation? What about writing tests?

Most of these projects are passion projects. The developers have full time jobs. Go take a look at some issues on your favourite projects and see if there is anything that excites you.

Once you start submitting pull requests to open source projects, you will begin collecting some invaluable feedback. It’s like having access to an infinite list of senior developers. How great is that?

Much like what I talked about in the section on practice, contributing to open source really gets you surrounded by code written by other folks. This helps open your eyes to a new perspective and new ways to solve problems. Read as much code as you can and try to think about how you would have done it differently.

If this sounds exciting to you, then you have to read GitHub’s guide to contributing to open source. It’s extremely in-depth and covers everything you need to know. Including giving you lots of ways to find projects looking for help.

Expand your knowledge

We live in a beautiful time. The internet is full of resources for learning. If you have an idea of what you want to learn, chances are you can find it online for cheap or even free.

It wouldn’t be hard for me to endlessly list online resources here, but I’ll leave the searching up to you. I was personally very curious about computer science so I started to self-study.

What you decide to learn about doesn’t really matter. Just continue to learn. Showing potential employers that you are a self-starter and capable of picking up things on your own is a huge asset. As a junior you become an investment. You need to sell to them and let them know you’re a valuable investment.

Never be afraid to ask

Hopefully your bootcamp is similar to Lighthouse. We have access to a Slack channel that has a thriving community. Even if your bootcamp doesn’t, you can find online communities to be a part of. These communities provide an excellent alternative for you to fill your knowledge gaps and get feedback.

No one is dumb who is curious. The people who don’t ask questions remain clueless throughout their lives - Neil deGrasse Tyson

Ask people your questions directly. Share some of your code. Read what other people are struggling with. All of these options are opportunities to learn.

Accept recruiter communications

I have one final suggestion for your post-bootcamp journey. Let recruiters on LinkedIn know you are open to communications. It never hurts to be on their radar, and they might just be able to find you a good fit.

Wrapping up

That’s it! Those are a few things to increase your chances of success.

As you can see, there are a few common themes spread throughout these ideas. You need to get your name out there, continue learning, distinguish yourself from others, and give back where you can.

Like most things in life, you’ll get out what you put in. Put in the work, believe in yourself, and have fun doing it.

If you have any questions, need some support, or would just like to chat, please don’t hesitate to reach out to me on Twitter or LinkedIn!

Best of luck!