It’s That Time Again

What time is it?

Time for me to announce I’m starting a new job! My time at Scripted was wonderful. I learned some really good life lessons and understand myself more as an engineer and a person. I’ve discovered I’m really interested in bridging that engineer to the world communication that is so necessary for both internal employees and translating your product to your audience. I’ve shifted from being a mostly backend engineer to a mostly front end engineer (as an aside is anyone else bothered by the fact that the accepted spelling for front end has a space but backend is one word???) and I feel like the topsy-turvy nature of the JavaScript ecosystem allows me to keep experimenting but also not take myself or my fellow engineers too seriously.

It's a secret

I can’t really talk about what I’m doing next as we’re still in a closed alpha. Surprisingly the image above is more of a clue than it seems. I’ll be working as a mostly front end engineer with a very good friend at another tiny startup and this time my goal is to learn. I’m going to be working with some really smart people and I want to soak it all up like a sponge.

Also, I would like to actually post more here. It’s become a bit of a wasteland and I need to figure out how to remedy that. I think my biggest problem is I feel like I need to be super tech professional here and that’s not my life. Well not all of it at least. I also write and knit and play video games and take too many photos of my cats. I tried focusing on that part of me in another place Everything Will Be Amazing but I couldn’t focus on that either. So maybe it’s time to unify. I’ll keep you posted.

Accessing accessibility: Some SEO-friendly tips

This post was originally written for my work engineering blog. Check us out and see some interesting articles from my coworkers at goats.scripted.com.

According to the 2012 U.S. Census, almost 60 million Americans (nearly 20 percent of the U.S. population) have some form of disability. While not all of these disabilities may affect the way people interact with your website, a large population of your potential users probably can’t use your website the way you expect them to. For any company, but especially ones like Scripted that prides themselves on words, this is often an overlooked trap.

Accessibility is not just about making it easier for people with disabilities to interact with your site. Instead, making information easier to consume and understand should be your primary goal. These tweaks can be simple, such as using the appropriate H1 tag versus a stylized div for your main header and having links that are descriptive on their own rather than just saying ‘click me’ or ‘here’. Keeping accessibility in mind also allows you to build a better organized, more SEO-optimized, and easier-to-navigate app for all of your users.

A good place to start optimizing is by running your site through Addy Osmandi’s A11y tool. Running the online A11y URL checker against a page will give you a list of warnings.

A11y warnings for Scripted home page

In Scripted’s case, the home page had some warnings about hidden links and was missing some alt tags for images.

A11y warnings for Scripted order form

Scripted’s order page had some severe shortcomings regarding labeling inputs. Without input labels, many screen readers can only guess what your forms are trying to collect. And as a secret bonus, input labels make the clickable surface of your input bigger. A tiny radio button without a label means the user can only click on the radio dot to choose an option. With labels added, they can click anywhere on the radio or surrounding label to make a choice.

    <label for="content">
        Custom Content
        <input type="radio" name="content" value="custom">
    </label>

A11y passing tests

After adding the labels and making some of the other suggested tweaks to both the homepage and the order flow, the report is looking much better, but one file change won’t solve all your problems. Someone on your team might make a change next week and forget to include an alt on an important image without thinking about the impact. You need a plan! Whether it’s running the URL checker on a regular basis or asking the team to keep accessibility in mind during code reviews (and training them on what to look for), figure out a path that will help you maintain the accessibility of your site. For both quick fixes and good basics on accessibility, a great resource to start your team with is the A11y project.

Flexbox: Tables of the Future?

This post was originally written for my work engineering blog. Check us out and see some interesting articles from my coworkers at goats.scripted.com.

The greatest CSS gif of all time

What is flexbox?

Most websites design around grid systems. A long, long time ago, in Internet years, this was done using frames and actual table grids. Then we all moved on to floats and percentage widths. The Holy Grail layout was often a mess of different solutions. Flexbox is a CSS layout mode that gives you complete control over the components you put in your grid, allowing you to keep sizing organized both inside and outside the box, as well as providing a unified layout styling no matter what screen size you view the components on.

