I get very tired of people looking for rockstar and ninja developers. I find it arrogant and actually detrimental to the whole market of development. We are professionals and we should take our jobs serious. We should also make sure that people who start in a company don’t have to deal with a terrible mess rather than being able to contribute immediately.

During my whole career I concentrated not on bringing myself into the centre and be the rockstar of a department but instead try damn hard to build sustainable teams and departments. This might have been a wrong decision in terms of money but seeing people grow and processes improve gives me a bigger kick than being admired as the guy who knows it all. There is a lot of quick glory in being a “Ninja” or a “Rockstar” but it is actually bad for the company. It is also a problem for your own career as you make people dependent on you rather than being able to grow and change to what you want to be and do in the future.

One of the big mistakes I was part of in the past was that I was part of a team of rockstars. When I joined the company the mandate was to get the best people in front end development and build the coolest products. I was proud as punch to be able to hire people I had a boatload of respect for and always wanted to work with. We all had the best ideas, we had the talent and we were hungry to prove ourselves.

What we didn’t have was the insight into how to make a large company care as much about what we do as we did. What we also didn’t have is the patience to understand that people who don’t want to immediately support you don’t do that out of spite but because they have other things to worry about. A big part of work is politics and that means that things don’t move as quickly as engineers want to. This is a human issue – take too many people to make a decision and it will take longer. On the other hand this decision can become a much better one as it has been scrutinised from several angles. Sadly enough in most cases when it comes to decisions made across departments of companies they don’t turn out better. The reason is that people don’t talk to another but follow their individual agendas instead. A lot of companies made process the goal and not the way towards the goal.

I am right now preparing my talk for this year’s Paris Web and it will revolve around the issue of getting listened to in the company and the market if you are a technical person. We can delude ourselves into thinking that building great products will get us fame and insight and be listened to but in the end it will be the product managers who’ll be remembered being the people who brought these products to life and not the people who built them.

The rockstar analogy

I think my ex-colleague JR Conlin hit the nail on the head:

Being a real rockstar gets you the fame, the sex and the drugs. However it also robs you of your privacy, forces you to repeat over and over again what you’ve done in the past and it typecasts you:

It also means that unless you are clever and you start your own label or production company or do your own merchandise a lot of people will make a lot of money on top of your talent and you only get a small share of that.

Rockstar fame is very fleeting – people who are on top now can be amazingly quickly forgotten tomorrow. Popularity is quite a tough thing to keep up and any slip-up you have will be all over the news and misinterpreted to become headlines. At first this aids your bad boy image but later on when you get older it just appears pathetic.

In essence being a rockstar means burning out quickly with a lot of glory but not much sustenance. And if you don’t plan cleverly for your future you’ll end up playing carnivals and open up shopping malls. I have a hard time to find the equivalent for an IT rock star.

For a company it means you have a employee that is hard to work with and that you need to keep happy all the time. A diva that is very much aware of his or her temporary fame and makes ridiculous demands (check the rider of some rock bands or talk to some roadies or people who work in theatres for tales of woe). You also concentrate on a single person and thus cause jealousy in the rest of your staff which means that they either under-perform, try to sabotage the rockstar or leave.

It also means that you have to sort out the troubles your rockstar gets into. Unmaintainable products that have the handwriting of one genius developer and no documentation on them are the IT equivalent of trashed hotel rooms. Headhunters calling your rockstar are the equivalent of the paparazzi. The only thing that is less likely to happen is getting into troubles with groupies.

In essence I see the demand of rockstars as a flattering way of companies to find somebody to quickly burn out and get a quick product out of that can be hyped. Nothing sustainable and especially nothing that hints that there will be a chance of a career for you in that environment. You start at the top of your game and you are expected to over-perform. Any request to get official support to improve will be seen as a weakness.

The Ninja analogy

People calling themselves $technology-ninja has only recently become popular. John Resig was one of the first with the JavaScript Ninja mailing list (which has become very silent as of late) and Nicole Sullivan had an interview published that started with the notion of her calling herself a Ninja.

You know what? I forgive both of them this – both John and Nicole consistently worked in silence and out of a sudden released a deadly cool technique or product before they went off again to hone their skills on the next attack. They never celebrated themselves much but instead promoted technologies to use in a professional environment and to get quick results. I am friends with them and I admire them for what they did and what they are about to do. I am confident they have more and more cool things up their sleeves in the future.

