Skip to main content

Kimberly Blessing

Kimberly Blessing

Web Developer Job Search: Interviewing Tips

4 min read

Obi-Wan Kimberly Blessing That's me conducting a speed interview during my Speed Interviews session at WebVisions 2010

I've interviewed a fair number of web developer candidates recently, and many have followed up with me afterwards for feedback. The number one question I get? What else should I have known or said during the interview to land the job?

This is a pretty easy question for me to answer, so let me give all of you some insight into what I'm looking for, as a hiring manager and interviewer:

  • Have an opinion. This doesn't sound too tricky, right? But in order to have an opinion, you have to have some knowledge and/or experience. For example, if I ask someone what their favorite browser is and why, it's going to be easy for the person to come back with a response -- likely based on what they use everyday. So why is it so difficult to tell me what doctype you prefer to code against, or whether you like or dislike reset CSS? To me, not having an answer means that you either don't know what these things are or don't have experience with them. Oh wait, you do have experience, but you don't want to voice an opinion that would be contrary to my own? Your interview is not a time to be timid! State your case and let me at least know that you know what you're talking about. I certainly won't judge you negatively for that.
  • Know some HTML5 and CSS3. There are lots of HTML5 jobs opening up, and even those employers that don't presently advertise the need will want these skills in the future. What, you haven't learned any HTML5 or CSS3? You're a professional, right? The excuse that your current job doesn't support you trying these things doesn't fly. There are plenty of websites and new publications out now to help you get up to speed in your own time. Plenty of shops are currently looking at switching to HTML5 and adding CSS3 features, and they want people who are able to contribute to these efforts from day one. Believe me, you don't need a lot of time to pick up some knowledge -- in just a few hours you can learn quite a lot!
  • Admit that you don't know. Sometimes interviewers will throw you curveball questions designed just to get you to say one thing -- "I don't know." Yes, it can be mean, but it does have a purpose: are you someone who will bullshit your way through an interview, and then possibly a job? Or are you willing to admit that you don't know something -- and in that case, are you the kind of person who shuts down, the kind who asks for help understanding, the kind who says "I'll go learn about that and follow up"? It should come as no surprise that I like the latter kind of person. But there's an even more practical reason for this: you may misunderstand a question, or the interviewer may not ask the question in a clear manner, or you may not be able to give a direct answer to a question but you could speak about something related. Saying you don't know, but that you're going to try to answer the question in the way you understand it, shows patience and diligence -- and may just expose some additional skills or knowledge. Don't hesitate to say it.

Want some more interviewing tips? Back in May, I ran a session at WebVisions called Speed Interviews. In it, I gave some tips to help the audience have a great interview experience, and then I conducted a number of 2-3 minute interviews on stage. It was a fun but challenging experience for me! My slides are online and I welcome your questions about interviewing. Good luck!

Looking to learn more about HTML5?

Kimberly Blessing

Epic Management Fails

6 min read

"who's able here to honestly say 'I have a great boss'?" two hands raised... 320 persons in the room... Via Daniel Glazman on Twitter

Although I always identify myself as a technologist, I've been managing people for a while and that is the primary focus of my full-time work. Managing people is an art, not a science. It's very hard work, and I didn't completely understand this before becoming a manager. Honestly, I don't think most people -- even managers -- understand how hard of a job this can be.

