Forem: Amy Holt

Meet border-box, my best friend.

Amy Holt — Mon, 02 Sep 2019 23:16:14 +0000

Have you been given the advice to use box-sizing: border-box; but not completely understand what it was doing for you?

Whether working to recreate comps down to the pixel or building my own designs, border-box has made my life a lot easier. But it didn't seem any easier until I understood what it was doing for me. That's why it is my best friend and I think you might want it in your life, too!

Before you dive into this, you should have an understanding of content, padding, border, and margin and the role each of those play in the box model.

`box-sizing: content-box;`

content-box is the default value for the box-sizing property for most elements. The content in content-box means that content, and only content, will use the height and width that are applied to an element.

If we apply a width of 200px to a div, we won't be surprised to see it take up 200px. Now, when we add on 10px of padding and a 3px border, we will see that the box is now 226px wide:

If I truly only have 200px for this element, I now need to subtract the padding and border from the content, so I set the content at 174px. Any tiny change I decide to make to the padding or border from there on out, I'll also have to calculate and make a change to the content.

`box-sizing: border-box;`

The border in border-box means that the border and everything inside of it, padding and content, will count toward the defined height and width of the element.

If we apply a width of 200px to a div element, then the 10px padding and 3px border, the content, padding and border will all fit within that 200px width:

If I need to modify the border or padding at any time, I can count on border-box to keep the element the size I defined, saving me tome from having to do the math and adjust the content's height and width every time.

Different Elements → Different Default Styles

While most elements default to content-box, not all necessarily do! This depends on the user agent stylesheet for the browser you are using. In Chrome's latest stylesheet, buttons are defaulted to border-box along with several types of inputs.

Example

To see this in action, visit this CodePen. Commenting out lines 30 and 34 one at a time can give you a feel for what each declaration does.

Wrap Up

border-box may be your new best friend, but only if you know what it is doing for you. Try adding it to the next small project you whip up and see how it helps you!

Be an Approachable and Empowering Mentor

Amy Holt — Mon, 15 Jul 2019 15:46:17 +0000

While these thoughts are frequently running through my head when I teach, pair, and observe others do the same, the 9th trait of a 10x engineer in the recent shit-storm motivated me to collect these ideas and get them out. If you missed it:

I think engineers, junior to senior, should be able to mentor and teach others. Mentoring and teaching require skills that we aren't just born with, and may not feel so natural for some folks. But that's ok - it's learnable!

What is a Mentor?

For the context of this blog post, I'll use the term mentor to describe anyone who is...

serving as an official mentor
a more senior engineer teaching something they have more expertise in
a less senior engineer teaching something they have more expertise in
co-worker or classmate teaching something they have more expertise in
educators

So, anyone who shares their knowledge with anyone else!

Why is this Important?

The way mentoring interactions feel for the mentee can hugely determine the trust they have in their mentor, whether they feel valued, and their confidence and happiness in that space. A negative mentorship experience can lead a mentee to feel discouraged, frustrated, and like they are alone in their professional growth. On the other hand, a positive mentorship experience can make a mentee feel confident, valuable, and empowered to continue growing and collaborating!

How Do You Do It?

There is no silver bullet. It takes work and thoughtfulness. Some of the things we say and do that might be leading to us not be approachable or empowering are deeply engrained into our daily language. Those are habits that we have the power to change!

Check Your Vocabulary

Consider the following words:

just
simple
easy

All three of these words are harmless and perfectly acceptable to use in the workplace. But when a person hears them over and over, in reference to something that is complex and new to them, it adds up and can contribute to that imposter syndrome, as well as the approachability of the person using those words.

True Story: Last week, I advised a new student to refactor a lengthy function. They asked how they would go about it, and I said "Just pass that function an argument of whateverItWas". To me it may be "just passing an argument", but to my student, at that moment, that meant about nothing. I immediately backed myself up and we worked through it together, but I can't undo my use of that word and the impact it may have had.

Similarly, something that currently seems "easy" or "simple" to you may not be for your mentee. Removing some of these oh-so-engrained words from your vocabulary could make a huge impact for your mentees experience and your approachability.

Remove Assumptions

"We all know how to _______, right?"

How does that feel for the person who doesn't know how to _______?

They now might be questioning if they are ready to learn what you're about to talk about.
They may be wondering if they are the only person who doesn't know _______.

In this scenario, the mentor just assumed the mentee did know that concept, therefore sent the message that they should know it. It's was probably the mentor's intention to create a transition from something the mentee likely has previous knowledge about so they have some context for the concept they're about to discuss. Keyword: likely. Instead of assuming, let's ask them! It might take 30 more seconds, but they payoff will be your mentee feeling empowered going into this new topic!

