This is one of the strangest things about working remote. On days like this, you wake up like you usually do. You make the same coffee and see the kids off to school. You fire up the computer and check email and your calendar to see what your day is looking like. You might even field a few Slack messages, answer some questions on Skype, and post a few gifs like you always do. But there is no denying it. No matter how normal this routine feels, something has changed. Typically this change is preceded by packing up your office the week before, and today would be all about unpacking and meeting new faces. But instead you're remote. And even though you're starting a new job today, everything feels oddly the same.
The first time I heard about CSS in JS I thought it was interesting but absurd. It appeared limited to producing inline styles, and introduced nasty workarounds to support pseudo selectors like :hover and :after. So when Brad wrote about What's wrong with css-in-js, on one hand I completely empathized with his frustrations. But on the other hand I had spent the past 2 years seeing the limitations of traditional, build time, CSS styling and had fully embraced the css-in-js model that Microsoft Fabric UI had adopted. I wanted to quickly jot down my thoughts of why Brad was partly correct, partly incorrect...but mostly, just hadn't seen nothin yet.
Many of my blog posts originate as a good tweet, and this one is no different. Recently I'd been working with a large system of "components" that were very difficult to import, render and test outside of the monolithic application they were built for. I surmised that until we could make significant changes, we didn't have a system of components but simply a collection of abstractions.
Every now and again, I compose a tweet really resonates with my peers. Sometimes I sorta expect it, and other times it's out of the blue. But everytime I do strike that nerve, I'm reminded that a large number of people feel that what I said was important, and if it really is that important, it should probably make its way into a blog! I'm sure I have dozens of old tweets that should be turned into blogs, but for today, I'm going to start with just this one: How making a small demographic change in who I follow on twitter has completely changed my worldview.
A few days ago I saw a tweet asking about whether or not working remote was a good idea for junior level developers, and I couldn't stop thinking about it. I've been working remotely for a majority of my career, from junior level to senior level, and I feel I had a few things to share about how I've been able to make it successful.
I keep hearing that 2018 is going to be the year of the personal blog, and I'd really like to see that as well. For me the thing always holding me back were my multiple blog posts that turned into blog series that ended up never being completed. It's hard to feel confident diving into another year of blogging with so many failures in the past. But then I realized what my main problem was...
So far, all of the solutions we've talked about so far are build time solutions. They won't change from render to render. But as your component gets used by more and more people, you often find that people want to change things at runtime, when the component is being rendered.
Sometime back I tweeted "Writing the correct CSS once is pretty easy. Making that CSS work in all situations, and for all people is the hard part." and it resonated with more than a few people. I'm not saying that CSS is simple, and doesn't require skill to master. I'm saying that writing the correct CSS is just the first of many steps when creating a large scale Design System.
Having entered 2014 with a pink slip in my inbox, there's no way I could have imagined where I'd be today. How does one go from losing a junior position (64k/year) to landing a senior position at Microsoft (level 64) in 2 1/2 years? There's part of me that wants to say the answer is "a ton of luck", but I think a better expression is "several great opportunities and the willingness to seize them". The first of those opportunities did not require much deliberation as, after 3 weeks of job hunting, I was offered an amazing position with a DC based Drupal agency. The next opportunity though, came much quicker than I expected. My first hour of employment was spent at a sprint retro meeting with the client who's website I'd be spending the next 2 1/2 years building, and it was my willingness to seize that opportunity that opened every other door.
In 2013 I took a leap of faith, accompanied by a song, and applied for a position at a prominent Drupal shop. I barely qualified, having taught myself everything I knew about Drupal in the month prior, but I knew they needed front-end developers, and I was starting to get pretty good at this new Responsive Web Design thing. Even though my time there was cut short, it laid the foundation for which I credit my current success. Let me tell you about that journey.
Today I am writing this article while riding in a warm, comfortable, wifi-enabled bus to my senior level position at one of the most desired employers on the planet. I hope that this does not come off like a brag. I'm constantly amazed at how fortunate I am to be where I am, and my imposter syndrome won't even allow me to feel superior to a junior developer. Yet here I am, doing the work that I love, and getting paid well for it. So I wanted to share a bit about my journey and write down some of the lessons I learned along the way. I'm going to share my salary information as well, not to "prove what a success I am," but to help others set expectations and demand equal pay for equivalent work.
You might say that I've been living under a rock for a bit. With all my focus on design systems, and more recently React and Typescript, I've been completely ignoring the elephant in the room...the inevitable arrival of CSS grid and how they will change the way that we write out layouts! In this post I'm going to be sharing my thoughts as I take a first look at this incredible new layout tool, and hopefully it'll intice you to take the plunge yourself.
One of the challenges of developing for an open source design system like Fabric React is that, as a system used across our entire organization, developers will have unique requirements for various components. We might create a dropdown menu, but a developer might have a use case for icons added to the left side, or the ride side, or on both sides, or image thumbnails, or multi line, or..or..or..or..... until we've got a dropdown component that has a hundred different possible properties, tons of custom CSS to cover each use case, and dozens of tests to make sure that each possible variation doesn't break.
A funny thing happened this last month. Between two different events, and three isolated groups, a consensus was made, terminology was chosen, and the way that we approached building and implementing design systems changed forever.
This past week I was thrilled to stumble across the alliteration filled article by Brad Frost called simply "Frontend Design". Actually, I didn't stumble across it at all, as it was showing up in just about every feed I followed around the interwebs. It had been tweeted, retweeted, quoted then tweeted, screen captured, uploaded and tweeted so many times that I had a feeling Brad had struck a particular nerve in the community. So I sat down to read it, curious to see see just what pain, joy, or fear receptor he might have hit.
Metalsmith bills itself as "An extremely simple, pluggable static site generator", and it delivers in some big ways. If you want to learn more about Metalsmith, you are in the right place! Over the next several posts I'll be diving deep into how the system works, how you can extend it, and how you can make it do just about anything that you want. If you aren't interested in static site generators, or if you're already invested in some other platform, don't go anywhere! This isn't just a simple how to. I am going to spend some time peeling back the layers of a sophisticated NodeJS tool. I'm confident you'll learn about good ways to dive into the tools you already use, and understand them more completely. Once you "know how the sausage is made", you'll be in a better position to debug, improve and extend anything in your current toolchain.
It's that time of the year when everyone sits down and writes about what they did over the past 12 months, and what they hope to do with their next dozen. I normally don't do these, and have thought they were a bit silly at times. But the more I think about it, this post isn't as much for you to read, as it is for me to write. So here I go. 2015 in review:
2013 was a banner year. I started working at one of the most well respected Drupal shops in the country. I traveled to Prague to speak at Drupalcon about my rapid prototyping framework, Tractor. At CSS Dev Conf, in the historic Stanley Hotel, I spoke in front of some of my CSS idols about Getting Your Sass in Line. After spending the previous year being envious of Seattle's Sass Meetup, I decided to start PDX Sass and now welcome dozens of front-end developers to our meetup at Puppet Labs each month. Lastly, after recording a few Sass demos for friends, I decided to just continue making demos, creating the Sass Bites Podcast. Now with hundreds of Youtube subscribers and over 20 episodes under my belt, I feel like I am just getting started.
This week I spoke at the inaugural meeting of the PDX Sass and Front-end Meetup that I have been organizing for the past month. The event went great. We had a better than expected turn out, some amazing pizza and I got a lot of great feedback on a talk that I had been preparing for the past few weeks. Click through to see the video and other details about the event.
I have been diving headlong into Compass Sprites for a large response redesign. The site has a ton of sprite images, so it seemed to be a perfect opportunity to learn as much as I could about spriteing. One of the problems I ran into was that Compass used @extend to add selectors to the background-image property. This obviously causes problems in media queries.
This week I finally got through chapter 6 of Drupal 7 Module Development, and I have to say, it was quite an experience. This chapter walked me through the process of creating an entirely new entity, called Artworks. True to form, I followed along and hand typed over 700 lines of schemas, controller functions, page callbacks, menu entries and form validate hooks.
Life has a way of being cruel and ironic. I was thinking yesterday how lucky I was to have a job where I could go home, and leave work at work. Fast forward a few hours and I was having trouble sleeping as I tried to tackle a sticky Sass and Media Query delima.
As I've mentioned before, I am going through the "Drupal 7 Module Development" book, trying to learn as much as I possibly can as I go from chapter to chapter. I still stand by my suggestion of explaining your code in plain english. That one technique has really served me well as I try to trace the flow of Drupal's rendering process. Sure, it makes getting through a chapter take longer, but I always find the process worth while. Another thing I do that slows down my progress is typing out, by hand, every single line of code from the module examples.
I have quite a bit on my plate with this current project. As the only developer I am tasked with the design, front end, and back end development of the entire site. With the design and front end coming together quite well in the past weeks I have been starting to focus on the back end. Having decided to build this site on Drupal, I knew there was going to be a steep learning curve to get to the point I wanted to be at.
Some of the first big decisions I had to make for my mobile first design was how I would handle media queries. One of these decisions revolved around whether I would use an exclusive, or inclusive media query.
@Brad_Frost pointed out a blog entry today by Bearded called The Thing About Those Media Types. The TL:DR of it is that some people use "screen" in their media queries, while others do not. Right now this is not a huge deal because almost all devices that are capable of displaying websites identify themselves as "screen" media type, even if they are a TV or a projector.
I came across a tool today that I can honestly say I've been trying to find for years, CSS Inliner. If you do any HTML email designing you know it's best to put your styles inline (to get the best email client support), but inline styles are HORRIBLE to maintain and difficult to implement when you have multiple authors contributing. CSS Inliner is a tool that will take everything from the style tag and spit out HTML code with all of those styles inlined! I've seriously dreamed of finding something like this, and here it is.
Over the past week I've been putting the finishing touches on my first round of html comps for our new responsive, mobile first layout. True to the mobile first nature, I started with no media queries, reduced the width of my browser and started to design away. I've been really happy with the results and wanted to share a few thoughts I had after finishing the process.
After months of sitting on an updated Godbolt.me, I finally decided that today was the day to stop hiding in my MAMP install and get it out there. I know it's not perfect, I know there is much more I plan to do with it. But as any startup will tell you, get your product out there, get feedback, and then iterate. So that's the plan. Just enough functionality to not look like a total fool, and plenty of room to grow!