Tom is no longer in your extended network

It's been almost 10 years since we saw massive changes underway at MySpace. If you don't remember what MySpace was, it was the popular social network before Facebook was king (though technically it still exists).

Tom's MySpace Profile

This was when everyone started with a new friend named Tom who was the co-founder of MySpace. Everyone could set their own "top 8" that could make or break the best friendships if you snubbed someone.

You could also set a song for your profile which would be added as a little player, back when it was “okay” to automatically play a song when your page loaded.

But MySpace is now a thing of the past, so why am I talking about it?

Making MySpace, your space

MySpace had a unique characteristic about it that you don't see in any of the popular social networks these days – it allowed you to add HTML and CSS into the page so that you could really do whatever you wanted with the your profile.

Example of custom code in a MySpace profile from dummies.com

Though from a simplistic perspective, this gives you some limited options. Maybe you can add some CSS that updates how the headers look and change a background color.

But realistically, this opened the door to adding full webpages that you could overlay on top of your profile by positioning your new layout above the original content with some z-indexing.

Custom MySpace profile for the band Filmore

The trick was, you had a limited amount of characters that you could put in each input. That had limitations, but these limitations helped promote creativity whether it was figuring out how to strip all of the whitespace in the code or by figuring out a way to add something with less overall code.

Learning through hobbies

Building MySpace profiles was addicting! It was a social medium that you could customize to make your own and stamp your name on it to show everyone what you did.

While you could do the same with your own website, it wasn't as easy at the time. And building out a profile on MySpace was easy, free, and you could connect with all of your friends.

One of my portfolio custom profiles

Each time I made a new page, I tried to think about what else I could do. I was even involved with small communities where we would share our work and help each other figure out how to hack things into a profile page (shoutout DM!).

This whole time, as I was trying to learn what more I could customize, I was learning how to code! I learned about how I could squeeze every inch of HTML I could out of a document and I also developed an understanding of how CSS selectors worked. I also learned how positioning allowed me to do cool things on the page and how to center things back when we didn’t have the option to flexbox all the things.

Flexbox all the things!

And this led to “business Colby” developing a sense of entrepreneurship. At this point, I was still in high school, but I was able to spin off a little business from building these pages.

While a modest $50 per profile seems low, that's a lot for a highschooler in 2004, not to mention that was a lot of money for another highschooler to pay to get one created!

STK Counter-Strike 1.6 team website

But this was the start of my code journey. Building off of MySpace, I started creating actual websites for Counter-Strike teams (CAL anyone?) and bands which would ultimately lead me to make a career out of coding.

Turning hobbies into jobs

I've heard others with a similar story, even others who similarly started with MySpace that eventually turned their interest into a coding career. While the MySpace era is something we all look back and laugh at, it really inspired a lot of people to find what they love to do.

Finding this kind of inspiration can be important to discovering how you want to spend your time. Whether it's a hobby or learning on the side to turn it into a career, keeping engaged with something you're actually interested in is important to learning a new craft.

But it's important to pay attention to how you engage with that new interest. You don't want to force it into a career and quickly burn yourself out. That will lead to regret and resentment.

While I got lucky that my interest in coding ended up turning into my career, I make sure to not "take my work home" as it's important to separate the work from your personal interests like random OSS projects on the side.

Find what motivates you

The important thing is to find something that can motivate and inspire you to develop your passion whether for a career or hobby. Each of us have our own journey, whether code related or not, and we should try to find something that will make us happy.

What was your inspiration for your interests? Share with me on Twitter!

Why is writing important in the first place?

Everyone will develop their own reasons for why writing is important to them, but there are aspects of writing that can help us all.

Writing is a way to teach both others and yourself. While it may be obvious that writing out a tech guide is helping to teach an audience, you're also reinforcing your own learning. Documenting your experiences both provides a way to dig deep into what you've learned and also gives you a way to reference it in the future.

While writing comes easier to some than others, it doesn't have to be scary! There's always someone that can learn from your perspective whether you're new or experienced on a topic.

And the best part about writing is you can do it for yourself. If you want to write to help yourself grow, you can do so privately and never share it with the public! But when making that decision, weigh the benefits, as there is some merit to learning in public.

So now that you're convinced, what can you do to make your writing more effective?

Keep your content organized with headlines

Getting someone to read your content is already hard enough, but when you have a sea of text, it just makes digging in more intimidating.

