DEV Community: Bastion Fennell

Traction: A Management Book Review

Bastion Fennell — Mon, 11 May 2020 16:39:33 +0000

For those of you who don't know, in my free time I really enjoy reading two things:

Management books
Roleplaying books

Surprisingly, they're actually very similar types of content! We explored this a bit in my last post Dungeon Master to Dev Manager. Both types of book offer the reader a system of thinking, a way to view the world. Good management books give you a new lens with which to view and address most problems rather than just a tool to address a specific problem.

Traction, by Gino Wickman introduces us to the Entrepreneurial Operating System (EOS), a complete top-to-bottom paradigm for running your business. The book pulls a lot from other well respected books and pairs those with Wickman's many years of experience helping businesses succeed to give you a complete system to run your entire business.

Overall, I would give Traction 4.5/5 stars! Here at Volusion we've started using it as the main system across our business, and the effect has been staggering. It's brought alignment in both our cultural values and our business goals from the leadership team to every employee. If you want a one stop shop to define everything you need for your business, look no further!

Let's talk about some of the highlights!

What is EOS

EOS is made up of 6 main components:
Vision
People
Data
Issues
Process
Traction

In the book, each of these components gets an entire chapter dedicated to the systems involved and the nuances of implementing it. Similar to roleplaying books, Traction is like the core book. You can learn everything you need to effectively use it with this single book. However, for anyone who wants to dig in more, EOS has an entire library of books to help you learn more and implement EOS in the best way for your company.

Wickman calls this system an Operating System for good reason. It's very specific and breaks every part of your process down in a way that can be understood within this system. As a developer, having such a clearly defined API for interacting with the business is incredible!

Let's talk a bit more about those components!

Vision

Vision is the first (and possibly most important) component to get clarity on. EOS uses what's called the Vision/Traction Organizer to consolidate all of the core ideas of your company in a way that anyone can understand at a glance. It includes your core values, issues, niche, mission statement, and even short and long term goals!

Just being forced to write all of these things down on paper is incredibly powerful. It's easy for companies and teams to fall into the trap of everyone having a different vision for the company, different goals. If you can get the whole organization to align towards a single goal, you can tackle big challenges and do amazing work.

People

People is the next, and often toughest, component. This section is divided into the idea of getting the "right people" into the "right seats." If you can do that, everything else starts to fall into place much easier.

Figuring out if you have the "right people" means figuring out if the people you're working with match the core values you defined in the "vision" component. They recommend using their People Analyzer, which is basically just a spreadsheet of people and how those people match the company's core values.

After making sure you have the "right people," next you have to get them into the "right seats." When someone is in the right seat, it means they "Get it, want it, and have the capacity to do it." Is everyone in your organization working to their full potential, and are they a good match for the work they're doing?

Again, just writing these things down on paper adds a lot of clarity. It helps you understand how much you may have compromised on your core values, who's overloaded, who's underperforming, and more. Unfortunately, Wickman direly warns that no company has successfully implemented EOS without having to make personnel changes.

Data

The data portion is very straightforward. Once you have the right people in the right seats, the next step is defining and measuring success. Everyone should have an objective measure of how well they're doing. Easy, right?

Unfortunately, it's the actual definition of these measurables that's the hard part. Crafting them in a way that alerts you about problems before they happen, not after, is even harder. Once these measurables are defined though, you can check them weekly and know at a glance how well you, your business, or your team is doing.

Issues

Issues are a part of every business. If there weren't issues, there wouldn't be so many books about how to solve them! Traction requires the leadership team to be transparent about their issues and to be honest about whether those issues are going to be solved now or later.

The big tool Traction recommends here is the Identify, Discuss, Solve (IDS) system for meetings. The most important part of that trio is Solve. After discussing an issue, you should have one of two things: an actual solution, or a person selected to find that solution. If implemented well, you can finally say goodbye to discussing the same problems over and over again!

Process

Nothing can be fine tuned until it's consistent

Process is an important but oft forgotten component of EOS. To successfully implement this step, first you have to decide on your Core Processes. Then you must document them and distribute them and make sure everyone follows the process. No exceptions.

Once it's documented and being followed, it's easier to see where the issues and inefficiencies in your business are. It's also possible to see what impact the changes you make actually have instead of trying to discern them from the day-to-day chaos.

Traction

It's the name of the book, so obviously this is a big one. The "secret sauce" of the whole thing. Traction is about accountability and discipline. This goes hand in hand with the scorecards you make in the Data component of EOS.

With this component, you define measurable quarterly goals (called Rocks), then you set up weekly meetings to see how everyone is achieving against their Rocks. Everyone has at least one Rock, though leadership typically has a few more that they're responsible for.