Lately, however, the Ninja analogy runs rampant with 4606 of them being available on LinkedIn:

A lot of the self proclaimed Ninja know their trade but it is actually interesting to see what they have forgotten when it comes to being a Ninja:

• Ninja attack silently and use the element of surprise
• Ninja disguise themselves to blend in
• Ninja are not seen or heard
• Ninja use a series of passwords and own languages to talk to another to be more effective

As a company, hiring a Ninja only makes sense if you want to disrupt your competition as the main tasks of Ninja are:

• Espionage – do you want to get rid of your secrets?
• Sabotage – hire a rockstar instead, he’ll make sure your products will decay quickly
• Assassination – not that applicable either.

When it comes to the JavaScript Ninja mailing list this made sense – a closed community with an own language that shares secrets with another and leaks them to the outside world to sabotage bad products and assassinate bad practices. And most people on it are rarely seen or heard (Dean Edwards and Stuart Langridge anyone?).

When it comes to people who call themselves a $technology-ninja the metaphor quickly crumbles to the same levels of “I am a social media expert” or “SEO wizard”.

Look for Sensei, Mercenaries and Padawan instead

If you really want to use an analogy (I don’t think we need to but hey, they sell like hotcakes) then I’d think you should focus on people who really will help your company:

• Mercenaries – in the middle ages we had mercenaries who roamed the land offering their strength and skill with their weapon to anyone who could afford them. They also were masters of marketing and changed their names to impressive things like Schwerdtfeger (“The one who sweeps with his sword”). A mercenary is a single minded person doing the job without any regrets, values or beliefs. They get the job done and move on. There is no loyalty beyond the contract and there are no demands beyond what was agreed on. They are independent and bring all the tools they need and are not interested in sharing. If you want to build a product to make some noise and you don’t expect it to be scalable or stay the way it is anyway then these are the people you want. Mercenaries are rockstars with their own label. Or think of Jayne Cobb in Firefly
• Sensei – are teachers, as simply as that. People who know their skills and know how to teach them to others. It ails me that in IT trainers are not paid as high as engineers. Being able to build something is one thing – being able to guide others to build the same so they don’t need you or your input in the future is a much less common skill. A good Sensei knows when to guide, when to explain, when to show and when to allow his students to fail and hurt themselves. It is strange but we learn more from making mistakes and avoiding them in the future than from doing things right. This should apply to companies, too. Lately when Google put Wave on the back burner a lot of people started writing sarcastic posts about it – just to learn after some research that there is no problem in failing when you analyse and salvage what was useful. A good Sensei is a developer with experience who knows what to keep away from his students and when to let them run free and show their skills. A good teacher makes himself not needed over time – for his students to become masters and then teachers themselves. Lead by example but leave space in your solutions for the creativity of your students and you will build working products that are ready for future improvements.
• Padawan – are young talents that show a massive proficiency in a certain subject matter (in the case of the Star Wars movies the force and being able to not scream every time some guy calls them “Annie”). They don’t need to be amazing at it but they should show adaptability, a hunger to improve and be open and ready to listen to advice – even if it seems not fascinating and shiny at that time. These are developers who want to build things – to create systems as a team and partner with people who are passionate about the other skills necessary to achieve the goal. They also should question authority and find their own way but be driven by achieving peace with their environment rather than disrupting it for the sake of disrupting it. They are developers that you can coach, mentor and form and partner with other skilled people to rely on another and share with another. They are also developers that when they get bored with what they do should get the chance to switch departments, roles and train them up to become leaders and Sensei

What do you think? Is it worth to let vanity and arrogance run our markets and frustrate people who want to learn rather than shine or should we concentrate on building an empowered work force rather than a privileged few?

I am currently in Prague, Czech Republic and gave a talk on re-use, professionalism and ease of development at the WebExpo.

Today I am going to have a longer chat with the people at the University about accessibility and creating a WAI-ARIA enabled framework for web applications.

For now, here are the slides of the WebExpo presentation and the audio recording of the talk. There was a video streaming, too, and it is up to Microsoft now to get this out as a recording.

Slides

Audio recording

You can download on being cleverly lazy as an MP3 - 36MB or see other audio options on archive.org

Notes / Transcript

Today I will talk about the fact that being cleverly lazy will make you a better developer.

