I managed to code my way through Ada Lovelace Day and only noticed it today (belated tip of the hat to Michelle Bachler on being one of the winners of Mozilla's Jetpack 4 Learning Competition though!)  However it reminded me of some post-dev8d blog post discussions about how to attract more women to such events, and how as women we need to try and articulate what it is that might make a difference.

So this is an attempt of sorts. I am going to talk about communities more generally rather than events, with some of the following more relevant to real-life communities and other parts to online communities. As I mentioned in one of my comments, my own experience at dev8d itself was entirely positive, so this is much broader and not specific to dev8d at all.

I want to make it clear that I can only speak for myself and not for women more generally and that I don't feel any sense of entitlement here. Communities have the right to be whatever sort of community they want to be. I also can't claim to have always followed my own guidance without fail, although I aspire to!

So those caveats over, here is my advice if you are interested in making a community more welcoming to people like me:

Say hello to newcomers

At least in smaller groups, if you're an established member of a community, make an effort to go and say hello to anybody new, chat to them and introduce them to people. Sure if I'm new, I can go and say hello to folk myself, but it feels so much nicer if people come and say hello to me, and if I approach folk at random, I may not pick the right folk to get a good first impression. It's still rare enough that it'll make your community stand out. I remember it happening at the London Girl Geek Dinners, but I'm stretching my brain to think of other instances.

Thank and compliment people

This improves the atmosphere all round. You don't need to go over the top, but do actively look out for things that you can thank people for. If somebody's given a good presentation, tell them. Say nice things about other people generally.

Don't criticise in public

If you are intelligent, you are constantly spotting ways things that could be improved and analysing what exactly is wrong with things. It's an easy thing to slip into and I've certainly been guilty myself.

However, if like many tech communities, your community has a culture of 'competitive criticism', then I'm instantly turned off. It doesn't matter that it's not me that you are criticising, I'll notice and feel like I don't want to belong.

This is also about giving people the benefit of the doubt. A particular case in point here is code. Every programmer has written rubbish code at some point in their life. You can't tell from code the context in which it was written. You don't know whether somebody was given an impossible-to-meet deadline that day or had a family crisis. Plus we were all newbies once. If you don't look back on your old code and cringe, then it probably means that you're not learning anything.

Critical feedback can certainly be useful to people, but the right place for it is almost always privately. The fact that lots of communities pride themselves on their openess does not override this. There will be exceptions such as with open code review processes, in which case say what you need to say, but make sure you say it coming from a place of kindness rather than of irritation.

Another option if you want to give constructive criticism, is to either target it broadly rather than specifically, or to instead of criticising, praise the people who are doing the opposite. That I guess is what I'm trying to do here. It'd be very easy for me to pick on particular communities and examples and it would make this post far more colourful, but I don't want to do that.

Value people for more than just their technical prowess

Yes, I join communities because I want other people with whom to discuss technical things, but I want to belong to a community were relationships about more than just that, and people care in some small way about eachother beyond that. I can understand that this isn't the case with everybody, but for me I can't just divorce the technical from normal human relationships.

I think tied in with this is not worshipping certain members of a community as 'gurus'. I have to confess for me that as soon as community refers to people in it as gurus, I find the community immediately unattractive. I can't quite put my finger on why, but I think it's because it says that the community doesn't value anything other than the technical.

Give people a way to save face

Everybody has the occasional mental block. If somebody says something patently daft, there are ways to correct them in a face-saving way. Use them. Likewise if somebody asks a daft question, don't reply with questions such as 'why didn't you do such-and-such?' that make them look stupid. If somebody said they struggled over something, don't turn around and say that you did it in five minutes and can't see why it would take anybody any longer.

Don't ignore the behaviour of poisonous people

If the community you are in is stuck with somebody poisonous for whatever reason, then at least do your best to temper the effects. I remember the Moodle community once being fantastic when somebody ripped into something I posted in unnecessarily vitriolic language. Within the hour, I had various people defending me and apologising for that person's behaviour, and it really helped to neutralise the effect.

On a smaller scale, discourage snarkiness. Lots of clever people are snarky, but there are plenty of clever folk just are interesting to talk to that aren't. Choose their company instead.

Don't give 'RTFM' responses

Sure, I know how it feels to hear the same question for the 100th time. Yet if when I first glance at a community and see even a few RTFM responses, especially if the questions were reasonably intelligently phrased, it feels like somewhere that doesn't welcome questions. It doesn't take much more effort to politely give somebody a link to the documentation and if it happens repeatedly, it's probably a sign to look at the usability of your documentation.

By the way, I don't have any problem with super-concise answers online. I don't expect lots of smalltalk and niceties, but there's a difference between concise and making the person asking the question feel unwelcome.

I've been mildly intrigued by the amount of debate that the topic of learning styles seems to spark. There's a collection of links on the topic if you want to learn more. I expressed my opinion there that that's a danger that the idea of learning styles has a limiting effect on people in terms of discouraging folk from learning to learn in new ways. However I wanted to elaborate on the topic in a slightly more personal way. 

The most common type of learning style that you hear about is the split between visual, auditory and kinesthetic learners. I fall nearly as far as you can get into the visual category and as a result, I don't find the concept that learning styles implausible. However, another consequence is that I'm also not sure that most of the advice on how to adapt to different people's learning styles quite hits the mark.

I'd better describe a little bit about what it's like, for me at least, being an extreme visual person. The most obvious thing is that I have a limited form of photographic memory. I have to consciously use it and it doesn't have quite as many bytes storage as I'd like, but I've nonetheless got an extremely good visual memory, something that was incredibly useful in school exams. It came as quite a shock to me when I first discovered that some people spell words by going through each sound in turn, rather than just seeing the word flash up in front of them.

This is all compensated for by a complete lack of auditory memory. My scores on any tests of musical ability are about as low as you can get and I can't tell the difference between notes a semi-tone apart. I do like certain types of music, but I'm aware that it's not as important to me as it is to most people and I don't really notice its absence. Occasionally, I get it into my head to try to learn to be more musical, but it always turns out that I'm fundamentally just not interested enough to put the required effort in.

When it comes to learning things, the thing that is most obvious is that when people speak to me, I turn what they say into a visual buffer as they speak. This works perfectly fine for normal conversation. However as soon as the content gets complicated, this process slows down. If you're talking about something very technical to me and you see me glaze over, then I've hit a buffer overflow error. This translation process also takes mental energy with more complex content, which means my attention span will be a lot shorter than if I am reading and I can't think hard at the same time as listening.

This doesn't mean that I don't value spoken content. You can convey emotions in speech far more easily than in writing. In particular, in the case of teaching, that ability to convey enthusiasm is worth an enormous amount. People will also often use much more informal language in speech than in writing. I actually really like podcasts because I can replay them as many times as I like, whereas in real life I only get one shot at taking everything in. Even in more everyday life, you can have far richer spoken conversations than written, and the extra energy is takes is often well worth that.

It also doesn't mean I prefer non-verbal to verbal visual communication. A lot of things need the nuances of language and if somebody tries to communicate them without those nuances, it's just frustrating. Sure, don't spend time describing something that a picture could communicate better, but at the same time, realise that diagrams have their limits and that language was invented for a reason.

Likewise, give me a good spoken lecture over a badly written book any day. The differences that it makes for most things is small enough that other factors are far more important and trump any 'learning style' I may have.

So having said that, I think there are three main things that are indeed useful to me:

• for technical content and lists, it really helps me to have it written down as well as spoken
• when I glaze over and ask for something to be repeated, I'd much prefer it repeated not paraphrased - it's much easier to pick up where I got lost rather than start again from scratch
• in group discussions or lengthy discussions, especially about complex subjects, I occasionally need some quiet time by myself away from the discussion to digest everything

I realise that I also have a responsibility to figure out how to learn to live in a world where lots of information does come in an auditory form and will continue to do so. Any tips for this, beyond yet more sheer practice, are very welcome! 

This blog post is a write-up of the talk that I gave at dev8d.

When I was thinking about what to talk about at dev8d, I started to think about what I had actually learned since I'd started doing development. It's easy to list all the technical skills you've acquired and so on, but I realised looking back over old projects and cringing a lot, that one of the main things I've learned is to gradually eliminate mistakes that I've made. So this is going to be a list of some of the things that I've learned not to do. Coming from real life, it's both slightly esoteric and rather personal. So for example I learned about web security pretty early on in my web dev career and I don't think ever not used version control as a professional programmer, but I'm sure both would come high on a list of common web dev mistakes.

To give you a bit of context, I'm one of a team of four developers in a university department of around 100 people. Most of my projects are research projects but I've also worked on internal projects. Our projects are small with just one or two developers and we do absolutely everything from server and database administration through to user interface design, writing research papers and a good chunk of what might often be a project manager's job.

1. Not thinking about character encoding right from the start

If you want to make me break out in a cold sweat, mention character encoding to me. Normally I'm a fan of getting working software out there as quickly as possible and then adding functionality incrementally, but this is one place where it will come back to bite you if you don't spend just a tiny bit of time upfront. If you're a web developer, it's your job to understand character encodings and know how they affect your application.When I've psychologically recovered, I may even write something up on the topic. In the meantime, if nothing else, read this article by Joel Spolsky.

2. Not establishing upfront which browsers to support

You need to decide at the start of the project which browsers you are supporting. I include support for mobile devices here. If you don't have an established policy, then you'll end up having to support Netscape 0.3. I used to include browser resolutions here too, though that's become less of an issue. I've never met a non-technical person with opinions on which browsers to support, so let me give you a hint: if IE6 isn't a default browser at your institution, make certain it's not on the list.

3. Making bad choices of third-party code (and not using third-party code when I should have)

If I look back on old projects, an awful lot of the pain I have experienced has been associated with bad choices of 3rd party code, libraries and frameworks. However, this is a hard topic to give advice on since until you use something in anger, it's really hard to tell how good it is, by which point it's often too late. The most dangerous examples tend to be code with just about enough bugs or niggles to cause you lots of headaches, but not quite enough to justify switching to something else. All I can say is that when you start using other people's code, you need to put it throughs its paces quickly and be ruthless at the start about chaning your mind if there's the slightest hint it's not going to be right for you. Along similiar lines, you can waste a lot of time reinventing the wheel. In this day and age, you should have picked your favourite MVC framework. You shouldn't be writing your own search code and you should be using one of the great javascript libraries out there. Likewise for lots of other things. 

4. Underestimating the time for legal and acquiring domain names

Getting the terms and conditions and privacy policies for a site sorted can take a lot longer that you might imagine. It's not the job of lawyers to 'get' the web, and it might take quite a lot of iterations to get something both you and legal are happy with. Likewise, don't undestimate how long it can take to get a domain name sorted. I think from start to finish, getting a .ac.uk domain name took us about two months, including negotiating both our internal process and the JANET process. If a friend hadn't done me a big favour fast-tracking the process internally and giving me some useful tips, it might have taken much longer than that.

5. Not dotting i’s and crossing t’s

It's a bit mundane, but looking back on past projects, it really does pay not to be lazy. It's very tempting when you've got an exciting new feature working, not to put the time into proper error handling, form validation, handling edge cases properly and testing. But it's doing this that separates the  casual person who can get something working on the web from the good programmer. You need to take pride in your work and be constantly trying to make the best software that you possibly can.

6. Not clarifying expectations about admin interfaces and statistics

These are the two areas where I get the most what I call 'Can you just ...?' requests. I'm not sure about the psychology behind it, but there's a tendency for people to not think that changes to these areas require work or that an admin interface should let change absolutely anything on the site. So set expectations here early and get clarification. Statistics tends to be a big issue with research projects where people want data for evaluation or other research purposes and you often need to know early on what exactly you need to be recording even if there isn't a nice interface to view the data. My other big tip here is not leaving off the Google Analytics code after a major site redesign...

7. Asking permission to spend time on security, accessibility, backups and refactoring

There are some things that non-technical people just don't have the knowledge to make sensible judgements on, or will be tempted not to take seriously enough because they either aren't going to be the person feeling the consequences or haven't worked on enough web projects to make sensible judgements.  Part of your job to make the decisions on these. They are an overhead - you generally don't have anything to show for the work you've done, but you still need to just get on with them. At the same time, it's important to keep a level of visible progress on projects, to maintain trust, so you need to figure out how to fit these things in with 'visible progress' items.

8. Not checking the colour contrast of graphic design work

This is a little bit of a random mistake but it's something that's caused me quite a bit of a pain. For accessibility reasons you need to make sure that the colour contrast on websites is sufficient. If you're hiring a graphic designer for your site, most accessibility mistakes they make, you can fix quite easily yourself, but not this. As a general rule, unless you're hiring a designer who has made accessibility their speciality, you should be doing at least a minimal check of the acccessibility of their work yourself. There are great designers out there but there also ones who will promise a WCAG-compliant site and not deliver one.

9. Continually putting off usability testing

I don't know what it is about usability testing but it is so easy to put it off again and again. I guess it is 'important but not urgent'. It's one of those areas where the perfect is the enemy of the good, and especially in a university environment, it's easy to think that it needs to be treated as scientifically valid research, whereas what you're actually trying to do most of the time is look for the blindingly obvious ways to improve your site that you've missed because you're too close to it. For a side project, I was working on, we managed to do basic usability testing and get lots of really useful changes to make in less than 24 hours from deciding to do it, using a voice recorder and colleagues kindly volunteering their lunchbreak.

10. Underestimating the problem of spam

It's easy to imagine that spam doesn't exist or that captchas are all you need. Most of the spam on our site has clearly been generated by humans and it's embarrassing to have spam on prominent parts of the site. We've used Mollom which is probably great for blog comments but has given us too many false positives for the type of content we get on our site. Bottom line is that you need to decide how you're going to deal with spam before it becomes too big a problem. It's a frustrating thing to have to spend time, but it's part of making your site work well. 

11. Not protecting my programming time fiercely enough

Onto meta stuff now. If you're a developer, you don't need me to tell you that your productively isn't linearly related to the time you spend programming. You'll get a lot more done in a long stretch of uninterrupted time than in the same total duration divided into smaller intervals. There are two main threats to your programming time: interesting things and meetings.

Interesting things includes things like Twitter and e-mail and Hacker News. You absolutely need to turn off Twitter when you are coding. If currently have Twitter on when you are coding, you can think of this as a postiive thing: it means that you can become a better developer overnight just by turning off Twitter. If you work at a university like I do, there are also always lots of interesting seminars and other events going on. Sometimes you just need to be ruthless and not go to these even though they may sound fascinating.

The other problem is meetings. If you haven't read Paul Graham's article Maker's Schedule, Manager's Schedule then do. The way I've found to deal with meeting is to block out three days a week in my calendar for coding, and put all my meetings in the other two days. This means those days tend to be back-to-back with meetings but it's so much better than having them scattered throughout the week. I also try and do any admin jobs on those days. Occasionally, there will be something that absolutely has to happen one of the blocked out days, but as long as you only let that happen in emergencies then it's not too much of a disaster.

 12. Expecting non-developers to appreciate the work of a developer

When I worked at a tech company, you were respected for your technical prowess. If you work as a developer as a department where there are only a few developers, then that's not the case. Most people will never understand what you do or only in a limited way (and I include in that folk who have done the odd bit of coding here and there) and you have to accept that rather than try to explain what is hard about your job. You need to be doing development because you think it is worthwhile, not to get other people's appreciation.Counter-intuitively, once you start doing this, people will start appreciating you more. A quote I like is 'It is amazing what you can accomplish if you do not care who gets the credit' by Harry S Truman. Enjoy the privilege of being able to do the job that you do making things!

• Common Pitfalls of Building Social Web Applications and How to Avoid Them (and part 2 and part 3)
• Ten Rules for Writing Fiction
• Global Game Jam Achievements 
• How to split up the US
• The PhD problem
• A Writing Career Becomes Harder to Scale
• Accept Defeat: The Neuroscience of Screwing Up
• Platform Papers: Peter Brook
• How to Say Nothing in 500 Words
• Curiosity
• Why Marketing Research Makes Us Cringe
• gaping void's thoughts on blogging, 2010
• Virtual Mafia in Online Worlds
• How Tea and Shivers Make Short Stories 
• 101 Things I learned in interaction design school
• How Not to Write a PhD thesis 
• Walt Disney's Creative Organisation Chart
• The Real Reason Outsourcing Continues to Fail
• Guardian Camera Club videos 
• Questioning the Merit of Meritocracy and FLOSSPOLS, Sexism and Why Meritocracy Really Isn't
• Yawn
• Back Pain

Last week was dev8d, a conference run by JISC for developers. It's part conventional conference, part hackfest and part unconference in style. It's the sort of event where you have to get used to the feeling of missing out on stuff that you really want to go to. This is the second year it has been run and for me it felt quite different compared with last year where I think I only knew two other people attending beforehand, whereas I was much more in the thick of things this time.

For me this was the year of learning about mobile development and thanks to sessions by Phil Raymond and Sam Easterby-Smith, I'm pretty confident that, with a good dosage of reference material, I could write android and iphone apps. As well as plenty of very useful workshops and sessions, there was no shortage of cool stuff - from the arduino workshops to a self-replicating 3D printer that cost just £300 to make, and Ben O'Steen's great uses of a till printer:

I was also really impressed by the amount of great development that got done at the conference. There was a series of 'bounty challenges' for different categories such as best mobile app and best use of certain APIs. I was one of the judges for these and I don't think that the wiki page can quite convey quite how hard people worked. I'm particularly conscious of this as I started work on an idea for one of the challenges, but quickly realised that there was absolutely no way that I would finish it by the deadline unless I missed out on most of the conference. Hopefully it will still see the light of day, nonetheless

There were a few ideas I liked too. The first, appealing to my gamer instincts was 'developer bingo'. For this each person was given a slightly different grid with each square containing a different attribute that somebody might possess. You had to get a signature in each square from somebody possessing that attribute. This proved to be remarkably fun. It felt a bit like getting 'achievements' in games but in real life - those obscure geeky things that you'd done were suddenly something you could be proud of as you signed somebody's else sheet. Though admittedly I felt more excited that I appeared to be nearly the only person at the conference who had been eaten by grue, than by the fact that I had once spent a month of my life programming in TCL.

Another cunning idea that I will probably steal came from the folks behind e-prints. They offered a small reward for anybody who installed e-prints and got a 'hello world' plug-in working. Normally getting over the hurdle of installing something new is the real pain point, and once you've got past it, the programming is actually quite exciting and fun. Very clever idea.

I've put my photos from the event up on flickr.