One of the most important parts of Rocks is that they can't be changed mid-quarter. Obviously, circumstances may force you to change them, but ideally these Rocks give you clarity for the quarter and define what success (or failure) looks like for you and the organization. It gives people not only ownership but also accountability for what they're supposed to do this quarter.

Bringing it All Together

In the end, none of the stuff that Traction brings to the table is necessarily ground-breaking or revolutionary. It's not meant to be. What it's meant to be is a set of simple tools that you can use across the organization to create clarity, drive accountability, and create the traction you need to get things done!

These simple tools can be used by anyone and understood by anyone, which is what makes them so powerful. Along with the actual tools, it also gives you a shared language across the organization so people know what you're actually talking about. Rocks, IDS, Core Processes, etc. Having that shared language makes everything flow more smoothly, clears up a lot of confusion, and allows you to focus on solving real problems instead of just misunderstandings.

Final Thoughts

Like I said, here at Volusion we're going all in on Traction and EOS! It's the system we use to run everything from top to bottom, and it's been wildly successful in bringing both clarity and direction to the organization.

Even if you don't buy in 100% to EOS, you can still find something new or a different way to approach your business problems in this book.

Hopefully I'll write a follow up post later this year to talk more about how we've implemented it specifically at Volusion!

Plugs!

Volusion is hiring! Times are tough right now and a lot of people are out of work. Volusion is currently hiring devs, product, and design in Austin, TX!

I have a Twitter! I'd love to get better connected to the Dev.to community! I also tweet far more frequently than I blog...

And of course, if any of this post intrigues you, you can learn more at EOS Worldwide. There is a whole company dedicated to helping other companies achieve success through EOS, and there's a whole library of books around all different aspects. You're sure to find something interesting!

Thanks for reading!

Books Referenced in Traction for Further Reading

Mentioned multiple times:
Unique Ability: Creating the Life You Want, by Catherine Nomura, Julia Waller, and Shannon Waller
The E-Myth and The E-Myth Revisited, by Michael E. Gerber
The Five Dysfunctions of a Team: A Leadership Fable by Patrick Lencioni
Mastering the Rockefeller Habits: What You Must Do to Increase the Value of Your Growing Firm, by Verne Harnish
Think and Grow Rich, by Napoleon Hill

Mentioned once
Focus: The Future of Your Company Depends on It, by Al Ries
You 2: A High Velocity Formula for Multiplying Your Personal Effectiveness in Quantum Leaps, by Price Pritchett
The Four Obsessions of an Extraordinary Executive: A Leadership Fable, by Patrick Lencioni
Risking, by David Viscott
Nuts! Southwest Airlines' Crazy Recipe for Business and Personal Success, by Jackie Freiberg and Kevin Freiberg
Good to Great: Why Some Companies Make the Leap...and Others Don't, by James C. Collins
One Minute Manager Meets the Monkey, by Hal Burrows, Ken Blanchard, and William Oncken
Leadership, by Rudolph Giulani
How to Win Friends and Influence People, by Dale Carnegie
Managing by Values, by Ken Blanchard
First Things First, by Stephen Covey
Death by Meeting: A Leadership Fable...about Solving the Most Painful Problem in Business, by Patrick Lenceoni
Confidence: How Winning Streaks and Losing Streaks Begin and End,
by Rosabeth Moss Kanter
Small Giants: Companies That Choose to Be Great Instead of Big, by Bo Burlingham
Happier: Learn the Secrets to Daily Joy and Lasting Fulfillment,
by Tal Ben-Shahar

Dungeon Master to Dev Manager, What DnD Taught Me About Leadership

Bastion Fennell — Sun, 05 Apr 2020 21:51:30 +0000

The room darkens as the sunsets final rays filter through the windows. We gather around the table, various cups and containers that once held caffeinated beverages litter the room now only serve as a reminder of how long we've been at this. The end is near, everyone hold their breath as you...

For "Deploy the hotfix to prod" go to page 66

For "Sneak attack the lich" go to page 34

Roleplaying, Storytelling, and Leadership

Roleplaying and software engineering have long run in the same circles. Back in my day, they were both considered "nerd hobbies" that no one popular would be caught dead doing. Nowadays though, both have seen a sort of renaissance. Now, engineers are cool and almost everyone knows about Critical Role!

I've been roleplaying and storytelling (another term for being a dungeon master) for about as long as I can remember. Building worlds with other people has always been something I've enjoyed. For better or for worse, because of that I tend to view the world through the lens of a lifelong storyteller. Through that lens, I think there are some lessons we can learn when it comes to leadership. So, what are we waiting for? Let's dive right in!

Have a Plan, But be Prepared to Improvise

This is an especially hot concept in modern roleplaying. As more of the roleplay market have day jobs, a lot of "prepless" roleplaying games have started popping up, games where people with day jobs don't have to spend hours putting together characters and campaigns for. The idea for these systems is that the storyteller is just another player. The storyteller is playing to see what happens, just like the players.