I think that I've become a pretty good manager -- with time and experience, with feedback and mentoring. There were times when I wasn't so great, though. In an attempt at radical honesty (hat tip to Erica O'Grady), here is a list of my epic management fails and what I've learned from them.

  • I tried to keep my hands in the code. Somewhere I once heard that coders who become managers and still try to write code only do so because they're arrogant and they end up sucking at both. While I don't agree 100% with that statement, I can agree that diverting focus from management responsibilities can have a negative impact on people and projects. As a manager I've gotten so deep into code that I've trampled on the responsibilities and goals of my direct reports. I've also made commitments to deliver production-ready code but then been so distracted by management responsibilities that I caused project deadlines to be missed. While attempting to code for production work isn't a good idea for managers, I think that coding for practice -- to keep one's skills in shape or to have experience with what the team is working on -- is definitely a good thing. A technical manager who can coach a team on both a personal and a technical level is a huge asset.
  • I didn't prepare for one-on-one meetings. One of the top priorities of a manager is meeting with direct reports on a regular basis to review expectations, set and track progress of goals, provide feedback, and coach for achievement. If you ignore this responsibility as a manager, you're not doing your job, period.* Over time, I've realized that some managers avoid these meetings because they're not prepared. I've certainly made the mistake of meeting with an individual without having an agenda, or without having deliverables ready. Ever had an awkward review with your boss? Chances are, it was awkward because they weren't prepared. I find that I have to practice difficult conversations before I walk in to a meeting, and I even like to rehearse giving feedback. When I'm nervous about a meeting, I know I'm not prepared. When I realize this, I'll try to reschedule the meeting or, worst case scenario, I'll admit to being unprepared and beg forgiveness.

    However, even if you conduct regular one-on-ones, you can do it very poorly. For example, I've had managers who've spent most of my one-on-one time talking to or emailing other people, just talking the entire time without listening, and even zoning out (staring at the ceiling, a piece of furniture). Other faux-pas include glaring at the person (or eye-rolling, laughing at inappropriate times), only giving negative feedback, never offering assistance, and never asking for feedback.

  • I wanted more (or less or something different) for someone. I'm an overachiever and I've always had a vision for what I could and should be doing in any job. I know that not everyone is this way, yet somehow this fact escaped me early in my management career. Some of my earliest supervisees were just doing a job, with no vision for themselves in the future, so I adopted a style of pushing my own vision for a person's career. I could pat myself on the back for the times in which this worked out, but there were times where this approach certainly backfired -- such as the strong generalist who I thought should specialize in an area they didn't care for, or the developer who I saw moving up the tech ladder when they wanted to move into management. Having a dialog not just about about an individual's current role and goals but also about their future is crucial. I like to do this at least twice a year, now, to ensure that my direct reports and I are on the same page.
  • I hired someone despite having concerns about their ability to do the job. This is a tough one to address in generalities, but I'll try. Any hiring decision should be backed up with evidence gathered through a rigorous interview process. Every new hire presents some level of risk, but you want to have primarily positive feelings about a hiring decision, not concerns. I have, on occasion, made hiring decisions based less on evidence and more on what I thought could be possible, given training, coaching, and mentoring. Sometimes it has worked out wonderfully. Other times it's been a painful experience for both the individual who was hired and for me. I do believe in giving people a chance, though, so I can't totally knock taking these risks. These days I try to be open about expectations prior to hiring and I reinforce those expectations once the individual walks in the door in regular one-on-ones. I don't usually out-and-out express my concerns, though -- this can kill a person's confidence! But if I must, I'll also express my support for the person and assume responsibility for making sure the right things are in place for the person to be successful.
  • I let my own issues get in the way of my responsibilities. Anyone who's followed me on Twitter for the past year has seen this one first hand. I started a new job last January and spent almost the entire year unhappy with my role, the work, and number of other things. I focused on the frustration, vented publicly, and let public response further fuel my discontent. All of this distraction consumed me; meanwhile my team languished. I began planning an exit strategy and engaged an awesome career coach who ended up reminding me of my strengths and reignited my passion for creating positive change. I set to work on creating a plan to address not only what was making me unhappy but also what I felt was missing from making our organization a powerhouse. I'm now executing on that plan and seeing small successes, which I hope to grow into larger successes this year.

Do you recognize any of these epic fails, either personally or in a manager you've worked with? Does your organization have a strong culture of coaching and mentoring managers to prevent against these and other fails? Share your story below for others to learn from. I'll share my epic wins later!

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

Preparing for Your Web Developer Job Search

6 min read

It's a new year, and perhaps you're a Web Developer looking for a new job. As a long-time Web Developer, here are three things I prepare when looking for work, whether it be freelance or full-time. And as a hiring manager, these are the same three things I'm looking for from the candidates who apply for work!

A Resume

I don't care whether I get one page or three pages from Web Developer candidates -- as a hiring manager, I do review the whole thing. Just don't fill it with fluff. I'm looking for dates of employment, size of company/product/team, type of work performed, and skills utilized. The general stuff which you do on a regular basis (emailing with Outlook, writing documentation in Word, slicing of assets in Photoshop or Fireworks, etc.) can just occupy a general skills section rather than be repeated for each job. Starting the resume with a technical skills overview gives me a quick snapshot of what you say you're capable of, and is a likely place for a hiring manager or recruiter to start with questions -- so don't list technical skills which you can't back up with experience! (Saying you have experience with HTML 5 when you haven't done much more than read a few blog posts is a sure-fire way of getting your resume nuked in a company's recruiting database, thus removing you from future consideration.)

While a beautifully formatted resume is always nice, don't agonize over it: using a Word resume template is just fine. Keep in mind that your resume doesn't always get through to the hiring manager in the format you sent -- so prepare a plain text version for textarea uploads. I know that typos sometimes make it in to a resume, and the occasional one will be forgiven or overlooked -- but do make sure to spell and grammar check everything! After all, if you don't QA your resume, how will a hiring manager know if you QA your code? (Need help? Read this and this.)

A Portfolio

To me, your resume is a formality of the hiring process, just metadata. Your portfolio is the real content which will be reviewed with a far more critical eye. The fact that portfolios aren't requested 100% of the time when seeking Web Developer positions only speaks to a hiring process which still treats the Web Developer role like a traditional programming job. Web Developers know otherwise, and if you truly want to be seen as a professional Web Developer, you'll have a portfolio at the ready. Do not slap something together on an as-needed basis -- proactively prepare a portfolio and send it even without request!

A portfolio should highlight your best work -- not all of your work. Don't include every project you've ever worked on. Choose three to five of your code samples which exemplify things like your coding style, ability to reconcile project requirements versus technical constraints, attempt to put HTML 5 into practice, etc. No one project will demonstrate all of those things, obviously, so make it clear why each project is included -- give a short narrative for each project to point someone to what you want them to focus on. Remember, you won't be the room when the portfolio is reviewed (unless it's brought up during an interview, which the portfolio will help you to score), so hand-hold the reader a bit.

