How to become a web developer.

Just do it.

I’ve been running a web development and consulting company, Red Queen Technologies, for 9 years. I have come from doing page templates to being called in to demonstrate agile development techniques for mid-size companies and running full multi-tiered architectural and systemic designs for sites.

I get questions all the time from friends and colleagues on how to start a web development company. The first thing I tell them is that you have to know how to code. I tell them to buy the HTML/XHTML/CSS for Dummies book, and jump in. If they’re too afraid to try to do the job that they want to manage others doing, they’re not suited to running their own dev company.

Just do it.

other day, I was in a boutique, chatting with two lovely friends of mine. These ladies are a bit older than me, by about 15 years. We all share an interest in haute couture; we were talking about Prada purses, I believe. These ladies are intelligent, beautiful, and entrepreneurial; one runs a successful clothing store, and the other is in real estate. When they asked me what I did and I told them, the realtor said “I could never do that. You are so much smarter than me.” This made me quite angry, honestly. There is a self-defeating voice inside many women that tells them that only very smart women can run their own tech companies, and since they’re not smart, they can’t do it. This woman was excusing herself from trying technology out of fear.

Just do it.

Get some server space, view page source for any web page, paste it into a text document, name it iwannacode.html, and upload it to your server
space. View it in your browser. Start fixing things. Learn.

Just do it.

Maintaining an empty inbox

The joke runs like this: When you have something you need done, give it to a busy person.

It’s very true, and for several reasons. Busy people have multiple projects, demands on their time, and responsibilities. They are trusted with increasing responsibility because they’ve proven themselves capable of handling tasks efficiently and competently. Part of being busy involves a deliberate strategy for time management. If you know how to manage your time, you accomplish more and better than those who do not.

Over the last several weeks, I’ve had a couple of (to me) strange responses to my emails concerning two different issues. The responses looked like this: “I’m sorry I took so long getting back to you; I am BURIED in email and my inbox keeps growing!” They’re not people I work with closely or may even need to talk to again, and I would have serious qualms about bringing them aboard any project I develop or manage in the future. It
also tells me that in whatever priority system they’re using, I fell off the radar.

Having an unmanageable inbox is a sign that you can’t manage multiple projects. I do not say an empty inbox: I said unmanageable. There are a lot of different strategies for coping with inbox overflow; go read every twentieth post at Lifehacker. People may choose to manage their inbox with tagging, folders, auto-reply…whatever your choice, being incapable of dealing with the mess is the same to me as if I’d walked into your office to assign you greater responsibility on a project, saw giant piles of paperwork everywhere, and decided that you obviously had enough to do without me adding more on top of your too-heavy burden.

If you reflect on that for a minute, you’ll ask yourself how many times you’ve given that excuse for not responding to an email rapidly or with the correct information. Has it cost you the
added responsibility that might have led to a promotion or better position?

I keep an utterly empty inbox. I counted when I started writing this post, and yesterday, May 24th, I had 89 email threads to deal with. That’s THREADS, not individual emails; they range from no-reply-needed all the way to one thread that required 22 responses from me yesterday. I use Remember The Milk; most people are familiar with that cloud service for GTD. One of my daily repeating tasks is ‘Zero the inbox.” At least once per day, I look at a totally empty inbox; this means that no one waits longer than 24 hours for a response of some kind from me. Some emails get archived and turned into tasks in RTM, some get archived and turned into Google Calendar events, some get trashed, and Mom’s emails that start with “FW:” get round-filed via Gmail filters. [Sorry, ma, but I warned you about the kittens and chain letters.
Love, your busy, heartless daughter.]

As someone who manages several projects, applications, servers, Scrum teams, and networks, I can’t think of any other way to stay busy that would ever work besides zeroing my inbox no less than once a day and more if I can. Do you have any ideas I can also implement?

UX Architecture: How do I design a user-friendly site?

One of the hardest things to do as a site architect and back end administrator is to think like a user. When I designed,, and this site, there were so many different user experiences that I went a little mad with flowcharts. I’ve architected other sites that have multiple enterprise-level uses and functions, but the real challenge is to switch back and forth in your mind between a consignment shop and a MMO and an advertising company–and what all those users need.

The secret is user stories. It’s a concept in agile development, and though everyone in the field of web development understands the need to think like a site user, this concept formalises UX/UI-based design. In essence, ask yourself what a user (both front-facing and behind-the-scenes) would want from a site like the one you’re developing.

1. “As a consignment
shop customer, I want to know what hours the shop is open and how to get there.”
2. “As a tech blog visitor, I want searchable site archives.”
3. “As an internet marketing company content writer, I want to be able to read and save drafts of my work before publishing it to the web.”

Ask yourself these questions. It’s how you figure out what people actually want from your site as opposed to what you THINK they SHOULD want from your site. This is how you avoid this trap:

People go to the website because they can't wait for the next alumni magazine, right? What do you mean, you want a campus map? One of our students made one as a CS class project back in '01! You can click to zoom and everything!

That’s the reason I did my personal website the way I did. Take a look: It’s simple as dirt, crawlable, scannable, and each of the QR codes is also an image map with links to the site the QR code advertises. Anyone at my home site is looking for my web portal; they get a visual experience, and can easily scan or hit links to the location they actually want to be at.

“As a visitor to, I want to find her blog/Facebook/Twitter/web companies/LinkedIn.”

That’s how user stories work; sometimes, talking through them gives you more information than you though possible to get without surveying users. Give it a shot.

A Senior Dev’s Manifesto

So I’m in the advanced Agile development certificate program at University of Washington.

By the time I’m done, I’ll have a mega-awesome Certified Scrum Developer certification, or some such nonsense. In all seriousness…what does that mean? As a dev and an OCD engineer slash scientist, my first impulse is to ask how interesting the problem is. As a lead, my job is to manage the people solving the problem. It’s sort of the curse of being good at something–sooner or later, you stop doing it, and start managing people who do it. Which is no fun.


As a senior dev/lead/PM/product owner, I have the power to solve larger problems than I was able to solve previously alone. I don’t know everything (regardless of how awesome I appear to be), and a SQL god with a truly talented UX/UI artist can enhance everything I do.

The real key, though, is to never lose your technical skills. Too often, I hear from PMs at
megacorps who have been rewarded for their skill and dedication by being removed from the job they were so good at in order to manage others. They tell me that they haven’t touched an IDE in years, and they barely know HTML3, much less 5. In the meantime, they’ve gotten very good at managing people, but have lost touch with the skills that made them great at the same jobs they’re now supervising.

So, when I’m asked what percentage of a senior dev’s time should be devoted to technical work, I hold forth with my opinion that if a senior dev is spending less than 30% of their time coding, they will lose the skills that make them great. I need to understand why my devs are choosing the solutions they are, and with aging skills, I’ll be left relying on their estimates of the time involved in a given sprint task. En masse, those estimates are likely to be wildly optimistic or violently pessimistic, with no real balance.

We have to make time to do the things we love and are great at; why
else would you take the job?