I find it helpful to strike a balance, both when it comes to leadership and storytelling. As a storyteller, I want to come to the table with a general plan, but I also want to encourage my players to build something I could never think of and make the story even better! When that happens, I need to be ready to pivot and work those ideas into the narrative.

Similarly, as a dev lead, you want to have a general plan for a milestone or epic or whatever. However, you also want to leave room for creativity and be prepared to change your plan. One of your teammates might have an idea you never thought of, or product might entirely reprioritize. In either case, you need to adjust the plan but still keep things rolling smoothly.

Make Sure Everyone Has a Chance to Contribute

In storytelling, there is a concept of a "spotlight." At any given moment, one or two characters have the spotlight. For that moment, it's like that character is the protagonist! It's your job as a storyteller to make that character shine, show off what makes them special, and leave them feeling like they just did something amazing that only they could pull off!

The tricky part about spotlighting is that you have to distribute it around the table. If one character is always in the spotlight, the other players will quickly get bored. Sometimes it requires a bit of coaxing, and not every game will highlight every player, but when everyone feels like they're making an impact it leads to a better story that everyone has fun making.

Spotlighting has pretty easy corollaries in leadership. Making sure you acknowledge the contributions of everyone on the team (not just one or two high achievers) and that everyone has a chance to build something they're proud of are the two big ones. To really spotlight effectively though, you need to know what drives your teammates, what truly excites them. The more you know about that, the more you can find and tailor tasks to that person and make them feel as successful as possible.

You Should Also Be Having Fun!

A LOT of people are dungeon masters because no one else in the group wanted to be, so they felt they had to pick up the banner and run with it. At a certain point, you have to ask yourself

Is this what I want to do?

It can be easy for senior devs to kinda "fall into" management positions rather than seek them out. Similarly to storytelling and being a player, managing and being an individual contributor are completely different skillsets that are rewarding in completely different ways. Not everyone wants to be a manager, and that's okay!

At some point, you need to make sure you're doing what you actually want to do. It often feels like the only way to progress at a certain point is going into management. Luckily, we're getting better as a community at offering higher level technical tracks that are separate from management tracks. Hopefully this trend continues and we can let people who want to code, code and people who want to manage, manage. That way no one falls into a role they don't want.

In The End, It's All About Collaboration

The most important takeaway from all this is that the dev lead is just another team member. It's not your job to run everything and prepare everything and micromanage everything as a lead. It's your job to bring the best out of people and make them feel like they've achieved something every day. To make your teammates feel delighted at work.

As long as you approach a problem collaboratively instead of competitively, anything is solvable!

Learning with Clicker Games Part 2: CSS

Bastion Fennell — Fri, 22 Mar 2019 16:29:28 +0000

This is the second part of a three part series:
Part 1, Layout with HTML
Part 2, Styling with CSS
Part 3, Interaction with JS

In this part, we'll be learning CSS! In the first part of this series, we built out the bare layout of our clicker game using HTML. Now we're going to take that layout and make it look better!

When I initially got into web development, CSS was one of the first things to really hook me. Being able to really manipulate what the users are seeing and interacting with... It was like magic! And just like magic, the rules can be complex and arcane. Nevertheless, it gets the job done!

With any luck, by the end of this post our clicker game will look like this:

If you're already familiar with CSS, take a stab at styling it yourself! You'll see we did add a little bit more content as well, just to make the game more user friendly. The general HTML is the same shape as what we built in part 1 though.

What is CSS?

CSS stands for Cascading StyleSheets. It is essentially a set of rules that tells the browser how the HTML should be rendered. The idea is that HTML is the content, while CSS is the presentation.

Separating out presentation and content is also a way to help make our sites more understandable and accessible for things like screen readers. They can just pick up what they need from the HTML and ignore the CSS!

So, what does it look like? Typically a little something like this:

body { // tag
  background-color: black;
  color: white;
}

.upgrade-button { // classname
  width: 200px;
  height: 50px;
}

#header { // id
  height: 50%;
}

First, you put an identifier followed by {}, then put the rules to apply to that identifier between the {}. What are these identifiers? Well, they can be tags like <div> or <body>. They can also be what are called class names or IDs. Classes and IDs are attributes that you can define on an HTML element so that you can apply specific styles to it.

<div class="container wide" id="main-container"></div>

These attributes are a space separated list of identifiers. Classes can appear multiple times on the page, so they're good for recurring elements. IDs, however, should only appear once on a page. Use it to make sure that you only have one of an element.

In CSS, we use a . to say we're styling a class, and a # to say we're styling an ID. So, to style the div above we could use:

div {} to style based on the tag
.container {}, or .wide {} to style based on the classes
#main-container {} to style based on the ID

