Skip to main content

Kimberly Blessing

Giving Credit Where It's Due on Ada Lovelace Day 2014

3 min read

I haven't written a post for Ada Lovelace Day in a few years (last in 2010) and recent conversations have made one feel necessary. When the contributions and accomplishments of my female contemporaries on the Web are unknown to people just a generation behind, I get extremely concerned. After all, the making of the Web is the making of history in modern times. As I've pointed out before, we have the opportunity to document our times and lives unlike never before -- but data loss can occur. And it is.

Twenty years ago, when I was in college and learning how to create web pages, I pretty much had two sources of information: documentation written by TimBL and USENET newsgroups. But once I started working professionally, I realized that there was a wealth of information being printed on paper. And what I saw was that large numbers of these books on web development and design were being written by women.

Me and Molly HolzschlagMe with Molly Holzschlag

Women such as:

I wish I could tell you exactly how many books these women have collectively written -- I'm sure it's over 100 -- but quick searches of their bios and websites doesn't always make this data clear. Is it modesty? Do multiple editions make the numbers tricky? I don't know.

But when I mention the names of these women -- all of whom are still active online, many of whom are still writing (or speaking) about the web and programming -- to web developers today, I'm often met with blank stares. I'll have to mention that Lynda founded Lynda.com, (still!) one of the top online training sites, or that Jen co-founded the extremely popular ARTIFACT conference. I have to explain that Dori has helped run Wise Women's Web, one of the earliest communities for female developers online, and that we have Molly to thank for convincing Bill Gates and Microsoft to be more open about Internet Explorer development at Microsoft (there are so many articles to link to, but I want to link to Molly's old blog posts, which are gone *sadface*).

While my past ALD posts have been happy remembrances of people who've made positive impacts on my life, this post is written out of frustration -- and even a bit of anger -- that the contributions of these women are being forgotten or overlooked in their own time. Let's give credit where it's due. Comment or blog or tweet about the books written by these women that helped you learn your craft. Send them a thank you email or tweet. (In Molly's case, you can give to her fund.) Share this post or the links to these women's websites with someone who needs to learn about their foremothers. And just be thankful that women helped light the path for others by sharing knowledge about building the World Wide Web.

Kimberly Blessing

Web Developer Job Search: Your Resume

6 min read

I estimate that I have spent a full work-week, over the course of my career, reviewing web developer resumes. That's enough time to produce some strong opinions on the topic. Allow me to finally continue the Job Search thread by sharing my advice for creating a top-notch web developer resume.

Resume Format and Structure

Your resume format should work to highlight your strengths. The chronological resume, perhaps the most traditional format, fails in this regard. A functional resume does a much better job of highlighting your experience in a specific role, but most web developers are good at more than one thing. I suggest mixing aspects of the two formats, organizing them in a way that makes sense for you and your strengths -- then you'll have a resume that stands out.

Here are the general sections found in a great web developer resume. With the exception of the first two, the rest can be ordered and/or further broken out according to your needs.

  • Objective: If you're searching for a job, you ought to know what you're seeking! Customize your objective, as needed, when replying to job postings. (Note: If you're not actively seeking a job, but still want to have a resume posted online, it's okay to omit this section.)
  • Summary of Qualifications: It's a cheesy headline, perhaps, and all too often the summary is filled with buzzwords -- but I have read really compelling summaries that made me want to know more about a candidate. Focus on describing your strengths and what you contribute to an organization.
  • Skills: This is where the keywords and buzzwords will start showing up. That's okay: you'll back them up with evidence in the other sections. You can subdivide this section in any number of ways: Technical vs. Soft Skills, Front-End vs. Back-End Skills, Design vs. Development Skills, etc.
  • Professional Accomplishments: Here you can include project accomplishments, awards, public speaking engagements, publishing credits, or descriptions of really awesome things you've accomplished. Like the Skills section, you can also break these out separately.
  • Work Experience: If you've done any combination of full-time work, freelancing, and volunteering, this is the most generic title you can use for your work history. Some people like to break out their professional experience from other work, but I think that can undermine the importance of having taken on freelance or volunteer work. If you list accomplishments for each job in this section, don't repeat them elsewhere, and vice versa.
  • Education: I don't like to see this section missing from a resume. Haven't gone to college? That's okay. Be proud of what schooling you have made it through and list it here. Oh, and that includes training programs, conferences -- anything you've forked out money for that you've learned something from!