Another way to spin it:

"Are you familiar with _______?"
"Before we dive into this, tell me what you know about _______."

This provides the mentee the opportunity to articulate their understanding and be part of the conversation. If that answer uncovers a misconception of lack of essential prior knowledge, the mentor know has this information and can fill in the gaps before moving on.

Hands Off Their Keyboard

Unless you are driving and they are navigating, just don't do it.

If they are having trouble understanding what you are trying to have them do, you can white board it, you can back up and go character by character. Whatever you do, don't touch their keyboard. That moment someone realize they are "too slow" or just "don't know enough" for the mentor in front of you can be heartbreaking. It can also be really infuriating when a mentor writes code that the mentee don't understand.

We aren't mentoring code, we are mentoring people. If you want to teach someone to fish, you don't just bring them a bucket of fish. Don't fish for your mentee.

And if the reasons above aren't compelling enough, the germs on someone else's keyboard should be.

Wrap Up

Not sure how much these tips apply to you? Take the next week to keep track of what you say/do. Jot down a tally mark every time you say "easy" or go for someone else's keyboard. If you realize it is something you need to work on, work on it! Tell a co-worker and ask them to hold you accountable. Or be straightforward about it with a mentee so they can also help you in your journey. Your mentees will appreciate you for it 💖

Semantic HTML? How can you tell?

Amy Holt — Wed, 26 Jun 2019 15:54:03 +0000

When HTML5 was released in 2014, developers were given a slew of new elements. Many of them are meant to serve as a replacement for the flavorless jello <div>, the inline <span>, and other elements whose names didn't convey much meaning.

Utilizing these elements to give our HTML as much meaning as possible is what it means to write "semantic HTML". Using semantic HTML results in the same appearance of our site in the browser, but it provides a lot of benefits to both users and developers.

Benefits of Semantic HTML

Increases Accessibility

Semantic elements help screen readers understand the context of the content on your site better; therefore communicate it to users more effectively. Search engines are also more effective when they have semantic tags to reference.

Dev Empathy

We've all seen that codebase with 14 nested <div> elements, and even with perfect indentation, it gets difficult to read. Using semantic elements, such as <nav>, <section>, <article>, and <footer> in place of the <div> element, when appropriate, can alleviate this. This will also make reading and updating the document easier for future-you. Another benefit for devs is when we need to style elements - instead of those 14 <div> elements that all need their own attribute, we now have different element names that we may not need to add as many attributes.

What Does it Look Like?

One of the two cards below was built with semantic HTML; one was not. Can you tell which is which?

The answer is - you shouldn't be able to tell by looking at the result in the browser. Semantic HTML should result in the same appearance; but the elements we use should communicate meaning to us, the devs, and technologies that read our code, in order to provide a better experience for all users.

Here's a screenshot of the code, side-by-side. See the full CodePens by clicking on the links below.

Find the CodePens here and here.

Note: There are many different ways the HTML could have been written for this card - all using semantic elements. This is by no means the best or only solution!

What About `<div>`s?

This does not mean you should never use a <div> again! Notice that, in the "Semantic? Yes" example, I chose to use a <div> to wrap the host details. I didn't want to communicate anything about the chunk of content, but needed the container to use FlexBox in my CSS. However, I chose to use an <article> element for the card itself, then a <section> to differentiate the rental info from the host info.

<div> elements probably do still have a place in your site. When you're not sure if you should be using a <div> or a more semantic element, ask yourself, "Are these elements grouped together because their content belongs together? Are they grouped together because I need a container for styling?" That can be a starting point for making that decision.

Your Challenge

After reading this you may be thinking "I already use some semantic HTML" - that's great! I encourage you to read through a project you're currently working on and assess your use of semantic HTML. If something sticks out to you, refactor it!

Wrap Up

Just like in anything else in programming, there is not one right way to write semantic HTML, but it's important we are thoughtful and constantly trying to make our applications more accessible to users and readable to other devs.

Check out MDN's page on Semantic Elements to learn about more of the elements available for your use!

Forem: Amy Holt

Meet border-box, my best friend.

box-sizing: content-box;

box-sizing: border-box;

Different Elements → Different Default Styles

Example

Wrap Up

Be an Approachable and Empowering Mentor

What is a Mentor?

Why is this Important?

How Do You Do It?

Check Your Vocabulary

Remove Assumptions

Hands Off Their Keyboard

Wrap Up

Semantic HTML? How can you tell?

Benefits of Semantic HTML

Increases Accessibility

Dev Empathy

What Does it Look Like?

What About <div>s?

Your Challenge

Wrap Up

`box-sizing: content-box;`

`box-sizing: border-box;`

What About `<div>`s?