Naturally when reading, having breaking points helps let your brain keep thoughts organized and understand the hierarchy of the page. By using headlines, we can effectively break our thoughts into chunks of content that can help others more easily follow along.

React's use of headings on their documentation website

An easy way to approach this is to think about the outline of your page before you dig in. When writing this article, I thought about what I wanted to talk about and in what order I thought it made the most sense.

While maybe some people might have understood the article regardless of the organization, it makes more sense to explain why it's important before going into how we can be more effective. Having that flow also helps me better express my thoughts as I'm writing the content.

This also helps from an SEO perspective. When you use HTML headers (which is common in most content management systems), you're signaling to Google and the other search giants what your page is about and what's most important.

By effectively using headlines, you're helping not only your readers, but you're helping to send the right signals to the robots indexing your page for search.

Visualizing your thoughts with images

Similar to headers, seeing a wall of text with no visual breakpoints can be hard to consume. Another way we can break up this content and provide more value is to add pictures to go along with our thoughts.

Pictures can be useful for a variety of reasons. For complex concepts, having a diagram can help illustrate thick data that can be hard to understand. Throwing a bunch of numbers in a sentence is easier to create, but providing a graph or chart can help someone actually understand what those numbers mean.

New York Times data visualization of running shoes

Adding examples of a new idea can help contextualize your thoughts. This can serve as a way to demonstrate a use case or to inspire someone with successful implementations.

But sometimes images are a good way to break the tension. Later we'll talk about finding your voice, but this is a way to help shape it. While maybe a funny gif isn't appropriate in a science paper, it can be a good way to get a chuckle in the middle of a technical walkthrough, particularly after getting through a dry, challenging part!

Spongebob bored

Link to other sources for more context and trust

When writing, the last thing most of us probably think about is adding links to other pages. But this can be a valuable tool at your disposal!

From your reader's perspective, linking to other pages is a way to show authority with your writing. Are you making a claim based on facts? Link to those facts! By backing up your claim, you're building trust with your readers that you're doing the research.

Link and chart to show language popularity trends

But you're also helping yourself. If you've been writing for a while, you already have a stock of great content you want to share. Why not link to some of your past work with some internal links?

The first sentence in this article when I was explaining why writing is important was a link to one of my previous articles: Overcoming Your Fear of Writing and How You Can Find Motivation. Rather than rewriting all of the same content, I can highlight a key point and provide a link for the reader to follow if they're interested. I'm both helping give the reader more value and sharing more of my content at the same time.

Providing links to other sources via external links is also helpful. In addition to backing up your claims with your readers, you're also helping build that trust with search engines who can see that you're linking to trusted resources.

And there's also a chance someone from that other website can see you sending over links. If you're sending them traffic and they see value in your work, they might return the favor and send people your way.

Similar to headers, providing both internal and external links are another tool we have to build trust with both our readers and search engines.

Finding your voice

Everyone tends to have their own unique voice when talking to others. And I'm not talking about the sound of your voice, but your style. It's the words you use, how you phrase them, and your experiences that go into those words.

You might even have a few different voices. Sometimes we need to be a little more professional in a school or work setting whereas we can be more relaxed with friends and family. But similar to when you talk to people, everyone has their own voice when writing.

This is something that will develop over time. Some people are lucky and find it early, but the more you write, the more you will develop your own unique style that people will grow to love.

ThinkGeek's historically unique writing voice

And it's something that you don't need to and shouldn't fake. While changing the voice of your writing can be important if you're writing on behalf of someone else, when you're writing from your own point of view, try to be yourself and open up your mind through your writing.

For me it comes from the passion of my work. I love being a developer so my voice naturally comes as I write articles to help others with their own journey. Try to remember why you're writing and it will help you craft your voice with that passion.

A few other thoughts

Here are a few more points that are worth mentioning.

Code snippets

Similar to images, code can be an effective way of demonstrating your point. It also proves as a way to share the code as you're walking through how to create something.

While helpful, be careful not to abuse code snippets. You don't want long blocks of code that extend beyond the page or really even half of the page for that matter. If the code is going to be long, try using something like a gist, git repo, CodeSandbox, or Codepen.

Image quality

Nobody likes looking at poor quality images. When adding a new image, make sure the resolution is high enough that it's clear and not looking fuzzy.