I'm going to write a more in-depth post about what should go in a portfolio and how hiring teams review portfolios, so stay tuned.

A Web Site

May I vent for a moment? I can't believe how many Web Developers apply for jobs and don't have a Web site of their own. Where, pray tell, do all of these folks do their testing and noodling with servers and code? Why would you not want some online repository of your code? OK, venting done.

Yes, I do realize why some Web Developers don't have Web sites, but when you're searching for a new job, you need to have one. No, you don't need to have a blog with a lot of profound blabbering about technology, but yes, you should have an online copy of your resume and portfolio. When a recruiter or hiring manager Googles you (oh yes, we do!), you should want something more than your Facebook page to come up in the results.

I really think the most important reason for having the Web site is to host your portfolio. With an online portfolio, you can still highlight a few key projects while hosting copies of all of your code. This way, at a moment's notice, you can direct someone to (or, in an interview, walk someone through) a code solution that exemplifies a point you're discussing. Plus, you can preserve your code as it was when you finished it (delivered it, launched it) -- no longer will you have to make statements like, "I made the templates for the CMS but someone else maintains them now, plus the content folks don't know XHTML, so I don't know if the pages still validate." Worried about keeping copies of your code online? Just password-protect your site. If you give each recruiter a unique username/password to access your site, you'll be able to check your server logs to determine who's actually checked it out.


How will having all three of these things prepared and submitted help you in your job search? First and most importantly, it will get you in the door faster -- literally. If you have decent experience and great code samples which are hosted online, I'm more likely to tell a recruiter to just bring you in for an interview, rather than go through the preliminary phone screen. Why would you want to wait and let someone else get interviewed (and possibly get an offer) first?

If you're looking for your first Web Development job out of school, as a new career, or if you're switching from freelance to full-time employment, the portfolio can be especially helpful in leveling the playing field. If you're able to demonstrate strong skills but have little or no job experience, you're more likely to get an interview than someone with years of experience but no portfolio.

Of course, while you're in the midst of a job search, all of these tools are equally useful for getting short-term contract work, too!

What else do you think is crucial to a Web Development job search? Leave your thoughts in comments. If you have questions, I'm happy to answer those in the comments as well. Best of luck with your job search!

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

CSS & Troubleshooting IE6

3 min read

This past Saturday I gave my CSS Summit presentation on CSS & Troubleshooting IE6. Feel free to download the presentation slides to check out what I covered!

In the chat room, a number of questions and comments came up regarding the use of CSS hacks to address IE. I don't know how many people were in the camp of "all hacks are bad, all CSS must validate!" versus "who cares, use all the hacks you want", but I was put on the spot and asked for my two cents. I said something to the effect of, "Aiming to write CSS which validates is a great goal and perfectly achievable on your personal site, but when putting together a site for work or for a client, especially a large site, you may find that using hacks is easier to write and read, and will scale better over time -- so long as you plan a way out." I think that resonated with some of the folks in attendance, who have always felt that to honor the Web Standards cause, a developer always had to follow the best practices and have valid code at all times.

So, just to reiterate, no, you don't have to have valid markup and style sheets all of the time. In fact, there are times where you'll intentionally code something not valid -- whether it's the use of the target attribute for an anchor to make sure a link opens in a new tab/window, or whether it's the application of a hack in your CSS, so a future developer doesn't have to look through multiple CSS files to figure out what you did. I think this is perfectly acceptable, provided you execute the hack consciously. At almost all of the large companies where I've worked*, we've had to use hacks or deliver non-valid code. It's just a fact of life. It's what you know about your non-validating code, what you plan for**, that matters.