First of all, I am Chris, a developer evangelist. This means I am a developer who evolved into a role where I can tell other developers how to have an easier life and tell my company what other things developers would want to make it even easier for them. I’ve written a developer evangelism handbook if you are interested in learning more about this role and why your company would benefit from having someone like me.

Cleverly lazy

Let me quickly define cleverly lazy here. Lazy is “I don’t want to do it” wheres cleverly lazy is “I don’t want to do that ever again so I do it right this time”. In development the difference between lazy and cleverly lazy is that lazy products do the job but are impossible to maintain whereas cleverly lazy products do the job, are easy to understand, extend and are built on a solid base.

Evolving the web

Our job as developers, designers, planners and organisers of web products is to evolve the web. We should have the chance to concentrate on building solutions that make people happy to use them rather than having to work out how one browser or another fails or how we convert data into a format the web technologies can display and understand.

In order to achieve this, we need to be free to do new things rather than worrying about the past.

The feature loop trap.

One problem is that as developers, we stand in our own way. The biggest trap that there is for developers is the feature loop:

• As developers we love to take a complex problem and tackle it. We love solving problems, that is why we become developers.
• We then normally and quite quickly find a simple solution to the complex problem.
• We then release the solution to the world and get feedback.
• This is where it goes pear-shaped. We get stuck in a feature adding and feedback loop until the elegant, easy and simple solution becomes a complex one again.
• Other developers will find our former simple solution and will think “hey, this is a complex problem, let’s make that easy!”

This keeps us from evolving as web developers. We don’t develop the web, we fill it up with solutions to the same problem.

My solution

The next issue is that as developers we love to find solutions ourselves and not use other people’s information. We appreciate other people’s work but in the end we only trust ourselves to come up with the best solution ever.

Short attention span

The problem with finding and building own solutions is that we tend to lose interest in them really fast and then leave them behind as we already another complex problem to simplify. This leads to lots of half-finished solutions on the web that don’t get any love any longer.

Unmaintained code is a security problem

All the code that is not getting any love stays unmaintained on the web and becomes a wonderful attack vector for new security threats or vulnerability exploits. Nothing beats being up-to-date when you want to build secure systems.

Things web developers must know to do their job.

Looking at our job as web developers, here are the things you have to be aware of to build things that people can use.

• The technologies involved
• How browsers deal with these technologies and how they fail to support them
• Security concerns and attack vectors
• Usability and accessibility of the product
• Internationalisation of our products
• Performance concerns
• Multiple platform support
• Flexibility of the interface

Browsers suck

Browsers are the bane of our existence as they are unpredictable, unreliable, there are hundreds of them (in various configurations) and they are not being updated by people out there.

That is a lot to know and deal with. The good news is that you don’t need to know all of it.

Good developers are like librarians

Librarians are great people. Instead of knowing everything that is in the library they know exactly where to find the information to solve a problem. As a cleverly lazy developer you should do the same.

Build on a solid foundation

Web development libraries came around for one simple purpose: Make our life as developers easier and our work as web developers predictable. They make browsers suck less and work around differences in browsers. They allow us to use web standards and get results instead of bugs to fix.

Build with components

If you build web applications and interfaces take a look around for what has already been created for you. Almost every library comes with widgets that are tested, work for everybody regardless of ability and can be changed to your needs. If you build your own component you are very likely indeed to forget some very necessary functionality that a collaborative product already had put in.

Use a good debugging environment

You can’t write great products without being able to know what is going on. Luckily enough nowadays we have great debugging tools like Firebug, Yahoo Profiler, JSLint and validators of all kind.

Plan for extensions

If you build a solution, plan a way so that people can extend it without having to change the central code. The central code should only have to change when there is a new browser or platform to be supported or there’s a security fix. Other than that people should be allowed to extend by listening for events or using other API hooks into your product.

Read, use and write documentation

If you build something, document it. There is no such thing as code that explains itself, that is a myth and an arrogant one at that.

Use the web

One of the really cleverly lazy things to do these days is to use the web to build your product rather than building your product and putting it on the web. Distribute your content on specialised systems like Flickr, YouTube, Delicious and LinkedIn and then put it together in a centralised CMS. That way your site will be easy to maintain and not vulnerable to a single point of failure.

Use APIs

To achieve this you need to use APIs. APIs can take a lot of your time to read up on and understand which is why it is a good plan to use YQL as an in-between to avoid going crazy on authentication and understanding what parameters go in and what data comes out.

An example