You also don't want to go too far overboard with high resolution imagery, as the bigger the image is, the larger the file size. Try to avoid huge images so your readers don't have to download those big files.

Writing tools

Try to get comfortable with your writing tools. There are a ton of options whether you use something like Bear to write with markdown or if you prefer to write directly in the CMS.

There's also a lot of tools that can help improve the quality of your writing. Hemingway will actually analyze the readability of your writing and help point out where you could improve it.

Effective storytelling

These are just some tools that can help you tell your stories. While we're all writing for our own purposes, you can use these tools to ultimately help boost the great content that you're working hard to create!

What are your tips for good writing?

Share with me on Twitter and start the conversation!

What being a Senior Developer is not

Before we start, let's get this out of the way. Contradictory to what you'll see on 95%+ of the job postings online, a Senior Developer is not strictly correlated to only the number of years on your resume.

It's true, more often than not, that many years on the job typically bring with them a lot of experience. And with some companies you can get by with just that. But it's not the only quality that rightfully proves that someone is at a Senior level.

This is a common problem in the software world and can lead to high expectations with low delivery. It can also lead to conflict within the team when your new 15 year 10x Senior Developer refuses to work with others.

So what can we do to prepare ourselves for that role?

What makes a Senior Developer?

Looking back through my career at the developers on my team that I've admired and respected the most, it's really come down to four qualities:

• Experience
• Leadership
• Mentorship
• Technical Ability

It's not good enough to look at any one of these as the sole representation of how someone will perform on a team. Each developer is unique and may be stronger with one quality than another. But it's important to see how those qualities come together to determine how someone will help your team grow.

Let's break these each down a little bit.

Experience

Experience is typically thought of as years on the job, and while it's not completely inaccurate, it doesn't tell the whole story.

Just as every developer is unique, so is their experience. While one developer might have spent five years in an intensive position where they worked to solve hard technical challenges every day. And another might have been kicking their feet up at a local shop where their only responsibility was to update the website every week.

And that's not necessarily a bad thing! We each have our own journey and need to balance our lives to fit it. But it's not realistic to say those 5 years were the same.

Then what does experience really mean?

Recognizing patterns from previous work

Every developer has a story (whether they remember it or not) of a random error they stumbled into through their development experience. This could be something dealing with Javascript, webpack, or even your operating system, and it just doesn't make any sense!

But whether through a peer or by searching on Google, you figure it out. And three months later when you're working on another project and run into the same thing, you don't even have to Google it, or you already know what to Google. You already know what the issue is and can get past it quickly and move on.

This is the kind of experience that makes a difference. Being able to recognize patterns whether because of an error or because it was super successful is what helps each of us grow. These are the experiences that help a team grow when others are stuck and you can get them out of a bind.

Recognizing what you don't know

It's also important to understand what you don't know. I think part of what contributes to my own personal struggle with imposter syndrome is that the more I learn the more I realize I don't know.

But this shouldn't be looked upon as a bad or scary thing. This should be inspirational. That means that your craft that you've been working on has that much more cool stuff to explore!

It's important to realize how this impacts your work and the rest of the team. For example, it doesn't help anybody if you act like you know everything and commit to huge amounts of work. When you commit to that work and actually don't understand it, it could knock your sprint off track which can frustrate the entire team (and the client).

Whether it's when you're planning or during development, don't be afraid to ask for help. Come up for air and throw your hands up! Just because you're the only Senior Developer, doesn't mean you can't learn something from a Junior team member.

Try to take a good look at where you've been, what you understand, and where you could benefit to dig in more.

Leadership

As a senior member of a team, I would expect a developer to have a natural tendency to lead. While this doesn't mean you have to be an actual Tech Lead on a project or make any of the final decisions, this does mean that you should have a basic level of being able to help push the project forward

Understanding the bigger picture

If you've worked on projects with team members, you should know that each project or feature typically comes with a bunch of stories to work through to get it done. Each story should be a focused piece that helps accomplish a larger goal.

Where this becomes challenging is if no one on the team understands how each of these stories help to accomplish that bigger goal. As a Senior Developer, you should be able to see how each piece fits into the puzzle and why the story is written with the specific acceptance criteria. And if you don't know, you'll know how to get the answers and make sure it's communicated to the team.

If you're unsure of the direction, try to take a step back. Try to see where it fits in. Help to lead the project team to that ultimate goal.

Helping direct less experienced team members