Cascading

You can also combine identifiers to make them more specific. For example, div.container.wide {} will only target div tags that have both the container and wide class applied to them.

If multiple styles apply to the same tag, the more specific one will win. This is where the term cascading comes from. If your stylesheet looked like

div {
  background-color: black;
  width: 100px;
}

div.wide {
  width: 200px;
}

Then any div will get that initial div styling. If you add the wide class to a div it will still get background-color: black but the width: 200px will override the width that only applies to div tags.

Another way to add specificity is by selecting elements within other elements. If you add a space between the selectors, you're telling the browser, "anything within this element that matches this selector should get these styles."

div.wide a { }

This will target any <a> tag within a <div class="wide"> and apply the stylings. If you had another styling that just targeted <a> tags, it would override them.

There are a lot of rules to remember with CSS, but there's just one last one that we care about right now. If two selectors match something with the same specificity, the last one in the stylesheet will be applied.

div.wide {
  width: 200px;
}

div.override {
  width: 150px;
}

If you had a <div class="override wide"> then the override styles would be applied instead of the wide ones.

That's enough theoretical stuff for now. If you want to dig into CSS specificity more, check out this post by Chris Coyier on exactly this topic!

Getting Our Classes in Order

Let's get to building!

If you followed along with our last post, you probably have something that looks a little bit like this:

So how do we make it look a little bit nicer? When styling, the first thing we should do is organize our HTML with classes that are clear and understandable. That way, when you come back to your code, it's easy to understand what was going on.

Let's take our first section, with the actual clicker button. If you look at the pen (codepen example) at the beginning of the post, we want to make the part with the clicker button more prominent. Luckily, it's already in its own div! We just need to add the class names.

// Original
<div>
  Lines of Code: 0
  <div>
    <button> Write Code </button>
  </div>
</div>

// With classes
<div class="clicker">
  Lines of Code: 0
  <div class="clicker__button-area">
    <button class="clicker__button"> Write Code </button>
  </div>
</div>

Looking at that pen again, you'll see we did make a few tweaks to the layout itself. Let's adjust our HTML to match that new layout while we're here. You'll hardly ever get the layout right on your first try, but one of the awesome things about web development is how fast the feedback loop is! Change something, check the browser, adjust it, check it, etc. etc.

<div class="clicker">
  <div class="clicker__button-area">
    <div> 0 Lines of Code </div>
    <button class="clicker__button"></button>
  </div>
</div>

Perfect! Now, the next two sections of "buyables" are pretty much the same, so we're going to use the same classes for both of them.

// Original
<div>
  Number of Extra Hands: 0
  Price: 10
  <div>
    <button> Buy Hands </button>
  </div>
</div>

// With Classes
<div class="buyable">
  Number of Extra Hands: 0
  Price: 10
  <div class="buyable_button-area">
    <button class="buyable__button"> Buy Hands </button>
  </div>
</div>

You might ask yourself why I'm writing the classes like this? These classes are roughly built on the BEM or block, element, modifier spec. It's a good way to keep your classes organized!

If we take another look at the first pen, you'll see we made some changes to this section as well! So, let's update the layout to match. Let's also wrap the whole section in a new div to differentiate it from the clicker section.

<div class="buyables">
  <div class="buyable">
    <div class="buyable__amount"> 0 </div>
    <div class="buyable__text">
      <div class="buyable__title">
        <span class="buyable__title-text"> Extra Hands </span>
        <span class="buyable__title-price"> 10 Lines of Code </span>
      </div>
      <div class="buyable__description"> More hands on the keyboard = more typing </div>
      <div class="buyable__effect"> Adds 1 line of code per click </div>
    </div>
    <button class="buyable__button"> Buy </button>
  </div>
  ...
</div>

We should be able to use these same classes to update the other buyable as well! Go ahead and do just that.

Actually Writing CSS

If all goes well, we should have something that looks like this.

Still looks kind of ugly, but we're only dealing with the skeleton for now. Let's go ahead and get into the CSS and make it all pretty!

First, let's add a stylesheet.css file right next to our index.html file. This is the file that we'll be writing all of our CSS into. Now, we need to tell the HTML where to get its' styles from. In the <head> of the HTML, add

<link rel="stylesheet" type="text/css" href="stylesheet.css" />

This tells the HTML what the stylesheet is and where it is, so it'll actually load our styles onto the page. While we're adding links, let's also use one to bring in the Google Open Sans font

<link rel="stylesheet" type="text/css" href="//fonts.googleapis.com/css?family=Open+Sans" />

Before we go any further, let's check to make sure that worked. In your CSS, just put:

body {
  background: red;
}

Now, if you load up the page, you should immediately regret the decision and be bombarded by bright red. Now that we know they're linked, let's remove that line and add some nicer backgrounds for each section.