How we use flexbox at Scripted

Flexbox is used at Scripted in a number of locations. Most of our marketplace pages are large grids of cards, and each card is itself a grid. In order to accommodate lots of information about each blog idea, we need to be able to keep sizing consistent with inconsistent data. Our CSS is compiled so we are able to make mixins for flexbox that do the heavy lifting (and solve a lot of cross-browser compatibility issues) for us on the fly.

Flexbox in actionFlexbox in action

On the page above, for example, each card uses our standard flex layout. We added the option of a column direction, meaning information should flow down the page, and each component in an individual card should stack. For the overall grid layout of an unknown number of cards, we use the standard with an additional wrap option so cards flow to new lines when we run out of space (versus trying to crowd them onto a single line).

Why not flexbox?

Unfortunately, like with most newer web standards, support and implementation haven’t had time to unify. For example, Internet Explorer — because it’s always the example with new designs — implemented an outdated flexbox interpretation in older versions. Even with current flexbox standards, different browsers render flexbox styles differently.

Other concerns, especially for sites trying to use flexbox for their overall layout, is the speed of rendering. While it’s a few years old, Ben Frain’s look at the speed of table CSS versus flexbox is a good start. Rerunning the tests now shows some better numbers for flexbox layouts.

We still use table layouts for assets that we want to just work; some of our feature charts are examples of this.

Other resources

While it still has some quirks, depending on your project and your commitment to polyfills, flexbox is a powerful tool to build some really nice layouts. To get started building your own, Sketching with CSS has the ultimate flexbox cheat sheet. And of course, Mozilla Developer Network has a full rundown of flexbox layouts and links to many tutorials.

If Your Only Tool Is a Hammer Then Every Problem Looks Like a Nail

Light on content again today. I’m having a bit of writers block I think. The life is boring but nice, so I don’t have as many existential crises to share with you. As a bit of a carry on to my dialogue last week, I’ve been thinking about the right tool for the job.

I have been wanting to track some stuff I’m working on and I wanted to be able to record a daily log. I spent a week looking at different frameworks and decided what database to use. Then I woke up Saturday morning and absolutely frustrated with myself, I started logging things in a spreadsheet. And my problems were solved. I can keep track of things, use pivot tables if I need more data and write quick charts. Hell eventually I can export it and parse it and put it in a database if I really need to. But do I really need to?

cat shakes head no

Analogous to this, is that shiny fancy bit of code that you’re super smug about because you figured it out and it’s bitchin’. It may be bitchin’ but it will in fact probably be a bitch for the next person to look the codebase to maintain. By no means should you take the easy way out, but if you are trying to use a slick one-liner in production code that takes a half hour PowerPoint to explain, save it for a blog post. Be kind to your fellow engineers. We’re generally quiet, but we will mentally curse you to the fate of having a problem that’s never been answered on Stack Overflow.

No News is Good News? or A Short Discourse on Pair Programming

Things have been quiet here at casa de Lindsey which is good for me, but probably not as exciting for the people who (maybe, sometimes?) read this thing. Since April I’ve been relearning why I love being a software engineer in a supportive and awesome culture at Scripted. It’s a small tight-knit team and I was a little worried about coming in as a newbie to a solid team but they’re amazingly lovely people and I love learning with them and from them. Front-end only land has been so busy I still haven’t had time to really even touch my first love of backend APIs (which would require me to learn Rails to do it justice at Scripted) but I haven’t really mourned that loss. Instead as one half of a front-end team of two I’m running around like crazy helping our backend/full-stack team be better front-end engineers, sitting down with our designer to craft better UX and handholding our marketing team through WordPress template changes when the starts align correctly.