This comes naturally in the ability to help guide those on our team who are more junior or less experienced. It's common for developers to lose focus on the big picture. But as we just discussed, a Senior Developer should be able to continuously have a good idea of the overall project and where the different stories fit into the bigger epic.

Help guide others on your team to get them on the right path. While it would be beneficial for everyone to understand how everything fits in to the bigger picture, sometimes it makes more sense to help an individual focus on how their specific task fits in.

Try to recognize this struggle when working with others whether by encouraging them to ask more questions or helping to guide them if they're not quite on the right path as you're reviewing their code.

Mentorship

It's often more convenient to be heads down on your work and not have to worry about what anybody else is doing, but is that really benefiting anyone?

Helping to build up other team members

You might be the so-called 10x developer, but doing everything yourself and not helping others can only slow down the overall team. Often you'll be stuck picking up the pieces that you could have easily caught if you spent an extra second pairing up with someone else on your team.

It's also bad for morale. No one wants to feel alone on a project and even more so as a junior. Software is a big scary world, a little guidance can go a long way to helping others to become more productive and subsequently encouraging a happier, less stressful environment.

It's easy to forget that we were all a junior team member at one time. While you might take things for granted, the concepts might be really challenging for others to grasp.

Keep in mind that we're all in this together. Celebrate the wins whether big or small. If somebody's struggling, reach out to help.

Knowledge sharing

Sharing knowledge is something many teams struggle with. While we're all usually hopeful that there's a way to accomplish it, most of the time it just goes unsolved. So what can we do?

Take it upon yourself to share what you know. Did you just rework the core business logic? Offer 30 minutes to walk everyone through the code. Pair up and screen share with your code reviewer if they're having a hard time understanding it.

This is something we can encourage everyone to do. You'll naturally learn more by presenting your work by reinforcing what you just worked on. This is helpful whether you're a Senior or it's your first time opening up a code editor.

Technical Ability

I intentionally wanted to leave this until the end. This is because, while it's important, there are more aspects to your journey to becoming a Senior Developer than just being really, really good at something.

Ability to get moving quickly

As a Senior Developer, I would expect another Senior Developer to become productive in something quicker than a Junior Developer. If they're an expert with Javascript, I would expect them to understand the core principles and patterns of the language.

But back to the idea of recognizing what you don't know, it's not reasonable to expect all Senior Developers to know everything. I wouldn't consider an expert in Ruby any less of a Senior Developer because they don't know Javascript, but I would expect them to understand how to apply what they know when building in and learning another language.

Promoting software patterns

More often than not, the code pattern you just came up with isn't new. And that's okay! The goal of building great software isn't necessarily to be unique with every solution.

And because of that, we can learn from past work by seeing what's succeeded and what's maybe not gone over so well to find patterns that work for you and your team.

Patterns like MVC (Model View Controller) didn't become popular without reason. Developers learned from the past and have learned from their peers who have solved big software challenges. With that knowledge, they can apply the solutions to their own work. It's not about reinventing the wheel, it's about solving challenges and making a good product.

We all have our own unique journeys ahead

No matter what anyone tells you, we all have our own unique code journeys. This is meant to encourage you and inspire you to become a better overall developer and understand how your work impacts the rest of the team.

While you certainly might succeed without taking these things into consideration, you could be missing out on core traits that could make people not want to work with you from a human being perspective.

Whatever your journey, keep these things in mind as you grow into becoming a better developer!

What do you think makes a good Senior Developer?

Do you think I'm spot on or way off? Share with me on Twitter!

In this article we'll explore what kinds of things you can do to make it a little easier on your future self.

Revisiting "prior art"

We've all been there. Six months into a project, you're trying to squash a bug, and what you find is shocking. You might be asking yourself, "who would write this kind of code?"

So you dig through your git commit history using git log -p filename.js showing changes for a specific file, trying to see who would come up with something like that. And then your heart drops – you're the one who wrote it!

Tituss Burgess shocked

This is a common scenario for any developer, experienced or new. If you haven't hit that scenario, I promise if you stick with coding long enough, you will.

Becoming more conscious about our coding habits

That six month reflection point is inevitable. That's a lot of time which you've most likely been using to work on other parts of the project or another project completely. Chances are, you've leveled up which has changed the way you write code.

