Forem: Will Taylor

5 Ways to Stand Out at your Dev Job

Will Taylor — Thu, 25 Jul 2019 11:35:24 +0000

I’ve recently been trying at work to get out of my comfort zone. That means doing my best to stand out in positive ways.
During this time, I’ve seen some great personal growth, and I know people at work have also taken note.

So if you’re looking for ways to stand out in your dev role, hopefully a few of my ideas can give you some inspiration!

Build Trust with Product Owners

Product owners are seen as a necessary evil by many devs. The reality is that having a strong relationship with your product owner can be extremely powerful.

Building trust can be tough, though. Here's a couple of things I've found especially effective.

Be willing and able to compromise. There will be times that a requirement comes down that for whatever reason you don't agree with. If you can talk to them to find a middle ground, they'll be much more willing to hear you out when you want to bring up your own ideas.

Communicate calmly. It can be frustrating when a conversation isn't going your way. Stay calm and explain your reasoning. That'll leave them feeling comfortable talking to you moving forward.

At the end of the day, you want to be the person your product owner loves to talk with.

Suggest New Ideas Beyond Your Title

This is a tricky one. I've always advocated that developers should not be confined in their engineering box. A great way to do this is to always look for suggestions or actions you can take that might be outside of your direct responsibilities.

For example, if you're a front end dev, try designing a quick mock-up in Sketch. Simply making a quick suggestion to the designer if your team has one can be just as effective as well. Little things add up and won’t go unnoticed.

Be sure to be respectful as hell when you do this, though. You don't want to step on other people's toes or inadvertently hurt a colleague’s feelings. If you do pull it off, however, you'll make a deep impression on people throughout the organization.

You'll show everyone that you are more than what your title says you are.

Share Your Knowledge

You know things. I promise that you do. You probably know things that people at your company don't know.

A great way to stand out is to share that knowledge. Say you’ve been working hard on setting up the linting for a project. Give a quick demo and teach people about configuring the linting rules themselves. If you're passionate about accessibility, share that with others at your company!

Not only is this a great way to stand out, but it's an awesome medium for personal growth. By talking or writing about a subject, you force yourself to engrain that topic in your brain. In addition, it can be a great confidence boost.

If you're already writing blog posts or sharing through another medium and your company doesn't know, tell them! It can be scary, but odds are they'll want nothing more than to encourage you!

So share your knowledge! Go help your company out all while making yourself more noticeable.

Always Ask Questions

Like I said, you know things. Other people know other things. Ask them about those things!

The benefits that come from asking questions cannot be understated. You'll work through problems more quickly. You'll show your co-workers that you're eager to learn. Most importantly, you'll actually learn new things.

Don't spend an hour bashing your head against a wall trying to debug something. If you've been at it for 5 or 10 minutes and feel stuck, throw the question into slack. Even better, if you know someone who might know a solution, go talk to them!

When you ask these questions, make sure to get some context behind the answers. A huge advantage of getting the answers from someone you know over going to Stack Overflow is the fact that you can dig deeper.

At the jobs I've worked, asking questions was always valued extremely highly. Just make sure you give whatever problem you're tackling an honest shot before asking!

Be Confident

This is the hardest one of all. Many of us struggle to some degree with imposter syndrome. That often makes us get in our own heads about standing out.

Amy Cuddy had wise words that fit well here. "Fake it till you become it". Doing everything I listed above is not easy, but it's something we're all capable of doing.

It only gets easier the more you do it. It's a positive feedback loop. Act confident, and you'll start to feel more confident. Start sharing your knowledge, and you'll become a better communicator.

You can do this. You got this. Go kill it!

Quick and Easy Text Highlight Animation

Will Taylor — Mon, 15 Jul 2019 12:26:46 +0000

Highlighting text on your site is a great way to bring attention to key features or important context. Sure, you could just have the text highlighted by default, but what if you could do it in a silky smooth and 😎crazy cool😎 way?

Getting an effect that looks just like this one is super simple, so let me show you!

Let's start off with the initial state where the text is underlined. While it may look like we use a border-bottom or a text-decoration, it's actually a handful of background properties.