Which brings me to my continued sermon on mentoring/pair programming and how much I luuuuuurve it. I keep reiterating it, but I’ll continue to reiterate. I love mentoring other engineers, I love pairing with people. It can be super awkward at first, because even if you’re the one who is supposed to be mentoring you won’t have all the answers. But that’s not the point! The point is for you to foster learning, for you as well as the other person. Software engineering is not a perfect set of knowledge that you can learn once and then just churn out the same thing over and over, but it’s also not always about going down the rabbit hole of discovery (especially if you have to earn a living writing code for a living). Mentoring and pairing almost feels like cheating to me, because I don’t have to solve all the problems myself. I might not even have to come up with the original idea for something, just help refine it and still get to take partial (but deserved) credit in the end.

Also there are so1 many2 better3 resources than my stream of consciousness musing on pair programming (and a MAJOR SHOUTOUT to a study on the benefits of pair programming for women – hint: it benefits everyone). Please check them out, give it a shot if you can. It is really, really hard at first and it’s definitely not for everyone but for me and most of my pairs it just takes so much stress of the engineering cycle.

Expect more posts soon, I’m thinking of trying my hand at “teaching” since I can never have enough “lemme just show you this one cool thing” moments. If it all works out it will probably be a series of posts a la “I don’t want to make another to-do app in JavaScript to level up my skills”.

 

On to Smaller and Better Things!

My time with Udacity has come to an end. I made some amazing lifelong friends out of it and learned enough to fill a book but I decided it was time for me to trundle along to a new opportunity. So I’m excited to announce that I’m joining Scripted as a JavaScript Engineer! It’s going to be a bit of a brain warp focusing most of my efforts on the front end but I’m ridiculously excited for the opportunity and working with the awesome new coworkers that I’ve met so far. The team is much smaller and very careful to cultivate their culture and I just felt right at home the minute I came on site for my interview with them (as an aside: sort out culture fits first or you will be miserable no matter how potentially amazeballs you think a project is). I really look forward to diving back into my JavaScript roots and being able to geek out about all the upcoming changes.

My other hope in this transition is to get back into mentoring more. Working in Mountain View and attempting to mentor in SF was super draining on me, but now that I’ll be working in SF, I want to pour more of my free time back into mentoring and helping others join this awesome ride that is the tech industry. So I’ll be spending some time to think about how to approach that aspect.

Reminder: Choose For Culture!

Lately I’ve been interacting more and more with people trying to break into the tech industry. It’s something I’m keenly aware of as a recent wall breaker myself and my general desire to mentor and champion other people to do what they want.

I recently had the privilege with my co-host and awesome, awesome person Jennie to lead a talk for Udacity Nanodegree students on how to get into the industry and how to make connections/get a job/etc. I wish I could link you all to it, but it’s behind a paywall currently. Lies! Youtube video:

The talk itself was pretty standard:

  1. Network, network, network.
  2. Recruiters can be your friend/spy.
  3. People are generally nice, especially when you don’t spam them and actually ask them things that are relevant to them.

But between that and a lot of the recent articles on tech interviewing/culture (which I’m not going to give my opinion on in this post as it’s nuanced and hard, but spoiler: pair programming interviews are the bomb) I’m a little dissatisfied that I didn’t mention my number one rule for finding a job:

CULTURE IS THE MOST IMPORTANT FACTOR

I’m not going to pass judgement on different cultures as people are, shockingly, different. Just know that if you have the luxury, which thankfully is often the case in tech, please, please don’t choose a job just for prestige or some weird convoluted inner turmoil. Make sure your coworkers are rad. You will need them, a lot. Many of my best friends now are former/current coworkers. We have nerdy parties, we play video games, we send each other stupid cat gifs (okay, that’s just me sending them out to everyone else, but they appreciate them damn it!), but more importantly they have my back. They can help me troubleshoot stupid mistakes or understand my inner rage at a feature or just geek out with me over the hot new programming hotness.

I think a person I follow on Twitter put it best when he said:

https://twitter.com/tef/status/578676050055561216