On the other hand, sometimes it takes stepping outside of the code to see the bigger picture and get a better look at how all the pieces fit together. We can naturally dig ourselves too deep into a solution and can become a little narrowly focused as we work to solve those challenges.

But either way, while part of the code journey will simply be gaining more experience and learning more about your craft, there are other small habits you can get used to early on that will help you down the road.

So let's jump in.

Improving the readability of your code

What is the challenge?

Part of the fun about our craft is there are a ton of ways you can do the same thing. Think an if statement is too many lines? Well we can write it ternary style!

// Example ternary statement
const isFreezing = temperature <= 32 ? true : false;

But sometimes this takes a toll on the readability of your code. While it might seem like it looks nice and super clean on one line, imagine that as that ternary gets more complex, someone will have to spend more time understanding what it means.

const minutes = 30;
const cookie = {
  color: 'black'
};

const cookieStatus = minutes > 20 ? cookie.color === 'black' ? 'burned' : 'done' : 'not done';

What can we do better?

Now I would imagine most of us can figure out what cookieStatus is in this example (spoilers: burned). But think about the time you spent figuring it out. Whether an extra 1s or 2s, it forces you to spend additional cognitive energy to read through the code.

On the other hand:

const minutes = 30;
const cookie = {
  color: 'black'
};
let cookieStatus;

if ( minutes <= 20 ) {
  cookieStatus = 'not done';
} else if ( cookie.color === 'black' ) {
  cookieStatus = 'burned';
} else {
  cookieStatus = 'done';
}

No, it may not be as clean or clever as the 1-line ternary statement, but the next time you visit it, the less you'll have to think about what the answer is.

It's also going to make it that much easier for bugs to creep up and get past your code reviewers when all of your code changes are in a 1-line git diff.

And yes, this is a simple example. But imagine this in a real world scenario with important business logic where you could run into these situations frequently.

Say you need to add another condition – that ternary is just going to keep getting more complex! You're just making it more difficult to debug or extend, where the if statements can continue on in an easily readable way.

For what it's worth, ternaries and other shortcuts can be simple and effective in code, but don't abuse that effectiveness and end up making things more difficult.

Keeping things consistent

What is the challenge?

We all have our favorite way to code. Though I'd argue not including a semicolon at the end of your JavaScript is just completely wrong, you might prefer to write your code the wrong way without them.

// Jim's code style

function MyComponent() {
  function handleOnClick() {
    alert('Click!')
  }
  return (
    <button onClick={handleOnClick}>My Button</button>
  )
}

// Creed's code style

const MyComponent = () => <button onClick={() => alert('Click!')}>My Button</button>;

But it's not always about what you prefer. When working with a team, chances are, everyone's opinion on how code should look is slightly different. You might agree about the semi-colon, but disagree about whitespace.

And no one is wrong (except for the non-semi-coloners)! There are valid arguments to most code styles, whether for or against, but the solution isn't for everyone to write their code their own way.

What can we do better?

Keeping code consistent is important to maintain code health. A typical goal is to "make the codebase look like one person wrote it."

The point isn't that one person gets their way, it's that the team came to a conclusion about a set of rules they would use that everyone would follow. Having this consistency provides less cognitive overhead as people work through the code. It gives everyone the ability to know what to expect when reading the code.

Errors from linting code

And achieving this doesn't need to be hard. There are tools that can simply check for these inconsistencies like Eslint for Javascript. And even better, there is another level of tools like Prettier that will fix it for you!

Commenting your code

What is the challenge?

Keeping up with commenting your code is an important way to put context to complex logic. As much as we all want our code to be self-documenting, that's rarely the case.

Too often we find ourselves dealing with a block of code that just doesn't make sense. And even if it makes sense on its own, we might not be able to figure out how it fits in to the rest of the application.

What can we do better?

By providing a good set of comments, you're setting up the next person who touches that code to have a better understanding of what the code is doing before they make a change.

// DONT CHANGE - WILL STOP MAKING MONEY

const shouldMakeMoney = true;

function makeMoney() {
  if ( shouldMakeMoney ) {
    return noMoney;
  }
  return moreMoney;
}

While this is a silly example, it brings up a real world case. Businesses are increasingly dependent on being able to maintain a reliable website to make money. Whether this is as an ecommerce business or an ad giant, these websites rely on business logic that determine things like cost, taxes, discounts, and other math related things we tend to not want to think about, but could make or break a business on the internet.