.clicker {
  background: #002b35;
}

.buyables {
  background: #fdf6e3;
}

The colors we're using come from a palette called Solarized that I use development all the time. I figured it would be fitting for a game about writing code.

There we go! We got the basic colors done, but it's all weirdly proportioned. Let's fix that. We want each main section to take up half the page, which we can easily do with the height attribute;

.clicker {
  background: #002b35;
  height: 50%;
}

.buyables {
  background: #fdf6e3;
  height: 50%;
}

Now there's a weird margin around the page still. Turns out, browsers add a default margin. The margin property defines the amount of extra space you want around the component. We'll go into a little bit more detail on that later, but for now, let's just override it.

body {
  margin: 0;
}

While we're at it, let's update the font-family to the open sans that we imported earlier!

body {
  font-family: "Open Sans";
  margin: 0;
}

Perfect, now we have our canvas written out! Next step, let's tackle the top section. We want to have our lines of code and button content centered. You have a few options with this, but we'll use the one most of the industry is trending towards, flex-box. Flex box has a lot of intricacies, but for now think of it as a way to lay out content that behaves predictably.

We'll want our main clicker area to be a flex box with some added attributes to make it center both horizontally and vertically.

.clicker {
  display: flex; // Makes this div a flexbox
  align-items: center; // This centers things vertically
  justify-content: center; // This centers things horizontally

  background: #002b35;
  height: 50%;
}

That should have centered our content, now let's actually style that content. This introduces you to three new concepts:

border-radius the roundness of the corners of a div.
padding the space between the div content and its border. For spacing, in order you have padding, border, then margin.
opacity how transparent the div is

.clicker__button-area {
  background: #fdf6e3;
  border-radius: 8px;
  opacity: .8;
  padding: 30px;
}

Last touches here, let's do some text formatting. We can use font-size and text-align to make our button a bit clearer and nicer looking.

.clicker__button-area {
  font-size: 24px;
  text-align: center;

  background: #fdf6e3;
  border-radius: 8px;
  opacity: .8;
  padding: 30px;
}

As a final touch for this second, let's make the button look like a keyboard! I just pulled this image from the wikipedia commons to use for our button. Let's add a public/ folder next to index.html and put this at public/keyboard.png.

When styling things like buttons or dropdowns, you have to override some of the browser's default styling. In this case, the default background, border, and outlines. The only new thing here is outline, which is basically a way to show users what element has focus.

.clicker__button {
  background-color: #fdf6e3;
  border: none;
  outline: none;
}

Now, let's introduce the idea of a background-image here as well. There are a few different ways to do images, but this will show us how to manipulate backgrounds! The main strange thing here is background-size. We're using background-size: cover, which will stretch the image to fill the entire container. For a few other options to play with, check out the Mozilla docs.

.clicker__button {
  background-image: url("public/keyboard.png");
  background-size: cover;
  height: 150px;
  width: 250px;

  background-color: #fdf6e3;
  border: none;
  outline: none;
}

Great, if all went well here, it should look something like this:

We've actually already pretty much used all of the CSS properties we'll need for the next section, with the exception of font-weight and some higher level flexbox shenanigans. Go ahead and try to style the rest of the app yourself before continuing down this page!

The Rest of the Owl

All that's left really is the "buyables" half of the screen. This is where everything buyable lives, hence the name. Right now it's just extra hands and code monkeys, but down the road we might have more items and even things like upgrades here!

When styling, I like to work my way from the biggest container down to the smallest one. Since we already styled the .buyables area, that means the next step is the buyable itself.

Since we're reusing classes here, if we style one card correctly it should style the other ones the way we want as well! Let's start by defining the size of the buyable cards.

.buyable {
  width: 600px;
  height: 75px;
}

Right now we're giving everything fixed heights and widths for the sake of simplicity. This means we're essentially styling to a single page width. What we really want is for users to be able to access our apps from any device, meaning any screen width, and it still look good. This idea is called Responsive Design and it's becoming more and more important to consider.

That being said, we'll save that for another time! For now, let's introduce you to borders!

Borders wrap around our tags and sit between the padding and the margin. They have a few properties that you can define on them, like border-radius that you've already been introduced to. A few others are:

border-color: white | red | #123456;
border-width: thin | thick | 10px;
border-style: solid | dotted | dashed;

Most of the properties are self explanatory, they tell the browser the color, size, and type of border you want. It's a lot to type out every time we want a border though. Luckily, there's some shorthand we can use!

border: 10px solid #123456;

This lets us define all three properties at once! Using that, let's give our cards a border now.

.buyable {
  border: 2px solid #002b36;
  border-radius: 8px;

  width: 600px;
  height: 75px;
}

Finally, let's add some padding to give our inner tags some breathing room, and margin to give the cards themselves some space.