Required Information

If your resume were to consist of only two things, it should be these:

  • Contact Information: You'd think this would be a no-brainer, but I have seen resumes where developers didn't list a phone number, email address, or personal web site (more on that below). In my opinion, it's a waste of space to display your full home address, especially if you are looking to relocate. No one's going to snail-mail you an invitation to interview, so city and state will suffice. HR will collect the rest of your contact information later.
  • URLs: I wish I could tell you exactly how many of those ~500 resumes didn't include a single URL... but my gut says that at least half didn't feature even a personal web site URL. Seriously? If you're a web developer, you should have some URLs to share. If you're brand-new to the field, put some of your school projects online. If you've only ever done intranet-type work, get permission to copy parts of the code and make it available, or create other projects of your own to demonstrate your skills. If you're serious about getting a web development job, you need this.

On the flip side, don't waste space on these bits of information: references (or the phrase, "References available upon request"), GPA, salary requirements, or personal information (except if you have hobbies that would be of interest to another geek and would increase the likelihood of getting invited in for an interview).

Frequently Asked Questions

Does my resume have to fit on to one or two pages? No, I don't think that it does. However, I think it's nice if a resume is so well edited and structured that, when printed, it fits to exactly one or two pages (one page if you're young, recently out of school, or switching careers; otherwise two pages). However, if you truly have so much awesomeness to report, then, by all means, go on! If you're really that super-duper, I'm sure I'll want to know all about it.

Does one resume fit all jobs? NO! Don't be afraid to tweak your resume format or content to the job you're applying for. In fact, if you have diverse enough skills and interests (design vs. development) you should probably have completely separate resumes for these purposes.

I am graduating soon and don't have much web development experience. What can I do to beef-up my resume? Use the "Objective" area to make it clear that you're looking for an entry-level position. Highlight your strengths in the "Summary of Qualifications" area and place the "Education" section next, so it's clear you're just coming out of school. List your technical skills, as well as any soft skills that you can support with extra-curricular or volunteer work. If you have been active in a tech community or have attended technical or web conferences, list those.

I'm switching careers. I've taken some web design and development courses and done some small projects. How do I reflect all of this in my resume? First, don't hide the fact that you're switching careers! Your prior experience, even if in a completely different industry, has (hopefully) taught you how to deal with people and has helped you understand your strengths. Start your resume with an "Objective" statement that spells out your desire to move into web development. Then list your skills, training and experience with the web so far before providing your employment history and other educational details. Highlight any experience that translates across industries, but otherwise keep the non-web details short.


I hope the above helps you create an awesome resume. Remember, your resume (supported with at least one awesome URL) helps get you in the door for an interview, so take some time to craft one that truly reflects you!

If you have questions I haven't addressed above, I'm happy to accept them in the comments below.

Kimberly Blessing

The Problem Isn't IE6 -- It's You

5 min read

This post is going to upset a lot of people, I'm sure, but what I have to say needs to be said, if only to remind members of our community to behave themselves.

Is Internet Explorer 6 an old, outdated, hanger-on of a browser? Yes, absolutely. Does it require the use code hacks in order to achieve semi-parity with more modern browsers? Yes, it does. Should this be such a problem for web professionals? No, it shouldn't.

IE6 Cartoon Thanks, Tracy Apps!

For a moment, forget about all of IE6's issues, security, how much you dislike Microsoft, or whatever baggage you're carrying around. Instead, think about IE6 as an unknown browser -- perhaps as a random blip in your browser stats, or maybe as an interesting piece of tech you've seen on a blog or at a conference. You don't know much about that browser or how your site is going to work on it, so what do you? You code it using web standards goodness: you create a base with semantic markup (and any server-side tech for forms), add on design via CSS, then layer on client-side interactivity with JavaScript and Ajax-y goodness -- et voilĂ , you have a lovely, robust web experience.

Now, with some new or unknown browser, you hope for the best. But with IE6, we know what the issues are. If you're using PNGs with alpha-transparency in your design, you'll need an alternate solution. If you're adding horizontal margins to floats, you know you'll run in to a double-margin bug. If you're trying to clear floats within a parent, you know you need to set height. You'll need to plan for handling unsupported CSS selectors. And when it comes to JavaScript, you may not even know what to plan for (unless you spend most of your days working with JS).

But again, you're a web professional. You know your craft. You know this platform and its issues. (If you don't, you need to know your craft better. No, I don't buy "newness" to the field as an excuse -- this is still a present concern, so you need to understand it! Why not start with my CSS tips for IE6.) While some venting may be in order, I find the outright hatred for this browser (and other versions of IE, also bashed on a regular basis) to be downright unprofessional. Here's why:

  1. IE is still #1. While recent reports cite that its market share is shrinking, IE (all versions combined) is still the number one browser in use worldwide. The snide comments I've seen people make about IE (which I won't link to) often extend to remarks about IE users, which is just about the uncoolest thing I've witnessed. Respect the user, regardless of browser!
  2. IE6 use is shrinking. With the growing number of sites proactively messaging that support is being discontinued for IE6, its share should continue to shrink, which will lessen your burden over time. (You do have an actively managed browser support policy, to help you identify when you don't have to support it any longer, right?) Celebrate that people are upgrading instead of harping on the stragglers.
  3. Promote the best experience. Instead of complaining about having to make a fancy widget work perfectly on IE6, engage with the client/product/design team to explain how you can deliver the best possible experience to every user by honoring only what each browser is truly capable of, rather than let one browser hold you back. You now have plenty of real world examples (Google Apps, Digg, Facebook, YouTube, etc.) to back you up on this!
  4. Help prepare for the future. Remind those in decision-making roles that the more time you spend looking backwards at the old, the less time you have to prepare for the new. Since I haven't met a business owner (small, corporate, or otherwise) who doesn't like "new", this should snap them back to their primary focus of strategies that save money and provide for the future.
  5. Don't make yourself look like an ass. If I'm one of those poor souls still stuck supporting (or, perhaps worse, using) IE6 and I'm trying to hire someone, do you think I'm going to hire the person who's been hating on that browser all over the interwebs? Umm, no.

I know folks are going to jump in with all sorts of comments about me not thinking about Ajax-y web apps or super beautiful design-y sites. The thing is, I do work on and continue to lead a team which works on these types of sites and apps, and yes, we're supporting IE6 in all cases. No, it's not to pixel perfection. No, the functionality we build for a new browser isn't 100% replicated. But these sites aren't as far off as you might think* -- and in the cases where I'm using hacks or JS shims to get IE6 into compliance, I also have easy code management techniques for dropping support.

*In fact, very recently, after preparing business and design teams to accept far less functionality in IE6, my team delivered a cool animated design-y thing that worked perfectly in that browser! (It's not live yet, but I'll update this when it is.)

So take the time to inform and to educate about browser differences and support strategies. Enthusiastically suggest alternatives to your team. Track your browser metrics and get happy about those numbers changing. Say a small thank you to those at Microsoft who are working to improve IE. Get inside the IE6 user's head and present their story, not your own tale of woe. If you need help, ask for it.

Seriously, it'll save you from looking like an ass.

Kimberly Blessing

How To Get Your Conference or Training Request Approved

5 min read

I'm a strong believer in continual learning and keeping abreast of one's field, not only because I like learning so much, but also because I know that a lack of learning leads to stagnation, boredom, and poor quality work. Most of the developers I know are also passionate about learning, and so they, like me, are always seeking to learn and discuss and debate and code. Even though we primarily function in the online space, there's nothing like doing all of that learning and engaging face to face -- so we love to attend conferences and off-site training.

Web Forms Panel at SXSW by Ari Stiles

But conferences and training often mean travel and registration fees, and sometimes managers and executives can't see spending money on these things -- maybe they don't quite understand the importance of investing in their people, or maybe skill development doesn't seem necessary to support the business. In any case, it's up to you, the individual, to do some convincing. If you're in this situation, what can you?

Build a Strong Case

Research the event(s) you're interested in, gathering dates and locations, presenter bios, and comments from previous attendees. Craft a proposal which summarizes this research and presents a strong business case for you to attend. Will you learn skills relevant to an upcoming project? Will you build skills which could have made a recent project go more smoothly, and will also help in the future? Will you be exposed to industry or domain knowledge which will better serve your organization in some way? Link the event directly to your work. Summarize the costs, including registration, travel, and meals, and if you can, estimate the ROI.

Request Funding

I think this is the part that scares people -- asking for money. But let me share a true story: In the first few years of my career, I never asked my bosses for training or conference money. I went to the classes they offered to me, and otherwise I requested time off to attend conferences on my own dime. Then my boss discovered that I was doing this. While he was thrilled that I was taking the initiative, he was concerned. (Was I planning on leaving? Did I think that I wasn't worthy of the investment?) At that moment he made me realize that just because I get a paycheck from my employer doesn't mean that their obligation to me ends there. He made sure I got my vacation days comp'd and reimbursed the training expenses, and from then on, I went to my bosses (and in grad school, my department chair/dean) with my conference and training requests.

It's great if you happen to know how much budget your company/department/team has allocated for training, travel and events. But even if you don't, always start by asking for full funding of your training/conference registration and travel. If you're the only person going to the event, or if the event is somehow more associated with your role than someone else's, you probably have a stronger case for full funding. Be sure to ask early to ensure the maximum budget is available to you.

But what do you do if your request is denied?

Negotiate!

If you really want to attend that event, don't give up! There are a variety of ways to get there, if you're willing to work for it.

  • Try before you buy. If your organization is considering sending a group to an event or doing some on-site training, ask the boss to send you to assess the event or trainer before sending a whole team or bringing a trainer on-site. As a manager, I've made many a training and conference decision on the feedback of a few key individuals who were sent out to do reconnaissance. As a trainer, I've met many folks at conferences where we've discussed the needs of the organization and how I can help, which I think made it easier for the folks in charge to decide on hiring me later.
  • Strength in numbers. Contact the event organizers and find out how many people you'd need in order to get a group discount. Then rally a group of coworkers around the idea of attending, and convince the boss to send a group. Yes, more people makes it more expensive, but more people asking places greater emphasis on the need for someone to attend and bring the knowledge back to share.
  • Volunteer. If you're trying to go to a conference where volunteers are needed, you can usually get free admission if you volunteer. Or, if you have a large blog or Twitter following, ask the event organizers if they will give you credit for referring others to register for the event; that credit may cover part or all of your registration fee.
  • Ask for partial funding. If you can come up with part of the funding (like travel costs) then ask your boss to support you by paying the rest (like registration). Again, if you have a large following on your blog or Twitter, you may be able to solicit donations to help cover costs. In either case, share in the goodwill by promising to share what you learn afterwards.
  • Finally, if you must: send yourself. If you can afford to pay your own way, sell your boss on letting you go -- without having to use vacation time. At this point I'd say that you're going for your own personal development and you needn't commit to sharing what you learn when you return. However I'd also caution you to not be stingy -- if do share what you learn, you're making a better case to be funded in the future.

What other approaches have you used to get funding to attend conferences or training? Have you tried these techniques only to still be rejected? Please share in the comments so we can all learn.

Kimberly Blessing

Craftmanship can change the world

2 min read

Most mornings, I hit the Starbucks near work for a double tall non-fat no-whip cinnamon dolce latte. Yes, it's a mouthful to say. And apparently it's a really tough drink to get right... at least for the morning crew at this particular Starbucks. Despite seeing the same crew regularly, I almost always have to correct them on some aspect of my drink that they've screwed up (espresso shots sat too long, wrong milk, wrong size drink, scorched milk, etc.). When I do point something out, rather than get an apology, I'm usually given some excuse as to why it's not right. I'm starting to suspect that either they're making my drink wrong on purpose or they just don't care about their craft -- but in either case, they send a clear signal: a job's a job, and they don't care about theirs all that much.

Web developers can't have this attitude. We absolutely must care about our craft and continually ensure that our work is demonstrative of best practices (both industry and our own signature practices). Sloppy execution of our work leads to cross-browser problems, inaccessible features, confusing user interactions, and time lost refactoring code in the future. We don't get to give excuses to our customers -- if it doesn't work, end users don't use the site, and clients don't pay. Messy code shows that we don't care about leaving something our fellow developers can learn from, and it demonstrates that we don't care to take the time get our code right.

I shudder to think about the kind of code the baristas at the local Starbucks would write, were they developers. If only they could be more like so many of the awesome developers/craftspeople I know... then I'd be happily caffeinated each morning. And if fewer developers wrote code the way those baristas make drinks? Well, the Web might just explode from all that awesomeness.

Kimberly Blessing

Code Monkeys vs. Code Ninjas

3 min read

Software programmer Sara Chipps (yay! a woman!) has written an article titled Natural Programmers (Code Monkeys) vs. Career Programmers (Geeks in Suits). It's probably the best non-techie explanation of the behaviors, habits, and beliefs of the "natural programmer" that I've read -- and yes, I completely identified with much of what she wrote.

However, I have to take a step back and address an issue that I have with the two types of programmers she defines and the names she assigns to them.

First there's the "career programmer (geek in a suit)". These days I find that career programmers are not geeks, and they're definitely not in suits (always business casual!). I've found that they're in programming for the money; they learn enough to do their work -- perhaps well, maybe even to get to the point of being perceived as geeky. But I also find that these people lack a true passion for the craft of writing code. Sara suggests that the career programmer is more of a business person, concerned with cost effective solutions, but I'm not even sure that's true anymore. To me, this person's work is just a job, and if flipping burgers paid as much as programming, they might be doing that instead.

Like Sara, I fall into her other category of "natural programmer". But I am certainly not a code monkey -- I am a code ninja! (Actually, with a nickname like "Obi-Wan Kimberly", I'm probably a code jedi, but anyway...) I find the term "code monkey" to apply more to the previous category of programmer. Why? "Code monkey" implies that anyone can do what we do and that we work for bananas. "Code ninja", on the other hand, says that we're stealth and secretive, jumping out of the darkness when you least expect it. Our code takes you by surprise in its brilliance and our swiftness of execution is legendary. We could do no other job because we have trained for so long, perfecting our natural talent, and nothing else can satisfy our need for control over the systems we affect.

Sara closes her article with some OR logic about which type to hire, however I need to propose a more detailed and different solution. If you have only one programmer working for you, you probably don't want either of these types -- you need someone who really does fall into the gray area between the two extremes. (Yes, they are out there!) And if you have a team of programmers, you need a mix of these two types, and you need to put effort into getting them to communicate effectively with one another. Only then will you have both a killer team and killer code.

Kimberly Blessing

Web Development as a Craft... and Career

3 min read

Karl Dubost's recent post on the craft of HTML coincided with the launch of the first round of Web coding standards at work. Why did we need coding standards? Karl answers that for me in his first paragraph:

HTML is a practical art. In a professional context, it requires precise and extensive skills. As with many popular crafts, the vast majority of people do it on their own, but only a few do it for a living. The quality of products varies a lot.

When you have a team of developers working on a product, you need to set quality requirements... but to meet those requirements you also need to set the expectation that the developers will work in a consistent manner. Sometimes this can be achieved by having the team lead set the direction for the code by crafting templates and doing code reviews. But what happens as team members rotate on and off the project -- how do you retain the knowledge about the coding direction without taking time to bring each person up to speed? What happens as your development team grows to 10, 40, 100 people? This stuff doesn't scale without spelling out the rules and setting expectations... thus the need for coding standards.

But standards alone won't create consistency, of course. When Karl says that "HTML is a craft", he implies that there are techniques that one can only learn through study and practice. When practicing a craft, there are skill levels that reach into the realms of mastery that only few will ever meet. Out of that team of 10, 40, or 100 developers, how many will truly become those masters?

My experience over the past 8 years of working in industry has led me to find that only a few will ever commit themselves to the craft of Web development, and that worries me as a developer and as a manager. We all want job security, and dedicating oneself to excellence in a field implies we're in that field for the long haul. But what career path can a Web developer expect to have today? What opportunities will be available 5 years from know? There are many unknowns and I think that this may be one big reason I don't see more talented developers taking the plunge and committing themselves more fully to Web development as a craft and career.

Karl points to another problem: the "majority of people do it on their own, but only a few do it for a living", which to me implies that most people think anyone can be a Web developer (how many times have you heard someone state that their kid could build a better site?) and therefore they don't take the craft of Web development seriously. I've found that most Web developers who didn't emerge from computer programming backgrounds have serious complexes over whether or not they're "real" developers... and a lot of this is due to snarky computer programmers who put Web developers down because they make the same, stupid assumption that "anyone can do Web development". How is that encouraging to anyone looking at committing themselves to this work as their career? (Nevermind how irrational it is for a computer programmer to dismiss part of their larger discipline.) How is that encouraging to anyone who has hopes of using Web development as a basis for a career that could include programming in other languages?

So what's a developer to do? And what's a manager to do? I'll post my ideas at another time... right now, tell me yours.