But it's not all about the company you work for. Touching old code can be scary. It's even scarier when no one on your team was around when it was written, so no one knows what it does!

Patton Oswalt hands over mouth

While you might not be the next person who touches that code, try to help out your future friend who's tackling the next ticket involving that code. Because there's also a good chance you will be that person and you'll wish you remembered how it worked.

Documenting your solutions

What is the challenge?

Documentation is similar to commenting your code, but from a different perspective. Documentation and commenting are both about finding ways to describe a solution in a human-readable way that will ultimately give more context. But documentation is more about the overall solution rather than the implementation details.

Having a high performing application is everyone's goal. But how did we get there? There's a realistic chance that someone will have to be working on the same project you are like onboarding a new team member. How will they be able to maintain that high performance if they don't know how it works?

What can we do better?

Whether it's introducing that new team member to the project or trying to share knowledge with another project team, documentation is an important part of maintaining a project. It helps keep everyone on the same page so we all confidently know what we're working towards.

For example, if we're still working with our ecommerce project with our business logic, there will be rules that the code needs to implement. While commenting might give details inline about how the rules were implemented, the documentation would define those rules.

/**
 * DOCUMENTATION
 * Order Total >= 25: Discount %10
 * Order Total >= 50: Discount %15
 * Order Total >= 100: Discount %20
 * Order Total >= 75: Free Shipping
 */

const orderSubTotal = 84.00;
let orderTotal = orderSubTotal;

// If the order total is under 75, apply shipping discount

if ( orderTotal < 75 ) {
  orderTotal = addShipping(orderTotal);
}

// If the order total reaches a threshold, apply given discount

if ( orderTotal >= 100) {
  orderTotal = applyDiscount(orderTotal, .2);
} else if ( orderTotal >= 50 ) {
  orderTotal = applyDiscount(orderTotal, .15);
} else if ( orderTotal >= 25 ) {
  orderTotal = applyDiscount(orderTotal, .1);
}

This is a minimal example, but we can see the difference between the rules at the top and how we apply them. The documentation should clearly explain what the rules are, but it shouldn't care about how those rules were implemented.

On the other hand, the comments might not care about what the rules are, but need to implement them in an efficient and logical way. We should be able to update the code with the business rules, such as changing the top level discount tier from $100 to $80, without having to rework the code.

But documentation is much more than business rules – it's providing a way for anyone to understand your work from a higher level. This could include anything from architectural diagrams to the theory behind your core algorithm.

While maybe code isn't the best place for details like this to live, it's really important information that can help instill confidence in your project and give others an opportunity to understand more about the work.

Creating effective Pull Requests

What is the challenge?

Pull requests (or merge requests) are a core part of any development team's project lifecycle. It provides a way to package and present your code in a consumable way for your peers to review and understand your work.

There's a lot that can go into a pull request from a single commit to the entirety of the next version of your website. That's a lot of context to expect someone to understand by reading through the commits alone.

What can we do better?

Pull requests don't need to be an art. There should be one primary goal of the preparation you put into it – providing context into your changes. At a minimum, it should answer the questions of "what" and "why".

We can even use tools like pull request templates to push us in the right direction. Define an outline of what you want explained and chances are, people will follow that outline. This helps avoid the 1-line "closes [ticket]" description or even worse, an empty description.

With my projects, I hope to have a few questions answered before I dive into a code review:

• What is the change?
• What does it impact?
• How do I reproduce or test the change?

Just a few details around the change set can provide much needed context for those reviewing your code. It's easy to look at code, but it's harder to understand it without knowing how it fits into the bigger picture.

Hardening your code with tests

What is the challenge?

Tests are a way to ensure your code runs the same way each time. Being able to prove that the same input will always have the same output will help provide you and your team with a higher level of confidence that your application won't come crashing down with the next small change.

Without them, we're left with human error, where no matter how good your QA Engineer is (shoutout to my testers out there), something will always slip through. And that's not to say your tests will always catch every problem, but we can use the tools available to help prevent it.

What can we do better?

Where comments are a way of providing the context of how something works, test are a way to ensure they work. Providing test cases that are repeatable helps enforce that.

function applyDiscount(value, discount) {
  const discountAmount = value * discount;
  return value - discountAmount;
}

expect(applyDiscount(10, .1)).toEqual(.9);
expect(applyDiscount(532151235, .1054)).toEqual(476062494.831);