As an example, let’s take a look at a web site built solely from data on the web, using YQL and PHP.

Thanks!

Thank you, remember if you use what is out there you have time to be creative. I want us to write code most of our time, not to fix bugs.

Last Friday I went to sunny Southwark to go to IPC media and gave a brown-bag presentation. The topic: IPC wanted to have a chat about using libraries and why YUI might be a good choice.

I covered the fact that almost every web site out there is broken, that the reason for that first and foremost is bad communication in development teams and that users, developers and clients are all unhappy about it.

I explained that we develop for an unknown environment and that the development tools we have are just not good enough (albeit getting better every year).

I lamented the lack of documentation and handover procedures and that as developers we are inclined to build small solutions for one problem over and over again rather than contributing to a larger framework of solutions.

I pointed out that we tend to go from visual display to functionality rather than the other way around which is why we produce inaccessible and overly complicated products.

As solutions to these problems I showed how YUI is built and maintained, how its development tools allow you to build in a predictable fashion and that it does very well what every library out there should do for you: making web development easier and less random.

Slides

Here are the slides of the talk:

• PDF without notes – 9.5MB.
• PDF with notes – 9.5MB.

Audio

I also recorded the talk audio and you can download the recording at archive.org. Listening to the audio it sounds a bit of a rant, however it is not, I am just very passionate about the subject of professional web development and making the internet the #1 media :).

Notes

Professional Web Development Tools

Almost every web site is broken.

If you look around the web you will find that almost every site is broken in one way or another. This starts with small display glitches and ends with the sites being inaccessible or not working for users out there.

This is bad.

This is really bad. It hurts the web as a media. We re-invent the web every year as we just cannot seem to get it to work for us.

Unhappy visitors.

Broken web sites lead to unhappy visitors. The real problem there is that unhappy visitors do not complain to the people who could fix the issues. Most visitors either think they’ve done something wrong or just try to find another site that offers the same content and works. Both of these visitors will never come back. Other visitors complain but get stuck in help desks and never get their problem fixed as it is highly unlikely to ever reach the developers who could fix them.

Unhappy developers.

It doesn’t reach the developers as they are too busy with building new functionality and other sites. If we don’t build new things all the time we are neither happy developers nor seen as efficient employers. Fixing things isn’t sexy.

Unhappy clients.

This leads to unhappy clients. If a client realizes something doesn’t work on the site they paid good money for they want it fixed, regardless of how fringe the problem is and if it only shows up on their machine with their (most of the time outdated) setup.

Reasons

There are many reasons for the broken web, and nearly all of them are our own fault or based on misconceptions.

Lack of communication

Probably the biggest problem of web development is that the different parties involved do not talk to each other or know each others tasks. Developers think they know more than designers, designers think developers are not creative enough in using the arsenal at their hands and product managers see the brand more than the media and are oblivious to the technical boundaries and freedoms the internet gives us. Furthermore we all have our deadlines, deliveries and reports to make and write which takes up too much of our time.

Development environment

Web development has the most terrible and undefined environment ever. There are thousands of browser configurations and versions, each of them failing in different ways. There is a lack of good error reporting, difference in server configurations, connection issues… you name it. Our development is hit and miss and we fix more bugs than we write code.

Piecemeal development

As web developers we always try to build small solutions that solve a problem we have right now. We don’t really consider that all things on a site and across sites should work smoothly together. We’ve been disappointed so many times that we don’t really believe in that.

Lack of handover and documentation

The piecemeal development also means we don’t really document or hand something over. As the next developer is most likely as inclined as we are to build something new (as it surely will be much better than the crud we are asked to maintain) there is no point in that.

Interface to functionality

The biggest issue is that we start with the interface and the cool effect and then work our way down to what the user needs to achieve. We tend to forget very fast that not everybody has the same experience or could benefit from the great shiny interface we want to build. There is a skeleton under every web application and if that skeleton is weak it will break no matter how pretty and shiny we make it.

Solutions

There are solutions for all these issues.

Back to Basics

The first thing to think about is going back to basics when it comes to development. How does the web work, what is the most basic way of reaching a certain goal.

http://uk.tv.yahoo.com/#yeug-search – is a search box with several options. It used JavaScript to change the form’s action when any of the links were clicked.

Task: Define type of search, enter search term,submit form.

There was no need for JavaScript – all we needed was a radio button group and doing the forking on the backend. Notice that the fieldset, the options and the search button form a logical sentence. This is very important for accessibility.