span {
  background-image: linear-gradient(#ffd900, #ffd900);
  background-repeat: no-repeat;
  background-position: 0% 100%;
  background-size: 100% 2px;
}

The code above says that there is a background-image that is really just the solid color #ffd900. By using background-image, however, we can set background-repeat to no-repeat to have full control over the size and position of the background.

The code that gives us the line itself is background-size: 100% 2px, which says that the background should fill the whole width but only be 2px high. To position that line under the text, we use background-position: 0% 100%, which tells the background to position itself at the start of the text horizontally, but all the way at the end vertically.

Now, let's talk about the highlighted state! I'm going to have the highlighted state trigger on hover, but you could have it trigger any way you want. To get the text highlighted, we just need to make a couple of tweaks to the initial state:



span:hover {
  background-size: 100% 100%;
  background-position: 0% 0%;
}

Not so bad, right! We just use background-size to make the background cover 100% of the width and height of the container and background-position to move the start of the background to the top of the container.

Okay, awesome! We have the text initially underlined, then getting highlighted on hover. It's pretty off-putting, though, how it snaps between states. So let's animate this bad boy!

Doing so is really, really easy. Both background-position and background-size can be animated which is key for what we want to do. That means by just applying a transition to our initial and highlighted states, we can achieve our desired result! Here's what those transitions look like:



span {
  transition: background-size .5s, background-position .3s ease-in .5s;
}
span:hover {
  transition: background-position .5s, background-size .3s ease-in .5s;
}

The hover transition brings the underline up to the top first, and then increases the background-size to 100%. The transition back to the initial state is almost identical, but we shrink the background-size first, and then bring the underline back down. To make one happen after the other we just need to set the transition delay to the same length as the first transition. I do this using the short-hand transition property to set the transition-delay as well as a couple of other properties.

Combining these few lines of code results in that smooth animation I showed you earlier! It doesn't have to stop there though! You can animate these properties however much you want. You can trigger them however you want. You can use these for something other than text highlighting. This is something that really leaves room for creativity, and I urge you to try it out!

Thanks for reading! ✌️

View the source for this animation on CodePen

Be Lazier With Semantic HTML

Will Taylor — Thu, 20 Jun 2019 11:45:26 +0000

Cover photo by Drew Coffman on Unsplash

I know semantic HTML is old news, but here's me shouting from the rooftops that it's literally easier to use it than to not. Show this to haters should you come across them

You may have heard of the term "Div Soup" before. That's when a website is built mostly out of hundreds of divs, often deeply nested within one another. If you want a good example, look at Twitter's source.

What's wrong with div soup? Well, there are three main problems.

Web crawlers will have a worse time indexing and ranking your site
Your code base is harder to read through and understand
Harder to account for and implement accessibility

Now, I'm not trying to attack Twitter. They clearly don't have SEO problems, the site works well from an accessibility standpoint, and I'll just assume they have a well-maintained code base. That's a credit to everyone who worked hard on the redesign and got it out the door.

However, I'm here to advocate for a different approach to the hard work Twitter put in. That approach is... Laziness.

Semantic HTML

For those who aren't totally familiar with what I mean when I say "Semantic HTML", let me give a brief overview.

Semantic HTML elements released in HTML5 (and also some from 4) give meaning to the content on the page, agnostic to any style decisions. For example, the section element could technically be used everywhere you use a div. That's not the point of the section element, though. It serves as a way to group together thematically related content. The element itself has no impact on the way your site is visually displayed.

There are plenty of other elements, and I strongly encourage you to check out this article which gives you a bit of detail on each.

So how does this all relate to being lazy?

It's lazy because creating or updating a site to use semantic elements doesn't require you to migrate to a new library or framework. It doesn't require some highly specialized knowledge or a total refactoring of your CSS on top of it. It's lazy because it can take a lot of the burden away off the developer when trying to make your site accessible for people using screen readers.

It's lazy, and yet still comes with so many big advantages. Let's look at that list of pain points about div soup from earlier again.

SEO

When a web crawler comes through to decide how it should rank your site, it uses a host of different strategies to understand what's happening on the page. One of the most basic strategies is using HTML tag names.

For example, having your header, nav bar, and footer clearly marked with their corresponding HTML elements and your main site content under the main tag allows a crawler to quickly identify where it should look for the actual meat of your site. This is the same idea as using more well-known SEO tags like title and all of the meta variations.

SEO is kind of a black box. There's no concrete way to say, "Yes! Using HTML5 elements will shoot you up in the rankings!". It's well known, however, that web crawlers do use HTML tags to try and find out where to look. If you can make their lives easier, that has a good chance of helping your site out.

Harder to read code base

A maintainable code base is a really, really hard to thing to achieve. That's why tools like ESLint and Prettier are so important. Format your code all you want, but if everything and its dog is a div, you'll probably have a headache before you understand what you're looking at.

Take a look at this beauty.

<div class="header">
    <h1>Hello There</h1>
</div>
<div class="container">
    This is some of the more important content. This is a basic intro to it.
    <div>
        Now let's get into the content
        <div>
            <p>This is an example piece of content</p>
        </div>
        <div>
            <p>This is an example piece of content too</p>
        </div>
    </div>
</div>
<div>
    This is my footer.
    Here's some legal info.
</div>

This isn't very complicated to parse once you take a beat. At first glance, however, it can be really tough to understand. Almost everything is segmented off with a div, and our only other clues to what's going are the class names and the content itself.

So let's fix this in the laziest way possible. Let's just change the tag names on the elements to be semantic.

<header class="header">
    <h1>Hello There</h1>
    <h2>This is the header!</h2>
</header>
<main class="container">
    This is some of the more important content. This is a basic intro to it.
    <section>
        Now let's get into the content
        <article>
            <p>This is an example piece of content</p>
        </article>
        <article>
            <p>This is an example piece of content too</p>
        </article>
    </section>
</main>
<footer>
    This is my footer.
    <small>Here's some legal info.</small>
</footer>

With just a few minor changes, this page becomes just a little bit easier to read. No libraries, no weird out of place comments, just pure HTML. Another benefit is that the page looks exactly the same as it did before (except the small element, that one changes font-size 😬).

Keep in mind this might not matter for an example on this small of a scale, but as your site grows, so will the value gained from leveraging semantic elements. This holds true even when you have your site well broken up into smaller components.

Accessibility

Accessibility is something every developer needs to be aware of. A significant portion of users have disabilities and use some sort of assistive tech when browsing the web.

There's a lot to consider when it comes to making your site accessible, (too much to cover here). Luckily, you can get away with a little laziness just by using semantic HTML.

DISCLAIMER: I'm not saying this is all you need to do for accessibility. It just helps.

To illustrate one of the big wins from using semantic HTML, let's look at the code from earlier's accessibility tree. The accessibility tree is a representation of the DOM that screen readers use to read to its users.

Here's the tree for one part of the non-semantic HTML:

Okay, that makes enough sense. It's a paragraph with some text in it. Now, what about the accessibility tree that uses semantic elements? Here's that tree for the exact same portion as above:

No, that's not just an un-cropped version of the first picture.

There's actually a lot more there! There's more context about what is present on the screen and what exactly the user is reading.

Why the difference?

The accessibility tree will leave out most divs since their purpose is usually stylistic rather than semantic. Therefore, there's no reason a screen reader should care about them.

You can, and should, add aria-label's to both examples to help the screen reader out. Doing so will include the div in the accessibility tree along with the label. We're talking about laziest wins we can get here, though.

Update: Here's a handy quote from MDN's ARIA docs

Many of these widgets were later incorporated into HTML5, and
developers should prefer using the correct semantic HTML element
over using ARIA, if such an element exists.

Conclusion

Semantic HTML is not the holy elixir that will magically solve all your problems and cure all that ails you. Nor are div tags the devil. They have their use, and they should continue to be used in the proper way. Semantic HTML is, however, a super easy, almost-no-risk way to gain some easy wins for your site.

So whether you're starting up a new project or continuing to work on a monolithic legacy codebase, you can leverage semantic HTML with ease.

So please do. Seriously. It's been official for like 5 years guys.

"You're Not Smart Enough to Code"

Will Taylor — Mon, 10 Jun 2019 15:26:36 +0000

I vividly remember the fall of my junior year of high school. Everyone was working hard to get their GPA up while simultaneously trying to figure out what they were going to study in college. After all, what you study in college determines the rest of your career (Note: it does not).

I was lucky. I knew exactly what I wanted to study. Since I was a twelve-year-old I'd been toying around with code. I'd make websites, little very-bad games, and learn whatever the latest YouTube tutorials wanted to teach me. I was good to go.

Oh, except I wasn't very good at math. Actually, I sucked at math. My whole life up to that point I desperately needed a math tutor to have any chance of getting through a class. I knew math was important, but I never had a doubt that I couldn't code because of it.

That was until it was time to meet with my counselor.

The school had three counselors, each assigned a group of students. These counselors were meant to help guide you through the tumultuous time of picking your college and your future. It's a very useful tool for many, and I was excited to take advantage of it.

When my meeting finally rolled around, the conversation started off very light. We talked about how the year was going, my band (hell yeah I had a band), and joked about the ending of Lost. Then we got down to business.

He asked me about where I was thinking of applying. I laid out five or six schools I was highly interested in. They were a little bit above my weight class, but I wanted to give them a shot. We talked strategy when it came to the essay, resumé, and potential interview. Very valuable information that I'm thankful to this day that I got. Then we talked about safety schools.

Safety schools are something everyone needs when applying to college. There's nothing wrong with them, and there's nothing wrong with going to them. My counselor mentioned that I probably was going to need a few, especially given I wanted to declare a computer science major.

That made sense, computer science is extremely popular. More and more students every year are declaring it as a major. What struck me was his next suggestion.

Maybe computer science was too competitive for me.

Too competitive? Okay, so I won't get into a few of my top schools. That's fine. My counselor was trying to get at something a little more dramatic.

Math is the single most important thing when it comes to computer science, he told me. If you're bad at math, you won't be able to become a programmer. It goes beyond not getting into school though, because even if I do, according to him, I'd likely be one of the many who drop the major after a year or less.

What I heard was, "You're too dumb to code".

I left that meeting feeling like someone kicked me in the stomach. I never doubted that computer science was exactly what I wanted to do. I'd been insecure about my intelligence, but never about my ability to code. He didn't only plant a seed of doubt in my mind. He watered it, gave it plenty of sunlight, and ensured it blossomed into a fully grown demon reminding me I'm not smart enough.

Over the next few months, I considered several different majors. History? I love learning about history. That could work. Maybe English? I kept thinking, but nothing sparked the same fire in me that coding did. Every time I started coding, though, the voice of doubt came back.

The time finally came to apply to some colleges, and I had to make a decision. I tried so hard to find something, anything that I thought I would enjoy doing more than computer science. Nothing felt right, and so I applied to every school as a computer science major.

Responses started to roll in slowly. Rejections, wait-lists, and even acceptances on the condition that I was not a computer science major. I could hear the voice of doubt in my head saying, "I told you so".

It wasn't until June of my senior year, which was terrifyingly late, that I was accepted off the wait-list at the University of Delaware as a computer science major.

Four years later, I graduated. I made it through a stressful job search my senior year, and then another just a couple of months ago. The voice of doubt in my head still exists, as I know it does for a lot of us. Just remember, if you're passionate about programming, or really anything, don't give up on it just because people say you're not good enough.

Oh, by the way, I still suck at math.

What are JavaScript Pipeline Operators?

Will Taylor — Thu, 21 Mar 2019 01:41:19 +0000

Update: View live examples of the pipe operator on CodePen

JavaScript is a constantly evolving language as I'm sure you've already experienced. TC39, the technical committee that determines what features become a part of the JavaScript standard, is constantly receiving proposals that aim to further improve the language.

One such proposal is the Pipeline Operator. This operator is still in the early stages of the process that brings proposals from ideas to reality, but its availability in Babel 7.3 has allowed it to gain some notoriety. So let's dive into what the pipeline operator actually does.

Let me preface this all by saying I'm covering one of the several proposals that pertain to the pipeline operator. This falls under the fourth, the "smart pipeline operator".

Disclaimer: None of the functionally outlined below is officially slated for an ECMAScript edition, as of March 2018

The Smart Pipeline Operator

Let's say you wanted to be able to perform a series of different string manipulations on a given string. Being an awesome functional programmer, you made each distinct manipulation its own function.

function repeat(str) { return str+', '+str; }

function exclaim(str) { return str+'!'; }

function capitalize(str) { return str[0].toUpperCase(); }

Now all you have to do is pass a string to all of these functions and watch the magic happen.

// Expected result: Hello World! Hello World!
let noPipe = repeat(exclaim(capitalize("hello world")));
// 🤮

That's not bad, but stuff like this can get really ugly and difficult to understand as it grows larger.

Enter piping.

Using the pipeline operator (|>), we can rewrite the above code to achieve the same result.

// Expected result: Hello World! Hello World!
let withPipe = "hello world"
    |> repeat
    |> exclaim
    |> capitalize;
// Pipe it up 🥰

With the pipe operator, you simply continue to call functions using |>, and whatever you use the pipeline operator on will be passed in as an argument.

This can make your code a lot easier to read as you know up front what is being acted upon, and the actions being taken on it read more like a story.

You may be asking now about using the pipeline operator with functions that have multiple arguments. Well, we can take care of those too! Let's take this function as an example.

function add(x, y) { return x + y; }

And now let's use the pipeline operator to put it to work.

// Expected result: 6
let sum = 2 |> add(#, 4);

The # character here serves as a reference to the value we are piping through to each function.

Okay, cool. So we can use this with single and multi-parameter functions and it makes us look really cool too. But what if I don't want to write a function just to do whatever modification I'm trying to do? Why can't I just do some logic inline?

You can! Let's do the same addition again, but this time without calling the add function.

// Expected result: 6
let sum = 2 |> # + 4;

Now obviously this seems a little silly to do with an example as simple as this, but as it grows in size and complexity this operator can really help your code stay readable.

The proposal, which you can view on github includes a lot of these examples and more. Some of the functionality outlined there, however, is not in the latest release of Babel. For instace, the use of await and yield in your pipeline.

Hopefully you found this brief introduction to pipeline operators useful, and make sure to check out some of the other TC39 proposals that made it into Babel 7+! Also, CodePen now has Babel 7 support, so feel free to try this out on there.