Sleep! Take breaks! Travel! Learn a new skill (particularly an offline skill, such as calligraphy or woodworking, may be useful). And switch up your front-end-related tasks if you can.

I love CSS 😀 But if I had to pick a few things I love a little less:

1. You can't label interaction style changes in CSS (i.e. there is no ::toggled pseudo-selector)

2. Support may lead to non-uniform vendor prefixing (which is a problem especially if you're writing vanilla CSS)

3. It's not very DRY (i.e. in vanilla CSS you have to rewrite classes to target pseudo-states)

I'm not a very qualified person to give advice on career changing 😛 but I guess I would give the same advice as someone starting in this field -- get a good grasp on the basics and build as much as you can to practice and improve your skills.

Lately, 7.5-8 hours a night (when I'm not traveling) 😄😄😄 You have to prioritize sleep! It's so important!

(But to be fair, I've only recently started prioritizing sleep -- I'd say 6 hours was my average for a long time)

Get on email lists and actually read them (Codrops is a good resource, there is also CSS Weekly, Javascript Weekly, and many others. I also recommend making time to either attend a conference or watch conference talks at home. Cue up a few on Youtube and spend a few hours watching/discussing with a fellow tech friend.

Most of all, practice -- side projects are key! If you want to learn a new skill, build something using that skill. This will force you to find resources and answers.

Start with contributing documentation and with issues that are labeled help wanted or intro PR. There are some great resources to help people find projects who are looking for beginner contributors like Your First PR and some great open-source projects always looking for beginner help like Hoodie.

I think the main thing with open source is: start small. A little bit can go a long way and build your confidence to make larger contributions.

<iframe src="//giphy.com/embed/l3E6qj3wFoUiXbxuw" width="480" height="270" frameBorder="0" class="giphy-embed" allowFullScreen></iframe><p><a href="giphy.com/gifs/l3E6qj3wFoUiXbxuw">via GIPHY</a></p>

🔥 Oh it will be 🔥

:( I tried to post an image:

I haven't looked much into it, to be honest.

I think people who have a vision impairment will likely use their own screen readers (to access other parts of their systems) which they're comfortable with, and I'm a little hesitant to override those.

The web will always be a changing entity. I've learned that the only way to be happy working on it is to embrace that change as an interesting challenge and continue to move the web forward. Always stay on top of emerging technologies, but don't let them overwhelm you. There's no way to become an expert on everything, but that doesn't make you any less valuable of a team member.

Making accessibility an important core tenant of your company is one way to make beginners care about it :) emphasize how it's key, don't let inaccessible code get merged to production, and accessibility will quickly become a habit/part of the development process.

Haha I wanted to be a fashion designer 😜. In high school I discovered the Wacom tablet and Adobe Flash, fell in love with Actionscript, and didn't realize that I had secretly been coding all my life (Neopets, Myspace, etc.). It seemed that front-end development was a natural fit. More on that here

Good Question Regina!

• Dark Matter -- I just finished reading this, and it's so good. Highly recommend if you're into sci-fi
• Americanah was also really good and gave me an entirely different perspective
• The Girl With all the Gifts was somewhat creepy but incredible
• The Art of Racing in the Rain was very cute and made me smile
• Outliers is probably the most inspirational book I read :)

There are so many more! But these come to mind immediately

Hi Michael!

• I say, avoid existing frameworks if you're working for a company. You should be building your own framework that fit your needs without the cruft of pre-existing solutions. This way, you can tailor your solution to your needs and use your own pattern library.

• I think CSS frameworks are good for prototyping -- this means, initial product iterations or 36-hour hackathons. Please, please invest in some design and UI development to then build a custom solution when there is a product at hand.

• I think the answer, as usual is: it depends. Are you building a prototype for a hackathon, or are you building a product? Hackathon: yes, product: no.

Ahh so many questions! I'll try to answer them all here:

RE: Getting started with speaking/noticed

Definitely start with writing -- get your ideas out somehow in an understandable way. Start sharing them. Then, start attending local events -- meet people, get to understand a crowd, volunteer to give a presentation at work or at a local meetup, and work your way up from there. Making yourself noticed (at least to me) has a lot to do with helping your community and infusing yourself inside of it. Then, don't be afraid to submit Calls for Proposals. I've submitted SO many :P

RE: What do I pay attention to when speaking

I try to focus on the audience, gauge who they are and their reaction. Speaking is really about connecting with people--you need to connect before you can get them to hear you.

RE: Getting started with UI development

Basic HTML, CSS, and JavaScript is where you should start. Don't worry about frameworks or preprocessors until you need them. Some excellent free online resources include: CSS Tricks, SitePoint, and Smashing Magazine

Hi Muhammad,

Honestly, I don't know that much about them, so I can't really provide an opinion :/

una.im is built on Jekyll. It's a pretty simple site. You can see the internals here: https://github.com/una/una.github.io

Hi Ricardo!

Thanks for the question. It's a good one, and definitely something I struggle with . I'm not sure there's a "great" solution for the work/life balance problem, but what I do think is true is that people have more time in their days than they realize.

What do you do in the morning, on your commute, or at the gym? You could be listening to podcasts or audiobooks, or even watching conference talks. I think exercise is really important. I get a lot of my ideas for blog posts when I'm working out (not when I'm working on an issue directly). I also make time to see my friends, but also, never watch TV (unless its with somebody). I wake up early to write, and go to bed reading. There's time in your day, it just takes some figuring out, and its not easy to figure out.

What's really helped me is keeping track of my goals which have been public since 2014. If I don't write down that I'll do something -- I will forget it. And having that list is a great reference to turn to when I have downtime.

Writing things down is the answer to your second question. Think about your larger goals, break those down, and write down the steps you need to take to get there. I gave a talk once (and only once) about this topic that I think you might appreciate.

Hello!

Great question. A technical writer can be defined in a few ways -- someone who writes tutorials, documentation, or specifications. I've so far written tutorials, research articles, and documentation for pattern libraries at various companies. It's definitely not my full-time job, but a big part of what I do on the side (writing blog posts) and is tangential to working on front-end assets like pattern libraries (where documentation is essentially your product).

To get started, I don't think you need an english degree, you just need a knowledge of the topic at hand and an ability to communicate that topic to someone who might not have the same background as you. Thats the most important part -- an ability to understand the point of view of someone who doesn't have your technical background.

To answer your last question, I prefer writing in markdown personally because its familiar.

Hope that helped! :)