If I fudge the math on our applyDiscount function above, there's a high probability that the test would fail (never say never).

But testing doesn't need to be hard. There are many tools out there that help from different perspectives. For example, you might use Jest to run your unit tests or add Enzyme on top to test your React components. But you can also bring in Cypress as an integration test solution that will work like a robot clicking through your application to make sure all the components actually work together.

There's also different methodologies of testing. While you probably see most teams write their tests after they have a working solution, some people swear by test-driven development. They might write their tests first where the code has to pass the tests rather than the other way around. This is a great way to define the requirements of the code before diving right in.

Whatever the method, capture the points that are most likely to break or the functions that add the most business value. You'll be helping to prevent a potential business loss or even simpler, a headache.

What can we learn from this?

That might be a lot to digest, but they're important points to consider as you grow as a developer. Starting these habits early in your career will help you naturally build these skills and work that way by default.

And if you're late in your career, it's never too late to start. We should all want to strive to be the best developer we can be and do our best to help make our teammate's lives easier, as we're all in this together.

Looking for more to learn?

• Put Down the Javascript - Learn HTML & CSS
• How to Become a Full Stack Web Developer in 2020
• What is the JAMstack and how do I get started?
• What is linting and how can it save you time?
• Why you should write merge requests like you’re posting to Instagram

What’s your advice for growing as a developer?

Share with me on Twitter!

Two years ago, I switched from medicine and redesigned Instagram.

Three months after, I packed what I could fit into my carry-on and two moving boxes, and flew to Saigon to become Christina’s second product designer. Fast forward to today and I am now their Head of Product.

I can still remember my first task on the job: creating color swatches for our tour guide’s awesome new helmets. It might sound like a simple feat, but after trying out hundreds of color combinations and learning a thing or two about color theory, I was pretty proud of the results.

As Christina’s grew from 100 to well over 450+ team members spanning all across Vietnam, so did my responsibilities. From tour guide helmets to redesigning the company’s flagship communication app to then launching it for Airbnb hosts all over the world to use, its been a crazy (but fun) ride.

As I look forward to my next journey back to the States, I wanted to reflect on my experiences by sharing what I’ve learned along the way as someone who started with zero knowledge about product design and technology.

Let’s be clear — I still feel like I know nothing. I just know a little bit less of nothing than the day before.

Trust your gut when it comes to recruitment.

If you, your team, and your culture are playing to the same tune — you will know whether the candidate is a good fit (or not). As a rule of thumb, my go-to question after assessing a candidate’s technical skill is:

“How did this person make me feel?”

My goal for going into any interview is to gain a better understanding of who the candidate is beyond what is on their resume and what their motivations are for arriving in this room with me. If I left the interview feeling more confused and conflicted than I did going in, it’s probably a good sign that this candidate is not the one. If I left the room feeling energized and excited, s/he is most likely a keeper.

Hire someone you would be excited to work with and most importantly, trust your gut instinct.

Be consistent in expressing your values.

From creating wireframes to leading a team of developers, I knew it was important to establish our design and engineering principles early. It helps guide us in making product decisions, examining trade-offs during development, and uniting us stronger as a team.

Our team’s north star ?

An example of when we put our principles to the test was when my CTO had fixed a bug only to have it spam our users with hundreds of push notifications within a span of minutes.

I suggested to my CTO that he should write a post to be considerate of our users, take accountability, and explain what had happened so that our users can empathize with us through our immediate transparency. It will also be the kind of leadership that our junior engineers can learn from. And he did.

Instead of receiving any backlash, his post was received with likes and heart-eye emojis. Not only did our principles became a model for how we communicated as a team and developed our products, but it also forged the path for building a trusting relationship with our users.

It goes without saying that leaders lead best through their actions, and not only by what they have to say.

Now whenever there’s a bug (not saying it happens often), our users are much more forgiving and understanding of it. Not only that, but the other engineers on our team started to follow his example and took accountability for their own missteps as well.

Don’t underestimate the power of 1:1 meetings, because they are so, so important.

Whether you’re a designer or the CEO of a company, 1:1 meetings will always be the bread and butter for building a personal connection with your team. My engineers and I have weekly 1:1 meetings to QA the state of our product and pending features. To my engineers, it might be just a routine product QA. To me, it’s a perfect window of opportunity for me to get to know them on a personal level, address concerns they might have, and provide insights to help them find more value in their work.