TV channel programme

http://uk.tv.yahoo.com/#ytv-listings – the hardest interface to build as a web developer. Looks like a data table but could have shows that are one minute long! This would mean the table has to have 180 columns and use colspan on every table cell.

Analyse what data you display, and find the easiest way to show it.
Then make it look the way you want it to.

The information the data displays is much easier shown as headlines and ordered lists. CSS does the rest.

Build things people want and know how to use.

Here is where Yahoo offers their findings of user testing with real end users – http://developer.yahoo.com/ypatterns. There is nothing that can replace this knowledge and it is normally very expensive to come by. Before you even think about building an own interface to solve a problem users have to solve, give this a whirl.

Using technology for good

Flash video players are to date the best way to show video – http://uk.video.yahoo.com/. However, they have no reliable keyboard control. By providing buttons that work in HTML and control the video via an API you can make it accessible to all.

Aiming for excellence.

This is the new Yahoo currency converter. It is an amazing piece of web development. It works for all users (including screen reader users) and makes it easy to convert currencies.

Here we explained in detail how it works and the approach we took in developing it.

Removing browsers

The biggest step to professional development and keeping our sanity is to get the random element of browsers out of the equation. You cannot support all the browsers in the world and neither should you.

The graded browser support is a framework to define which browsers you test for and get the full experience. Unknown browsers only get what works in them – no JavaScript and even more obscure browsers get no CSS either.

Making browsers behave.

Libraries have one job: make browsers work. Support is the most random thing in our world as web developers therefore it makes a lot of sense to put all the dirty hacking and fixing of wrong browser behaviour into libraries. YUI is what Yahoo built and uses exactly for that purpose.

First issue is that every browser has an internal style sheet that renders HTML. All of them are different which makes it impossible to develop a reliable look and feel across browsers. YUI Reset works around that.

The same applies to typography. By using the YUI fonts CSS you reset the browser typography to allow you to define pixel sizes as percentages, thus having control and allowing users to resize the fonts.

The CSS grids allow you to create multi column layouts that work across all the A-level browsers easily and reliably. Source order independence comes free, too.

If you are lazy, you can also use the grids builder, define your layout, hit the show code button and get a copy + paste HTML document. The CSS will come from our CDN, which means it gets delivered to your customers from a computer near them geographically.

Doing one job at a time.

YUI does what we as developers would love to be able to do: concentrating on one task at a time. Other than “catch-all” libraries, YUI is cut up into several components, each doing one thing. You can mix and match them to your needs.

DOM access.

One of these components is YAHOO.util.Dom which gives you access to everything that happens in the DOM and convenience methods around the more annoying things the W3C DOM API has.

Using this I can write a script that shows the perfect YUI grid for every size of browser.

Predicting issues and fixing them.

One thing you should do as a developer is being paranoid about things breaking. You should be able to see what can go wrong and set traps for it not to happen.

position:fixed is sexy!

Positioning elements fixed can be very cool. Say for example you have a long document but you want to show the navigation next to regardless of how far down the page you scrolled. Another cool use would be a comments field that allows you to copy and paste quotes from the document.

Positioning the navigation as fixed makes it always visible on the page.

However if the browser window is too small there is no way to reach the elements below.

This small script fixes this problem. Using getRegion I can get the size of any element on the page and getViewportHeight() gives me the available space. If there is more space than needed, fixed can be applied.

Once fixed, let’s re-use.

Using the YUI components we build all kind of widgets based on the design patterns.

Using these free widgets you can re-build yahoo mail yourself.

Re-use means the ability to style differently.

All the widgets are style-able using CSS. You don’t need to know JavaScript or change their code to make them look completely different.

Document your work.

The YUI comes with extensive documentation, both created from comments in the code (JavaDoc style) and step-by-step tutorials. The system that generates the docs from the source code is also available as open source.

Learn by example.

YUI comes with over 300 copy and paste examples of how to use the different components and widgets. As this is how most developers work, we realized that this is a very important part of our success.

Allow for extension.

YUI uses custom events for all of this. This allows you to completely separate your own code from the library. Instead of having to call library methods or call your functions from the library all you need to do is to fire or subscribe to events.

Know what is happening.

Not every browser comes with a great debugging suite like FireBug or Opera’s Dragonfly. This is why Yahoo comes with a logging control.