I don't know if I would characterize there being "problems" per se, because these two roles work very closely together. But I think the biggest challenge between them is that they simply have different goals sometimes. Making something beautiful vs. accessible could be an example, and finding that balance is where you can really make a product shine.

My only suggestion would be to communicate more. Try pair programming/designing and discussing in-person (or on-video) the reasons behind your thought process or decision making.

Involving design in the process early and often is how we maintain a great balance of friendly UI and powerful tools to maintain your system. One of our key values is: "Strive for simple and elegant solutions" and we keep that in mind with every iteration on our product.

In terms of technologies, it depends on which part of the product. digitalocean.com is built using Middleman, while some of our other pages such as the Community and Cloud site use Ruby and/or Ember.

Thanks for the question, James!

I don't use either personally :P I think they both have their individual usecases, and I've not found a reason to use either on my personal work apart from side projects just to test the technologies out. At work, we use Ember.js, which I really like for its CLI and convention over configuration approach when working on teams. Create-react-app also provides this sort of convention, though I sadly haven't had a chance to play with that one much yet.

Hi Maria!

It's actually a super-quick url trick:

  function addEmoji() {
    if (navigator.userAgent.indexOf('Mac OS X') != -1) {
      window.location.hash = "💁";
    }
  };
  addEmoji();

All I'm doing is adding the emoji after a hash. I'm checking for Mac users because the emoji was causing some non-Mac users URLs to break and not be able to access my site. I'm also adding it as a hash because if it were part of the URL "proper," going to any link without the emoji would 404. But adding an emoji hash is harmless otherwise on Mac

I work remotely, and am constantly traveling so my outside-of-work time varies greatly. At my job, it depends on the sprint cycle and task at hand. We recently rebuilt/relaunched the new company website and Hacktoberfest. Currently, I'm working on more internal front-end architecture. Some days its bugfixes and accessibility audits. So it really does vary :)

I love the people at DigitalOcean and how much they really care about what they do. The company drew me in because of its involvement in the developer community (I first heard of them at student hackathons and wanted to be a part of something that gave back so much to my community). And that kind of love is still very much a part of everything we do at DO. The company really trusts in its employees too, so theres a lot more autonomy in terms of bringing an idea to life than there were at larger places I've worked.

CSS3 is widely supported today, but it's definitely important to check browser support for the set of technologies you and your workplace are supporting. This is an important conversation to have at work/with your client (the exact tech stack of browsers you're supporting).

With that in mind, make choices that can reflect this decision. Then, be sure to test on various browsers and systems. Sometimes you find weird bugs on Chrome for Windows or IE10 that you weren't anticipating. Browser testing is the best way to uncover and resolve these.