If you’re looking for mentorship or growth in your career, I suggest scheduling 1:1 meetings with your team leader. First, it shows initiative. Second, you might also be surprised by the feedback and support you get in return. Before reaching out, make sure you understand what your goal is for the meeting. Is it to understand how you’re doing in your role? Is it to ask for additional remote days? After figuring out what your objective is, make sure to communicate it. This will help give your team leader ample time to prepare and keep the meeting focused.

Creating a process is great, but staying flexible is even better.

Create processes, but plan for disruption. This can mean one of two things. One, the process you created didn’t work out as intended. Two, the process you created worked, but it ended up being discarded somewhere along the ever-evolving development process. This is especially true for startups during their hyper-growth stage when you have many cross-functional teams working together to build and ship a product. When this happens, you have to be able to quickly switch gears, and adopt new mental models, while pushing the overall product vision forward.

So instead of looking for an evergreen process, make your process of implementing and iterating evergreen.

Figma is king.

This article is not sponsored by Figma, but I figured this would be a great chance for me to give this amazing team (and product) a shoutout. Before Figma, our design team at Christina’s was getting around with using Sketch for design, Zeplin for hand-off, and Abstract for version control. It was a lot of tools but we had figured out a process that worked for us. Intrigued by Figma’s approach to design and collaboration, I decided to test out the tool to see for myself.

With Figma, design to developer handoff became almost instantaneous. In addition to the speed and efficiency, we also saved a lot of money in not having to use multiple software to maintain our design system, version control, and hand-offs. Since then, our entire product team has switched over to using Figma, and we haven’t looked back since.

Thanks Figma ✌?

“Work politics will always be a thing, but it doesn’t mean you have to be a part of it.”

My COO said this to me during one of our lunch conversations after I had told him my reason for not wanting to accept the promotion to Head of Product.

With my previous role as a product designer/owner, I was able to influence business decisions, resolve problems, and focus on building products from behind the shadows, politics-free. However, when he said this to me, it made me realize that it’s not about the situation or the environment, but rather how I choose to react (or not react) to it.

More importantly, he made me realize that my new role will only put me in a better position to squash any office politics (with my killer resting face), reinforce our core values, and further protect the positive and empowering culture we have built together.

Start building your persona capital early.

A persona is in short — a representation of a target audience or a person. Research shows it takes about 3 seconds for people to form a perception of you upon the initial meeting. Sometimes even before you’ve even spoken a word. Now consider this in terms of all the micro-interactions you might have with your colleagues, clients, and business partners day-to-day. Add in impromptu slack messages, random hallway exchanges, desk drop-ins, meetings, and company events — now you have given every person you’ve interacted with countless seconds to form their opinion of you.

What kind of team member would you like to be? What kind of leader do you want to be perceived as? What do you want to be known for? Have these questions answered before you join any team or company — or someone else will answer them for you.

If you want to be perceived as a competent, reliable, and self-sufficient person — show it and own it every opportunity you get.

Once you build your persona capital, it’ll be one of your most valuable assets when communicating with stakeholders, influencing key decisions, and working with cross-functional teams.

Imposter syndrome never truly goes away, but it does get easier.

Several months after joining Christina’s, I had a heart-to-heart with my CTO. I told him how I felt like an imposter. I told him how I felt like everything I’ve achieved up to this point had all been attributed to luck. It also didn’t help that I’ve never had any formal design education. I’m afraid that I was going to be exposed as a fraud one day. I was upfront about my personal assessment, and honestly, it felt good to finally say it out loud.

What he said next shocked me:

he told me he felt the same.

I was in disbelief and all I could muster was… really? This made me realized that this so-called imposter syndrome is perfectly normal, and it can happen to anyone regardless of age, sex, and experience. If anything, it just means you’re a humble person with really high expectations of yourself.

It’s been a couple of years since that exchange, and since then, I’ve felt less and less like an imposter. If you’re feeling these insecurities, share it with someone you trust. It’ll help relieve some of the burden and guilt.

One reassuring thing I’ll add is this — it will only get easier with time as long as you show up, put in the work, and commit to continuously learn.

Remember, you’ve earned your spot at the table. The only person that you need to convince now is yourself.

“Your harshest critic is always going to be yourself. Don’t ignore that critic but don’t give it more attention than it deserves. 

— Michael Ian Black”