.buyable {
  padding: 10px 20px;
  margin: 10px;

  border: 2px solid #002b36;
  border-radius: 8px;
  width: 600px;
  height: 75px;
}

This introduces you to some new shorthand! We've seen padding: 30px before as a way to add spacing, but what does it mean when there are two values? padding is shorthand similar to border, except that it's used for the more explicit values:

padding-top
padding-right
padding-bottom
padding-left

If there's just one value, it defines all of them to be that value. If there are two values, it's equivalent to this:

padding: 1 2;

padding-top: 1;
padding-right: 2;
padding-bottom: 1;
padding-right: 2;

The way I remember which ones define which is that the first value always defines the top. You can also define all four, which will go in clockwise order starting from the top.

padding: 1 2 3 4;

padding-top: 1;
padding-right: 2;
padding-bottom: 3;
padding-left: 4;

Last step, let's declare these cards as a flexbox container so we can arrange the inner tags a little easier!

.buyable {
  display: flex;

  padding: 10px 20px;
  margin: 10px;
  border: 2px solid #002b36;
  border-radius: 8px;
  width: 600px;
  height: 75px;
}

With this, we should have something a little like this.

Uh oh, what's going on with that white space between our two sections? Turns out there's a thing called margin collapsing that can make margins behave unexpectedly! To solve this, we'll add an overflow: auto to the .buyables div. The overflow property tells a tag what to do if certain content goes outside of its box, but in our case it solves our collapsing margin issue.

.buyables {
  overflow: auto;
  background-color: #fdf6e3;
  height: 50%;
}

We've got our card container defined, now all that's left is the inside! Let's start all the way left with the amount. The first new flexbox property we're going to introduce here is align-self. This property tells the tag how to align itself vertically in this flexbox, similar to align-items earlier, so we can more easily center it.

.buyable__amount {
  align-self: center;
  font-size: 24px;
}

Let's move on to the text section! The second flexbox concept we're introducing here is flex-grow. flex-grow is a way to tell the browsers which tags we want it to expand within the flexbox first. It's a bit more complex than that, but that's good enough for now. We're going to use it to make the text section fill up all the space between amount and the buy button, minus a small margin.

.buyable__text {
  flex-grow: 1;
  margin: 0 20px;
}

Perfect! Let's dig into that text section, shall we?

We have two elements within it that we want arranged fairly specifically, so we're going to use another flexbox.

Let's reintroduce you to one more flex box property, justify-content. This property tells the flex box how to position the elements within it relative to each other. We're using space-between to keep our elements are far from each other as possible.

We're also going to use the more specific margin-bottom property, similar to the padding-bottom we talked about earlier.

.buyable__title {
  display: flex;
  justify-content: space-between;
  margin-bottom: 5px;
}

Within this title section, we're changing the fonts a bit. We want the title to stand out, so we're going to bold it using font-weight. Some fonts let you get more specific with their weight, but we just need bold for now!

.buyable__title-text {
  font-weight: bold;
}

Just add a smaller font-size to the effect, and we've only got one thing left!

.buyable__effect {
  font-size: 12px;
}

Now all we have is the button! You can probably do this one by yourself, go give it a shot! If you want to get it pixel perfect like our codepen at the top of the page though, here's the CSS.

.buyable__button {
  align-self: center;
  background: none;
  border: 2px solid #859900;
  border-radius: 8px;
  color: #859900;
  font-size: 20px;
  height: 30px;
  width: 80px;
}

We Made It!

Success! Our final product!

That was a lot to slog through, I know. However, these are the exact same things I use at work every day. With only a handful of exceptions, all of the CSS properties I need are contained within this post.

What I really want to try and get across though is how to think about CSS. Starting from the outside and working your way in. Starting to look at a website and get an idea of how you'd need to break something up to organize it correctly for styling.

Try taking what you learned here and rebuilding something that you've seen in real life! A tweet, a dashboard, maybe even this post! Try and tackle it like we have so far in the series. Break down what you think the HTML should be, build out the skeleton, apply the classes, then add styling.

In our next post in this increasingly long winded series, we'll add some interactivity to our app using Javascript!

I'm Bastion Fennell, and I support women devs.

Bastion Fennell — Fri, 08 Mar 2019 21:53:06 +0000

I will advocate for gender equality by...

Pushing for better and more inclusive interview strategies

Fostering a workplace culture that is more accepting of different communication and programming styles

Being an active part of my local community and seek out opportunities to help women in tech

Assuming the women I meet at conferences are developers

I hope to see my school/work/developer/tech community...

Become less focused on combative approaches to programming

Be more supportive of junior developers

Branch out from just bringing pizza and beer to meetups

My advice for fellow allies is...

l i s t e n
With both ears
All the time