The logger allows you to debug in any browser that the YUI works in. In addition to this all the YUI widgets and components are shipped as debug versions which report everything they do to the logger. This gives you full control over what is happening and when.

Monitor performance.

The YUI profiler allows you to monitor JavaScript performance – even of non-YUI scripts.

Test before you write.

The same applies to the YUI Test suite. Using this you can apply test-driven development methodologies to JavaScript development.

YUI 3

YUI3 is the new version of YUI, there are many speed and size improvements and we changed the way YUI works significantly to make it more secure, performant and allows you to write much less code to achieve your goal.

Performance

JavaScript performance is one thing, but in order to deliver really successful web sites there are many tricks to apply to create happy end users. The exceptional performance section of the Yahoo Developer Network has them all listed.

YSlow – a Firefox extension allows you to test any web site against these tips and rules and you get immediate, relevant information how to improve the performance of your site.

I’ve just finished watching Nate Koechley’s talk on professional Front-End Engineering on the YDN Theater:

You can download the m4v for your ipod and read the transcription on Eric Miraglia’s blog.

I’ve seen Nate give this talk before in a shorter version at @media in London, but this version has the whole story from what frontend engineering is, over technologies and methodologies to use and avoid up to a very compelling argument why it all matters.

So if you can spare an hour and a half (or chunk it over two workout sessions in the gym like I did) go and watch this video before you start flaming on mailing lists, forums or flat out tell people that it doesn’t matter when something is incomprehensible or works by magic – as long as it works.

Thanks Nate for a great encapsulation of the whole frontend matter in one video.

Today is Ada Lovelace day and alongside a lot of other people I pledged to write a blog post about a woman in technology I admire.

I’ve thought long and hard about who to write about on this occasion and I thought it not enough to talk about a single woman in this post. Instead I will give a list of women that inspired me and I had the privilege to work with in the past and now.

Jeri Ellsworth

First up is an inspiration of mine, Jeri Ellsworth a female alpha geek who built the Commodore One – a reverse engineered Commodore 64:

During development, it evolved into a re-configurable computer, a new class of computers where the chips do not have dedicated tasks any more. The two main chips carry out different tasks, depending on the needs of the program. The technology used is called FPGA - field programmable gate arrays. These chips can be programmed to do the tasks that the chips of the C-64 or other computers have done. It’s no emulation, but it’s a re-implementation of the chips that are no longer available since many years.

Try to out-geek that, boys!

Nicole Sullivan

I’ve talked earlier here about Nicole Sullivan and I have to repeat myself in saying that I am very inspired by her work with CSS and taking it to a new, technical level rather than getting lost in creating pretty things using this technology.

Working with Nicole is a joy as she is very outspoken, loves to stand her ground and bring up very good reasons for her course of action but also listens to you when you throw a spanner in her works. She presents very well at conference in English and French and in general is a very pragmatic and interesting person to have to throw ideas around.

Sophie Major

Sophie is my counterpart in the dynamic duo that is the Yahoo Developer Network outside the US. As such, she helped me get and do a job that is my passion and makes me not realize that I am working while I am clocking a lot of hours bringing Yahoo goodness to the people. I’ve covered Sophie in detail on the Ada Lovelace blog post on the Yahoo Developer Network blog so head on over there for more details.

Meltem Kogelbauer

I have worked with Meltem in my previous company, Netdecisions (now Agilisys) and seen her move from being a web developer to becoming a manager/architect in a short period of time. She is amazingly fast at taking up new technologies and ideas and validating them before coming up with a great new way of looking at them. What impresses me most about Meltem is that she is a fighter. When one of her absolutely adoring daughters died of cancer she took on the challenge and started a charity that tries to help parents in the same situation and raise awareness of how this special kind of cancer can be battled. You can find all the information about this charity and her sterling work in this area at Monty’s Corner.

Cindy Li

If you spend some time going to conferences about web design, you’ll be hard pushed not to come across Cindy Li sooner or later.

Cindy is not only a great designer but first and foremost a good spirit of the conference circuit. If there is some volunteering to do, if you need someone who knows everyone and has an open ear and friendly smile that is not glued on, Cindy is your woman.

A very pragmatic designer with a great eye for CI and wonderful humour (I has an open oAuth kitten) she partners with the right people to build great looking and working sites rather than trying to do everything herself. Thanks for being around, Cindy!

Emily Lewis

