As of late, I have found that one of the most common pieces of advice that I give to the developers on my team has been to take a step back and break down the tasks they’re working on into smaller chunks.
It’s not a novel concept. It’s part of the problem solving process. In many cases, the developers that ask me for help have already broken down the problem to a certain degree but just haven’t gone far enough.
When I go about the process of tackling a problem, I’ll go through “break down” process many times. The first time, I’ll break down the overall problem into big buckets of tasks. I might go through a few iterations of this to see if there are different ways to tackle the problem. Once I’ve got my basic buckets, I’ll treat each one as a problem to solve and then break down each one independently. By going through this cycle, I get a good sense of the tasks that need to be done.
If I am working on a task that I start to feel overwhelmed with, I’ll treat it as a problem and run through the break down process again. I find that it helps me refocus and provides me with a clear path to completion.
Most of the time, the developers already know the answers for themselves, they just need to take a moment to look at the problem again and break it down some more so that they can see the specific steps they need to take to move forward.
I’ve always been a supporter of women in the tech industry. I have been lucky to work with quite a few during my career. They have ranged from managers to developers with similar experience to those I have mentored. Through it all, I knew that as women in the industry, they had overcome larger hurdles to get to where they were than I had to.
Up until now, I think I simply acknowledged the fact that the gender issue existed and agreed that it needed to change. I can look back, put the pieces together, and see various occurrences where women I know have been discounted, pushed aside, or looked over. I look back with disappointment with myself that I didn’t recognize the pattern.
It’s bothered me a lot lately. Whether it’s guilt for not seeing things sooner, or the fact that I work with a group of incredible women who I want to see succeed, or because I continue to hear stories of women I respect being degraded even today, it makes me angry.
Lately, I’ve felt very over-protective of the women I work with in the tech industry (either directly or through social media). I’m not sure if I have the right to feel that way because despite the fact that I support them, I don’t know if I’ve actually done anything to help them. I don’t quite know what I should do. When should I intervene? When should I step back and provide space? Maybe the answers are right in front of me and I’m just blind to them?
I’ve never been opposed to asking for help and this is definitely one area where I could use it.
The tech industry is well known for it’s gender gap. It’s an issue that continues and to which I have no solution for. I don’t even think I am qualified to provide a solution because I can’t relate to the problem. Even though I can articulate some of the issues, I will never be in a position to suffer the hostility and disadvantages as the women in the industry do on a daily basis.
I recently remarked on LinkedIn that I have been extremely fortunate throughout my career to have had the opportunity to work with many strong female developers. They broaden my perspective and help me grow stronger as a developer. They have and continue to teach, guide, motivate, and inspire me every day.
To all of the female developers that I work with daily or interact with over social media, as well as those that I don’t know, I want to say thank you. I appreciate everything you have done for myself and the industry and will continue to support you in any way that I can.
With the impending introduction of CSS Grid in mainstream versions of major browsers, I have been playing around with it and trying to learn how I can incorporate into current production scenarios.
One scenario is a content block grid where we have multiple blocks of content that each consist of a title, some sort of image or media, copy, and some hyperlinks. In addition to making the grid of blocks responsive (which is the easy part), the scenario calls for each of the elements within the content blocks to line up with the corresponding elements within it’s sibling content blocks on the same row.
For example, if there are 4 content blocks in a row, the copy of each of the blocks should start at the same point on the x axis of the row. While this is relatively easy when you have total control of the content and can craft it so that each element has a consistent (or at least predictable) amount of content, the challenge arises when you don’t have control of the content.
I have been playing around with the following Codepen to see if I can get things to work. I’ve been able to line up the media at the top of the content blocks and the links to the bottom, but the title and copy sections in the middle look “jagged” because the image heights are different. Instead, what I’m looking for is a layout where the titles and copy sections of each block line up with each other so that there is a more uniform look to the grid.
I’m not sure if that’s possible but I’d invite you to checkout my Codepen (currently viewable in Firefox Nightly and Chrome Canary) to hit me up on Twitter or drop me an email with any feedback or advice you might have.
I’ve opened up an issue with this on Rachel Andrew’s CSS Grid AMA. Check it out and post any ideas you might have. Also check out the other issues on the AMA. It’s a great resource.
I recently returned from San Francisco where I attended my seventh An Event Apart (AEA) web conference. It was another wonderful experience with an excellent lineup of speakers and topics related to the web design industry. As an attendee of more than five events, I was recognized as “An Attendee Apart” and that got me reminiscing a bit about my previous AEA events that I have gone to.
My first AEA was in Chicago in 2008. It was my first conference of any kind and I can remember being star struck by the speakers, many of whom I learned about through Twitter. I’m pretty sure I had some sort of fan-boy complex, particularly for event founders Jeffrey Zeldman and Eric Meyer. I arrived in Chicago thinking that it would help me with my job (which it did) but I came away from AEA feeling connected with the web design community. I started to look beyond my job and out at the industry as a whole.
I skipped 2009 so that I could attend the 2010 Seattle event. This was a game changer for me. Not only did it introduce me to the city of Seattle (where I would eventually relocate to) but it was the first year that AEA included the “A Day Apart” workshop. Two days of speakers talking about various web design topics and then having the third day to dive deep into a particular area resonated with me as a great way to learn. 2010 was also the first year that I used Twitter as my conference notebook, which led to meeting many attendees and a realization that what I was doing was useful for others. Not only did I feel like a part of the web design community, I felt like I was helping it.
Over the years, I continue to attend AEA whenever I can. What I get out of each conference has evolved from practical code and techniques to inspiring the way I think about web design to thinking about how I can help others in the industry. I’m no longer just looking for ways to implement things, I’m looking for ways to solve problems. I’m no longer just looking for answers, I’m looking for ways to help find the answers. I’m no longer just sitting on the sidelines, I’m getting involved.
An Event Apart is great for learning tips and techniques but I believe the true values lie in the feeling of community, the opportunities to learn from the experiences of others, and feeling empowered to contribute to helping make the web better for everyone.
If you’re interested in finding out more about An Event Apart, visit their website or find them on Twitter.
According to MDN, HTML “is the most basic building block of a webpage”. It’s the foundation of the web. The first webpage was built on less than 75 lines of HTML. Yet for such a fundamental part of the web, I find that many front-end developers don’t have a good handle on it.
Editors, templates, and frameworks produce HTML that enable a developer to get content on the page but the resulting code often lacks the features and nuances of the language such as semantics to convey meaning and enhance SEO or attributes and meta data to improve accessibility.
If you’d like to learn more about HTML, I find that the MDN docs are a great starting point. You can also hit me up on Twitter as I love talking about this sort of thing.
Like many web developers, I have used a reset/normalize style sheet in a variety of projects with the intention of having a common starting point for all browsers when it comes to styling CSS. It’s been useful. It works great for setting a baseline to create web pages that are pixel-perfect reproductions of mockups from designs.
However, as I work with building responsive websites where the widening array of devices has changed the way that we design websites, I have fallen back to the age-old statement that answers the question of whether a website needs to look exactly the same in every browser. With the answer to that question, I have found that the reset/normalize stylesheet has become unnecessary.
As a designer, I have come to accept that there may be minor differences from browser to browser. If I can accept that my sites will look different (sometimes significantly) on different devices, there is no reason to get upset if my site does not look the same pixel-for-pixel in different browsers.
This doesn’t mean that I don’t make adjustments to things like margins and padding on a paragraph or list. I choose to embrace the defaults a browser gives me and work off of them instead of stripping them out and starting from scratch every time. I find that this approach makes my code cleaner and more robust without adding any extra overhead.
As the next part of my redesign, I created an SVG version of my pretty logo so that I could take advantage of the file format for multi-device use. Everything looked good locally so I pushed the image and code live… only to find out that a) I was getting scrollbars on the <embed> element and b) Firefox was asking for a plugin!
I spent quite a bit of time looking through the HTML, CSS, and SVG code trying to find out what was wrong and searching the Internet came up with a lot older posts regarding a Webkit height miscalculation bug. Since that issue had been fixed and I was having the same problem in Firefox, that wasn’t the issue.
Turns out the issue lay with my web hosting provider. They didn’t have the proper MIME-type set up for SVG images. This came as a surprise to me as I assumed they would have this in place but at least I had access to the .htaccess file. With the following two lines and a file upload, I was off to the races with my responsive SVG logo!
AddType image/svg+xml svg svgz
AddEncoding gzip svgz
So if you come across issues where your SVG isn’t rendering on the server, check to see that the MIME-type is properly set up.