The issues that underrepresented groups deal with every day are largely invisible because we've internalized the behaviors associated with them.

Systemic issues are all around you, we need to be an active part of finding these issues AND solving them. No more expecting everyone else to come to us with problems and solutions. They don't deserve that extra emotional labor on top of the biases fighting against them.

If you have a platform of privilege, it is your duty to help those that don't. Being an ally can mean just being supportive, but it can also mean so much more.

Let's try to help ease the emotional burden of finding problems, dealing with problems, and proposing solutions to problems.

As long as we listen to the people most affected by these issues, we can do our part to help solve them.

Learning with Clicker Games Part 1: HTML

Bastion Fennell — Tue, 05 Mar 2019 17:27:37 +0000

This is the first part of a three part series:
Part 1, Layout with HTML
Part 2, Styling with CSS
Part 3, Interaction with JS

In this part, we'll be learning HTML! Our goal is to build the bare bones layout of our app. You could say right now we're laying out the canvas that we'll use for parts two and three of this series.

Everyone has a different idea of what the "Perfect First Webapp" is when you're learning frontend development. Some people think you should build something like TodoMVC, a fake portfolio site, or maybe even just trying to copy facebook. All of these are good, but I'd like to introduce a new idea to the mix:

Incremental games

When I first started learning how to program and taking an interest in software development, I certainly didn't think I would become a web developer. I wanted to make video games! While I didn't wind up in that industry, I still have that itch to build games every now and again. Incremental games are the perfect way to combine the worlds of web dev and gaming. So, let's get started!

What is an Incremental Game?

Rather than tell you what an incremental game is, it might be best to show you. The game that got me into it initially was Cookie Clicker, which you can try out for free in your browser right now!

Basically, incremental games (also called clicker games or idle games) are all about collecting a particular resource. At first, you have to click and interact with the game. As the game progresses, you start to use that resource to buy items that will automatically harvest that resource every second. Eventually those items outpace your clicking so all you have to do is manage what to buy next and check on it every now and again!

We're going to be building our version of Cookie Clicker, called Code Clicker. Original, I know. Instead of collecting cookies, we'll be "writing" lines of code! In our initial app, we'll have two items we can buy: Extra Hands and Code Monkeys. Extra Hands will make our clicks write more code per click, while Code Monkeys will automatically write one line of code per second.

Now that we have an idea of what we're building, let's get started!

What is HTML?

For any sort of web app that we want to build, we gotta start with some HTML, or HyperText Markup Language. Think of HTML as a way to communicate what we want the page to look like via text.

Fun Fact

HTML is based on SGML, but has become the de facto web standard.

The main components of HTML are tags. HTML has a set of defined tags that have different effects on what we show on the page. There are a lot of tags, but here are a few that we'll use in this project:

<html> The tag that wraps the whole document and defines it as html
<head> This section doesn't have any displayed content, it only contains metadata for the browsers to use
<body> This section contains the layout of the page and what we will actually display to the user

<div> Short for division, this tag is simply used to mark a division or piece of the page
<p> Short for paragraph, used to define a section of text
<h1> Short for header, you can use h1 - h5 for different levels of header
<a> Short for anchor, used to create links
<button> A clickable button

Using these tags we'll create the general layout of our app. Now, this is going to look ugly. The next step, which we'll cover in the next post, is to style it using CSS and make it look nice. HTML is just to build the layout.

By the end of this part, hopefully we'll have something like this!

The idea here is that we're writing lines of code by clicking the write code button. There are also a few things we can buy below it to start automatically incrementing lines of code. It's not interactive yet, we'll get to that in the third part of the series.

So, how do we get here? Let's break it down. Create a file called index.html and let's start building our layout! First, let's make the wrapping HTML tag.

<html>
</html>

That lets the computers know this is an HTML document. Notice that we have the opening tag: <html> and the closing tag: </html> Anything between those two tags will be considered a part of it, or one of its children.

Next, we put our two main sections.

<html>
  <head>
  </head>
  <body>
  </body>
</html>

The head is for our metadata, the body is for our display data. So, what is metadata? It's data that the browser can use, but isn't strictly used for the layout of the page. Let's put in some example metadata!

<html>
  <head>
    <title> Code Clicker </title>
  </head>
  <body>
  </body>
</html>

The <title> tag is what is displayed in the tab when you're on the page. If you open up your index.html file in your browser now, you should see that the tab says Code Clicker on it now! Next, let's add our top section, which will show how many lines of code have been written and give us a button to write more.

<html>
  <head>
    <title> Code Clicker </title>
  </head>
  <body>
    <div>
      Lines of Code: 0
      <div>
        <button> Write Code </button>
      </div>
    </div>
  </body>
</html>

Now we're using div tags! These div tags serve two purposes: Putting the button and the text on separate lines, and defining this top section in the HTML.