I’ve run into Emily for the first time at webmaster jam session in Atlanta last year which is almost a crime. This lady has been developing web sites for almost as long as I have and has a tremendous insight into what makes sense to use and what doesn’t.

When we met she was up in arms about forcing people to follow web standards or GTFO. A few chats later I managed to convince her to use this tremendous knowledge and charms for good and catch flies with honey rather than vinegar and now she’s getting more and more traction and just started writing a book explaining microformats for mortals. You go girl!

Niqui Merret

Niqui Merret is a fighter for accessibility in the world of flash development. This makes her amazing and rare enough but when you meet her and see the enthusiasm she puts into driving her cause forward there is no way you can avoid being dragged along.

Fresh in thought, outspoken a,d technically very knowledgable niqui represents a rare mediator between the fancy world of flash and the more down to earth world of web standards. Together these two worlds can create amazing products which is why having her around is priceless.

Cathy Ma

Cathy Ma arrived in the London office of Yahoo and took the place by storm. With a background of herding cats at Wikipedia her passion and deep knowledge lies in building, fostering and caring for online communities. Her positive attitude is contagious and not even the vast challenge of herding Yahoo groups and Answers made her despair.

As developers we always forget that large groups of users mean a lot of work and that ‘our community will moderate itself’ is largely a dream and far from reality. If you have bundles of positive energy like Cathy to rely on to tackle this job, you come out laughing.

Stephanie Troeth

From the first moment I met Stephanie Troeth I was mesmerized. Her dedication to make the web a better place for all, her focus on teaching good practices from the get-go and her work for the WaSP is admirable.

Furthermore, she does it all with a sweet and very calm and understanding disposition that I’d love to have from time to time. Stephanie is one of the unsung superstars of the web standards movement and has a lot of great things to teach us.

She is also one of the warmest and most friendly people out there, technically very savvy and good at explaining complex matters in ways that people understand. A mix that is hard to find, thank you for being around, Steph!

Denise Stephens

Denise Stephens is a wonderful example of someone who doesn’t take fate for granted but takes action to change things that seem immovable at first but mushroom into something wonderful if you take on the challenge.

Denise has MS and realized quickly that her life and surroundings are changing. However she was very unhappy with the current state of affairs and doesn’t agree that just because of your body having new needs that your flat should look like a hospital.

Therefore she started enabled by design, a self-help site for people with MS and a showcase for functional and pretty living aids. She’s been recently featured in the guardian
and ebd is going to be a great resource bridging the gap between product design and accessibility. And for that and the fact that she makes me feel terribly good when we meet for coffee I admire her.

Antonia Hyde

Antonia Hyde is a non-technical project manager who tries very hard to make the accessibility world understand the power of technology. She also pushes the envelope of the accessibility world by advocating for support of learning disabled users instead of thinking to cater primarily for blind users. Her wish-list of a video player for learning disabled users presented at Accessibility 2.0 last year inspired me to develop Easy YouTube and we’ve been working on more and more ideas like that over the following month. Antonia knows she is a mediator between people who need technical help and geeks that can give technical help and she does a great job doing that.

Kath Moonan

I love Lucy meets the full monty – that’s Kath Moonan. The visuals give a first clue, and as soon as the Liverpool accent and the lack of hindering filters kicks in you know this is a lady you can’t mess around with. Kath works for Abilitynet, organized the Ability2.0 conference and in general is a refreshingly outspoken specimen of the accessibility world.

Kath is not the most technical but once she gets excited about a solution there is no stopping her advocating it and telling others that their outdated solutions are for museums.

We need more forces of nature in accessibility, so thanks for being here, Kath!

Jenny Donnelly

Jenny is part of the Yahoo User Interface library and does things full of awesome like the data table and the data source utility. She is also an evangelist for the YUI and does a tremendous job advocating it to developers out there.

What I admire most about Jenny is her attention to detail and willingness to add changes to the things she developed. She is also very patient with code and data structures, something that drives me nuts as I am much more happy to build things that create interfaces and interactivity.

Jenny is also a force of nature when it comes to organizing company internal front-end meetings and conference, something I am very thankful for. It is great to have her as a part of the YUI team.

And there are many many more

This is just a small sample of the female techies I work with that make me love my job. I wrote all of this on the blackberry so I stayed brief. I am sure that the female numbers in tech are rising and I’d say it is high time for this. The more diversified our workplaces are the better our products will become.