*At PayPal, we attempted to maintain separate IE6 and IE7 style sheets, called with conditional comments; this caused developers to have to write additional CSS in many cases, as the CSS architecture included a global CSS file, one or more product/flow/page-specific CSS files, and then these IE-specific CSS files. Due to the cascade, overwriting one style in the IE-specific CSS file sometimes meant writing additional lines of CSS to restore a style -- unless you could ensure that tweaking selectors in the other CSS files to make them more specific would be a better fix, without breaking any other pages... perhaps you see where I'm going with this? With over 100 developers potentially working on a bit of code, decoupling IE-specific styles created a nightmare situation, which inline hacks would have solved in a way that would have been easier to read and easier to maintain.

**On the other hand, at CIM, we have no coding standards (yet), so each developer appears to be addressing browser-specific issues in whatever way they want. I've seen multiple hacks used in our code and backing them out later is going to be a major challenge. When you do use hacks, make sure everyone on the project/working on the site uses the same ones!

So, with that, you have my permission to use hacks and write non-validating code -- just make sure you have a good reason for doing so, in case someone comes asking why you did it. 'Cause I won't back you up if you don't have solid justification!

Kimberly Blessing

The Seventh Grade

3 min read

While reading another story about the lack of diversity in STEM I was newly struck by the following statement, which I've heard in various forms over the years (emphasis mine):

"I think science is seen as a man's world by a lot of people," said Candy DeBerry, associate professor of biology at Washington & Jefferson College. "All the studies show that somewhere around sixth or seventh grade, girls start losing their interest in science but might be equally interested in it in the third or fourth grade."

For me, sixth grade was spent in elementary school. I had one teacher, unless you counted the music, art, or gym teachers. We almost always had one computer (a TRS-80 or an Apple II/IIe) in our classroom, which the teacher actually knew something about and which we kids would typically fight over using. Even the few kids who had computers at home (like me) wanted to use the computer at school, and we'd rush to finish an assignment so we could get in some computer time.

Seventh grade was the start of junior high school for me, and thus began the hourly switching of subjects, teachers, and classrooms. In none of these classrooms did we have a computer, and I don't ever remember my teachers mentioning computers. In junior high, the only computers I can recall were in the library, and they weren't the sort that you "played" with. In addition, all of the extra-curricular activities I was starting took away from potential computer time at home.

So when I keep hearing about this crucial sixth/seventh grade time period for young girls, I can't help but think back to my own experience around these grades. I didn't lose interest in computers (or science or math) in seventh grade, but I was certainly separated from them. As time went on, I had less time to pursue those interests myself, and in some cases I was discouraged from pursuing them.

Sure, times have changed, but as the old saying goes, "The more things change, the more they stay the same." Thus I'm inclined to assume that my experience may not really be that different from what kids experience today. Kids can't stay in the elementary school environment forever, but with middle schools now starting at fifth and sixth grade, are we pushing change -- not just academic and environmental, but social! -- on them too soon, thus potentially losing more future scientists, technologists, engineers, and mathematicians?

Kimberly Blessing

Working with the Not-So-Tech-Savvy

2 min read

Maybe it's the co-worker who sits next to you, or perhaps it's your boss. It could be a new client. And, invariably, someone in your family qualifies. That's right, they're the not-so-tech-savvy you have to deal with. How do you get them to understand you so that you can communicate and work together effectively?

Web Worker Daily provides 10 tips for working with the computer-illiterate, ranging from the obvious (avoid jargon and be patient) to smart strategies you may not have figured out yet (introduce new technologies gradually, talk results instead of process).

Two things that aren't mentioned in the article but deserve emphasis:

  1. Don't talk down to the person or treat them like an idiot. First of all, no one deserves being talked down to. Doing so is going to make you look bad and it will make future communications even more difficult. The person you're talking to could have a Ph.D. in some other field and simply may not have the background or experience to understand you without more explanation or context.
  2. Take the time to educate. I had a boss who was very results-oriented. When I was able to demonstrate the ROI of Web Standards in an effective way, he wanted to understand more. Over the course of a few months, I helped him learn some HTML and CSS, introduced him to our publishing tools, and gave him a copy of Zeldman's Designing with Web Standards, which we discussed at length. Didn't my boss turn around and become my biggest supporter and advocate to more senior management? And all it took was my investing in his education. Think of what educating a co-worker or client could do for you -- relieve you of that constant headache from one-off questions? Stop you from rolling your eyes after every interaction? Maybe the payoff seems small, but the mutual growth is worth it.