If you're more familiar with HTML, you might think we're a bit div happy in this app. Since this is a jumping off point for a web app, we want to start getting comfortable with divs now. We'll be using them for styles and with Javascript in the next couple of posts.

We're also introducing our first button! You could just use a div here, but it's important to make your interactive elements as clear as possible using things like button and input tags. That way, screen readers and people navigating via keyboard can still use your app. If you want to dig into this type of thing more or learn how to make your web app more accessible, check out the A11y Project.

Since we already know how to use each of the tags now, let's go ahead and just add the two 'buyable' items to our page.

<html>
  <head>
    <title> Code Clicker </title>
  </head>
  <body>
    <div>
      Lines of Code: 0
      <div>
        <button> Write Code </button>
      </div>
    </div>
    <div>
      Number of Extra Hands: 0
      Price: 10
      <div>
        <button> Buy Hands </button>
      </div>
    </div>
    <div>
      Number of Code Monkeys: 0
      Price: 100
      <div>
        <button> Buy Hands </button>
      </div>
    </div>
  </body>
</html>

And voila! We have the basic layout of our app using nothing but HTML! In our next post we'll explore CSS and see how we can make this look better.

How did your incremental app turn out? Let me know in the comments below!

Software Development for Humans

Bastion Fennell — Thu, 28 Feb 2019 16:47:17 +0000

// Be wary ye who venture into the depths below
// Here be dragons

It's a programming tale as old as time. You jump into the codebase, ready to be productive and push out a bug fix. The ticket was estimated at one day of work, should be easy to knock out.

But no.

The further you dig into the code, the less you understand it. You feel like you're taking crazy pills.

How did this ever work???

Someone is to blame for this... Who could have done it? You pop open your terminal, it's time to figure out who to git blame. Your heart skips a beat as your trusty terminal seemingly turns on you...

Bastion Fennell 2019-02-22 10:44:36 -0600

It was your code this whole time!

Developer Empathy

When we're developing software, especially in industry, it's easy to only think of one end user: the customer. While this isn't necessarily a bad viewpoint, I'd like you to think about one more end user: the next developer. Specifically, the next developer who is going to be working on this piece of code. Especially because it's likely that next developer will be you.

To build software for humans, we have to start to gain a little bit of empathy for that next developer.

Empathy
em·pa·thy
/ˈempəTHē/
noun
the ability to understand and share the feelings of another.

To develop that empathy, we just have to put ourself in the shoes of the next developer. Which should be easy, because we've all been that developer. We've all worked in existing codebases and had to figure out what is going on. While Developer Empathy is something you'll be honing your entire programming career, here are a few concrete techniques to make the next developer's life easier.

Don't be Clever

As developers, we have a drive to try new things and patterns. Sometimes, these new things that are exciting to us aren't exactly clear to everyone else. When writing code, we want to make sure we're writing readable code instead of the smallest, fastest code possible.

Of course, if performance is a huge concern or specifically what you're working on, you may still have to write some clever code. You may actually need obscure APIs or complex single line calculations. For the most part, though, being a little clearer with our code and our intention with the code will make everyone's lives a little easier.

This leads nicely into my next tip:

Verbosity Over Brevity

for(i=0;i<100;)document.write(((++i%3?'':'Fizz')+(i%5?'':'Buzz')||i)+"<br>")

FizzBuzz, as written here in JS. Sure it works, and it's neat to look at, but it's almost impossible to understand at first glance. This is more a subset of "Don't be Clever", but it's important to be conscientious with how we name things and lay things out in our code.

for(i = 0; i < 100; i++) {
    const fizz = i % 3 === 0;
    const buzz = i % 5 === 0;

    if (fizz) {
        document.write('Fizz');
    }

    if (buzz) {
        document.write('Buzz');
    }

    if (!fizz && !buzz) {
        document.write(i);
    }

    document.write('<br>');
}

I'm not saying my code or implementation here is perfect by any means, but it's at least understandable. If someone was given a ticket to print Baz every time the number was divisible by 7, it would be super easy to do it. Being more clear in your intention when writing code is a way to think of the next developer who is going to have to understand that code.

Documentation

My final tip is the same tip that everyone will tell you and hardly anyone will do: Add more documentation.

// Document, document, document!

Sometimes, code has to be complex. Sometimes it's hard to see where this console error actually came from. Sometimes you know that what you are working on will be used by a lot of people.

In all these cases, try to add enough documentation to make it easy to understand. When you're writing the code, you have all the context for the problem. At least, you have most of it. Try to think about what parts of that problem will be hard to understand for the next developer, and add that in the comments somewhere.

Here Be Dragon Slayers

There is a lot more to consider when writing software for humans, but hopefully this will give you a good starting point! Together, we can go from just finding dragons to being dragon slayers!