As cheesy as it sounds, I'm going to start off with a definition ripped straight off Dictionary.com:

per·cep·tion

–noun

1. the act or faculty of apprehending by means of the senses or of the mind; cognition; understanding.
2. immediate or intuitive recognition or appreciation, as of moral, psychological, or aesthetic qualities; insight; intuition; discernment: an artist of rare perception.
3. the result or product of perceiving, as distinguished from the act of perceiving; percept.
4. Psychology. a single unified awareness derived from sensory processes while a stimulus is present.
5. Law. the taking into possession of rents, crops, profits, etc.

Take a moment to digest the meaning of the word. Can you see how subjective it is? One's perception varies greatly depending on the observer. The motivation of the observation is also going to skew how one is perceived. The relationship one has with the observer is also going to impact how that observer perceives you.

Finally, it's important to note that what was perceived and any point in time is not necessarily the same as what actually occurred.

Motivation for Writing

So why am I talking about this? Earlier this week, the team I am currently working with had its fortnightly iteration retrospective. Quite a few issues were raised. A few home truths were revealed. A few of the team members implied that there was a perception issue, in that what appeared to have happened in some cases is not actually what happened.

This whole issue of perception has come up on almost every job I have worked on. This time round it has motivated me to write about it as I feel that for some reason people don't really understand the core of the issue. Not only that, they fail to see that there is actually a great deal of value in learning how to manage it and use it as valuable feedback to improve yourself as a professional.

How are you Perceived?

The answer to this question will vary greatly depending on the situation, your relationship with those who are observing you and what lengths you go to in order to portray the right image.

People will look at you differently if you're a contractor compared to a permanent employee. Their expectations will be higher, and hence when you're being obvserved people will be a little more critical. The expectation is that you're there as a domain expert that is adding value directly proportional to the cost of the service that you provide. As a permanent, the expectation is that you'll do the job to a "sufficient" level, work "enough" hours and "care" enough to get things done... eventually.

There are many shades of grey within these two categories as well as between them. I won't be covering all of them, but I believe there are a few points which apply to all of them when it comes to have they are observed from the perspective of the man who is paying the bills (for example, the Project Manager).

How much time do you spend...

• ... reading and writing emails?
• ... on the phone?
• ... reading and writing blogs?
• ... talking about non-work related stuff?
• ... messing around with personal gadgets or laptops at work?
• ... going out for coffee?
• ... using some sort of instant messaging client and/or social network tools?
• ... actually at work, at your desk? (ie. do you get in late or leave early)?

Don't get me wrong here, everyone does a few of these things when at work, regardless of there position. The question is where to draw the line, to make sure you don't go too far.

Now compare these to how much time you spend...

• ... starting and/or participating in design discussions.
• ... at your desk actually doing the work you're there to do.
• ... helping others do the work they do.
• ... helper others improve the level of quality of their work.
• ... attempting to add value in areas you're not directly involved with.
• ... going above and beyond to highlight and rectify problem areas.

These are all time-based issues. There are others which relate to attitude as well. How about..?

• When participating in team discussions, stand-ups or retrospectives, how much do you get involved?
• What does your body language say about how you feel or what you're thinking about at any given time?
• Do you get involved in discussions that have nothing to do with you?
• When dealing with people who you consider to be bad at their job, or people who you either don't like or respect, does your tone of voice give away you feelings?
• Do you find yourself getting personal for any reason when discussing issues with other members of your team?
• Do you attempt to discuss things that you don't understand while attempting to make it sound like you're an expert in the matter?
• Do you attempt to abuse your position of power (if you have one) even if it's to the detriment of the project you're working on?
• Do you wear appropriate clothing to work?

There are so many more, but I won't list them all as it'd make this post even more boring

Don't underestimate how each of these things can make you look bad if you don't manage your percetpion properly. A few small things can have just as big an impact on how you are perceived as one big thing. This can be bad enough even when the observer is a friend, but it's substantially worse if the person isn't!

Skewed Perceptions

This is where it gets nasty. Skewed perceptions can have a drastic effect on the employer's view. Most of the time, the employer's view is made up of those from a selection of people including some which will work alongside you in the trenches every day. If one or more of those people have a reason to dislike you then you have to make extra effort to manage how you are viewed. The smallest things can be blown out of proportion in this situation.

People who have a reason to dislike you will make every little thing you do look worse than it actually is. A slightly delayed email response will "put them back a few hours". A broken build will cause "huge issues with the work they're doing". A controversial email thread will be considered "extremely offensive" and having a laugh with some co-workers will be seen as "highly distracting and obnoxious".

Bear this in mind while going about your daily work.

Managing Perception

Ultimately, the best way to manage perception is the most simplest way: do your job, and do it well! That's really what it boils down to. If you do your job while you're at work then by definition you're not wasting time. You're not on the phone, you're not reading blogs, and you're not wasting time at all because you're doing what you're paid to do. The only grey area here is email. There are always going to be a plethora of work-related emails, and it's important to manage those and respond to them in a timely manner. Just make sure you don't spend your day in front of *insert email client of choice*.

But let's say that for some reason you aren't doing your job for the full eight hours per day. This isn't an unrealistic scenario, because everyone has something else going on in their lives which can have an effect on them during working hours. What do you do then? How do you make sure that you're not unfairly perceived? Again, it's very simple. Here are some examples.

• Phone calls: Don't take personal calls during the day. If you have a wife/partner that you want to speak to then call them during lunch. Make sure that they only call you during lunch or when it's an absolute emergency. If you have some other high-priority thing going on (eg. you're buying a house and you have to make sure the solicitors are doing their job) then make sure that you inform your manager/workmates. Tell them that you're expecting to deal with this issue during the day and that you'll be making an effort to keep it to a minimum. This means that if you're on the phone, people won't be asking questions as to why. Also, when taking calls, do yourself a favour and move away from your desk. Your colleagues don't want to hear the conversation (especially if it involves sentences like "I love you baby. Kissy-wissy! Love you!"). Give your colleages the space they deserve and go outside or to a private room. But make sure you keep it short.
• Coffee: I can be bad for this one sometimes. In short, get your coffee before you go to work. Don't take trips out after arriving. This can apply to other things such as late breakfasts.
• Care-factor: So you're in a meeting and you're either pissed off because of something someone said, or you're just not interested. We've all been there right? Er... have we? Anyway, let's say we have. Sitting there looking very disinterested isn't going to do you any favours. Don't constantly look at your watch. Don't glare at people like a sourpuss. Don't check your phone every 60 seconds to see if something more interested has landed in your inbox or Twitter stream. Pay attention! Sit up. Contribute something. At least do your colleagues the justice of listening to them and see if you can add value somewhere.
• Passive-aggressive behaviour: This comes in so many forms. Via emails, via jokes, via general conversation. It's a bad thing to do. It can be as subtle as a comment like "You're the Lead now, it's your problem". Avoid the jibes. Deal with the situation in a professional manner instead of behaving like a petulant child.
• Personality clashes: Someone at work has an issue with you, or you have an issue with them. Rather than let things turn bad, nip it in the bud. Take the person to one side and have a constructive discussion with them. Find out what it is that pisses them off, and try to deal with it. Attempting to work alongside someone when the air not clear not only causes issues for the two of you but can also be very distracting for the rest of the team.
• Caring too much: The work means more to you than the other people you're working with. You care about quality, standards, managing costs and expectations and you make an effort to stay in touch with the world you work in. The fact that your colleagues aren't like you infuriates you. This becomes evident in everything you do purely because of the anger and/or dismissiveness that you display whenever you interact with them. This fits into the professionalism category. Deal with it like a professional. I'm not asking you to like them any more, nor to lower your standards in any way. I'm asking you to learn to work around them. There will always be people that you work with that will make you feel like this (especially if you work in the government or in enterprise software). Learn to manage it and deal with your anger.
• Proactivity: This is something that isn't only going to improve your perception but will ultimately make you a better professional. Demonstrate some forethought for the area you work in. Read up on things in your own time and share them with your colleagues when you get to work. Constantly review your work methods and see how you can improve. If you find a way of improving yourself, you can again share that with people, but make sure you emphasise that you got a lot of value of it first. Make an effort to preempt some issues and deal with them up front rather than putting them off. Try to look past today's work and see what's coming down the track. Don't just look at the current line of code, be aware of the bigger picture. Don't be constrained to your field. If you're a tester you can improve the life of a developer (and vice versa).
• Do your hours: While a bigger issue for contractors, this definitely applies to permies as well. It's simple: do your hours! You get paid to do around eight hours of work per day. Less if you're a government employee. Eight hours is not that difficult. Whether you like it or not, your hours will in some way be monitored, and the perception of you will change if you don't do what is expected. Getting to work earlier than other doesn't mean you have the right to do less hours. If you rock up earlier, yes you can leave earlier, but if you're taking a lot of time out for personal stuff or lunches, then you should make the effort to stay back longer and make up for the time you have lost.
• Punctuality: Get to work on time, especially if you're a contractor. Rocking up after 9am most days doesn't look good, especially if you leave before 5pm and take a full hour for lunch. Get to meetings on time. There's no excuse for tardiness and it makes you look very unprofessional while wasting other people's time.
• Deal with criticism/feedback: When people have the nerve to come to you and talk openly about issues, be open to them and don't get angry. Don't try and justify your position by pointing out the flaws in other people. Don't attempt to make it sound like you're no different to anybody else. Listen to what people are saying. Use that information to better yourself as a person and as a professional. The best thing to do is separate yourself from the rest by learning from what you hear.

Trying Too Hard

When the issue of perception raises its ugly head, most people attempt to solve the problem instantly. This cannot be done. Changing people's perception of you is something that takes a long time. It's not something that will happen within a day, a week, or even a month. Expect it to take quite a while.

Here are some sure signs that you're trying too hard:

• You email everyone every time you do something related to your job. You're attempting to demonstrate that you're doing your work, but all you achieve by doing this is annoying everyone. You don't need to email everyone all the time. Only when it's relevant should you make the effort. Don't add noise, just try to add signal.
• You get involved in discussions that are outside of your area of expertise. I don't think I need to elaborate here. (this post is a classic example ).
• You make a point of highlighting other people's faults.
• You take the time to add value to anything and everything you can, splattering your workplace with "look how good I am" propoganda.
• Including lots of people in email threads when they don't need to be.

Instead of putting effort into directly changing how people perceive you, the best thing to do is change the way you work. Focus on doing your job better.

By the way, please let me know if you know of any more signs!

Conclusion

Perception tends to be directly related to your quality of work, though it can sometimes be skewed by interpersonal issues. Managing how you're perceived is actually very simple. If you care about your job and you want to do well you'll find that the whole perception issue fades into the background.

If you're floating along in a job you don't like or with people you don't like, and you're not really giving it 100%, then chances are you going to face this problem sooner rather than later.

Step up. Improve yourself for your own benefit, and you'll find that the rest of the perception issues will go away.

Thoughts, feedback, abuse and cheap-shots are, as always, very welcome

"We're very happy with the work you've done for us as a contractor. We want to keep you on, but would like you to take a job as a permanent employee and continue to work on the project."

Once they've made this point, they then feel the need to harp on about the good points of becoming a permanent employee. Things such as job security, sick/annual leave and better hours tend to get mentioned. All of them are complete bullshit of course.

There is no such thing as job security. Sick and/or annual isn't enough to make up for the difference in pay. Hours tend to always be worse when you're working for the man, because you're expected to do whatever needs to be done regardless of the hours. This is worse if you're working on mission-critical stuff.

Now I have no aversion to doing my fair share of extra work and mission-critical stuff is way more interesting. I often enjoy it. What I don't enjoy is the expectation for me to give away my free time to my employer for no reward. I don't get extra time off in lieu. I don't get overtime pay. I don't get ownership of the software. I don't get to see the result of the extra effort I put in. I'm just expected to do it. In other situations I'd be happy to do it, but 999 times out of 1000, the situation isn't right.

I've even worked for companies in the past who expect you to give up a lot of your personal time even if there isn't anything critical that needs to be done. I was expected to write small applications and create other assets that the company could use in future projects. At first this seemed like it could be fun. But the cold hard reality was that all of the effort was totally wasted, because none of the things that were created ever got used.

As a contractor, the view from the perspective of the client is different, especially if you're on an hourly rate. Everything boils down to a financial cost. You're more likely to get a fair deal as a contractor than you are as a permy (at least here in the Brisbane market) because you're entitled to make them pay for the time and effort you put in.

I realise that this makes me sound rather mercenary. In all honesty, I'm not mercenary. I love technology. I love building software. I don't go to work just so that I can get paid. In many ways I would work for less pay if the conditions were right. Unfortunately, I am yet to come across a job where those conditions are right. I've certainly given it a shot in the past. I took a substantial pay-cut to work for Electronic Arts back in 2005 so that I could work on something that I really wanted to work on. I thoroughly enjoyed it. As far as the technology and the challenges are concerned, it's the most fun I've ever had at work. Unfortunately, the experience I had there led me to believe that the lifestyle isn't sustainable (at least not for me and my family).

Would I do the same again for another job? Definitely. But the only company I would do it for would be Basho and my Erlang-fu is not yet up to scratch so I wouldn't be considered. Outside of Basho I'm not aware of any other company or work that excites me as much. So for now I will probably remain a contractor, and try to move around and add as much value as I can on a variety of projects, keeping up to speed on many different types of technology.

So if you're reading this, give me a few good reasons as to why permanent work is better than contract work. Why should I consider it? Would you consider it? If you're a permy, are you looking to go contracting, and why?

Feedback and comments are appreciated

This assumption was proved false a few days ago when I received an email about my Trac/Mercurial/SSH post not rendering properly in someone else's browser. Dammit!

So this time I actually did a bit of research by delving into the log files (yes, I know.. genius isn't it!) and determined that there was indeed a problem. Thankfully it was fairly simple to resolve. For some reason the fastcgi instances were failing to function periodically when attempting to access a folder on disk. In short, some of the temp folders were owned by the right user, and some of them weren't. After modifying the ownership of the appropriate folders, everything seems to be running nicely.

Yet more proof that the admin is an idiot.

If after I post this you notice any truncation at all across the site, please let me know! Cheers!

For some reason, it's a very common practice for those people who don't have expertise in a certain field to make decisions for people working in that field. The best example I can think of off the top of my head is the answer to the question: "Which technology should we use?"

Let me take a step back in time for a moment.

I applied for a job with a certain company (which shall remain nameless) that was looking for a number of C#/.NET developers of a certain level of experience. After confirming an interview date and time, I turned up to find myself facing a panel of 3 interviewers. One of those people held a technical position, though I found out later that the position he held was self-appointed and certainly not an indication of the person's level of technical knowledge or expertise. The other two were in non-technical positions.

During the interview we had the usual discussions and questions around technial knowledge, depth of understanding of certain areas of the .NET framework, views and approaches to dealing with people in teams, agile experience, etc. It all went very well. At the end of the interview I was given my chance to ask a few questions. The main one I wanted to ask was "Why did you decide to use .NET for this project?"

For the record, the previous version of the system was written using an older Microsoft technology stack. The decision had been made to go with .NET for this new version. Can you see the correlation?

The answer was quite stunning. The only reason the project was using .NET was because the previous version was a Microsoft-based solution.

The first thing I thought was "surely that can't be it?". As a matter of fact, that wasn't the only reason for it, but it was the main reason. The decision wasn't made by a technical person, it was made by someone in upper management.

Scary huh!?

In my personal opinion, there is one particular technology that I think would have done a much better job of solving this particular problem, and it's not a Microsoft solution. It's not a Sun solution, or any other mainstream option for that matter. In my view, Erlang would have been perfect.

I don't think that a company like that would have ever even considered Erlang as a viable option. Mainly for two reasons. The first is that the amount of skilled Erlang developers available on the East Coast of Australia is extremely small. The second is fear of the unknown/non-mainstream tech. That is, companies like to go with what other companies are going with.

The crazy thing about this scenario is that management go to market to hire people who are domain experts, and then proceed to tell them which technologies to use. Surely you would be better off hiring people to know how to solve problem X really well, and then listen to what they have to say about the technology stack that should be put in place? No, not in this industry. Probably not in my lifetime either!

So if you're a non-tech person leading a team of techies, please PLEASE listen to what they have to say. Ask them what they think is the right approach and the right toolset. Don't take control of the technical decisions. Let them do what you hired them to do: Solve the problem, and use the right tool for the job. If they don't know the answer, or the answer is always the same, then you've got the wrong developers.

Thanks for listening

I can thank Gabrielle Lana for this discovery, as it was his attempt at one of the katas that got me into it. He's also the reason I looked into Katacasts, which are simply screencasted recordings of people attempting to solve Code Katas.

This post is about my first Katacast, capturing my attempt at Code Kata #9 using Erlang and VIM with Rake as my build system. I've put the video up on Vimeo for the world to see/share. It's also embedded below for your convenience.

Before watching, I'd like to point out a few things about the video, and things that I have learned from the experience:

• I captured the video on my Linux Mint install. For some reason, capturing quality video in Linux is proving to be a bit of a pain for me. As a result, the video quality isn't that great. This partly due to the compression of the video, and partly due to the software failing to pick up some screen updates.
• I tried really hard to add a backing sound-track but all of my efforts failed in one way or another. If I did manage to get one to work it was either WAY too big (ie. > 1GB in size) or the quality was absolutely terrible.
• There were points during the process where I had to alt-tab out to a browser to do a bit of research on something that I didn't know (such as an Erlang syntax quirk). This resulted in a few points where I don't appear to be doing anything. In future, I'll remember to hit pause on the recording when this happens.
• I captured it in a non-standard resolution. I'm not sure if that's going to make it look bad or not. Feedback here is appreciated. I think in future I'll capture at a 800x600 resolution.
• This video is best viewed in full-screen mode.

So please excuse the lack of quality in this first Katacast. I'll be sure to improve when I next create one. That being said, on with the show!

As always, feedback/criticism/etc is greatly appreciated. I'd love to hear what you guys do and use to capture and edit your screencasts, particularly in Linux.

It's safe to admit that you just don't know! In fact, it's better if you do admit it. Pretending that you know what you don't not only makes you the butt of the jokes, but you end up being detrimental to the success of the project.

Stop trying to be a know-all. Let go of the idea that you need to be the one to approve everything. Take a step back and be honest to yourself and the rest of the team. You aren't a one-man-band. You aren't the technical guru that you think you are. You aren't even a specialist in a particular area, let alone a jack-of-all-trades.

When you attempt to do something and you fail, stop trying to make it sound like you haven't failed. Please stop yourself from trying to turn your wrong into a right. Everyone fails in one way or another during their working life, and as much as you don't want to admit it, it does include you.

Change your attitude. You'll be doing yourself a favour.

And while you're at it, how about you get up to speed with the technology you're working with. Then you won't have to pretend, and the likelihood of you failing will start to decrease.

Thanks for listening.

Remember, it's not about you, it's all about the software.

I know, this kind of thing happens thousands of times a day. Some arbitrary geek decided to build the next killer app and expects to make a crapload of cash out of it. While that would be nice, the ultimate goal isn't the cash. The goal for me is to build something that gets used, and for me to begin to master an area of technology that I've had a quiet passion for for a long period of time now.

My plan is simple. While learning the technologies that I will be using I'll be building another application and blogging about it so that all of you can learn with me. Meanwhile, I shall use my learnings to build this other application at the same time.

The final result should be a series of posts which help other people learn the technology stack, give better coverage and visibility to languages and technologies that a lot of the geek world doesn't know about (and really should!), and for me to carve myself a bit of a niche here on the East coast of Ozland. I am hoping to be able to consult my services out to other businesses as a result.

For those that are interested in following along, here is the full tech stack and toolset that I'll be using:

• Erlang - A fantastic cross-platform functional programming language that has some amazing features.
• Webmachine - A HTTP toolkit which sits on top of Mochiweb that makes it easy to build well-behaved HTTP applications.
• Nitrogen - An Erlang-based framework that makes it easy to build websites.
• Riak or CouchDB - Both of these amazing pieces of tech are potential candidates for the back-end storage. I'm not yet sure which one I'll go with.
• jQuery - A great JavaScript library for the front-end.
• VIM - My favourite text editor
• Xubuntu - Ubuntu Karmic Koala with XFCE as the window manager.
• Mercurial - My favourite version control system.
• Trac - A project tracking tool.
• VirtualBox - My choice for virtualisation. I tend to run Windows 7 as my primary OS, so most of my dev will be in a VM. When I get my desktop machine back up and running (with all three monitors!) it'll most likely multiboot Win 7 and Xubuntu.
• Google Wave - I'll be using this for communications with some really switched on people in the Erlang community who have kindly offered to help me with questions and whatnot specific to some of the areas of tech I've mentioned above.

During the course of my blogging/learning I'll be focussing on Webmachine, Riak/CouchDB, Erlang and Nitrogen. All the other tools will probably get mentioned along the way, but the primary goal is to focus on these things.

I'm really excited! I'm currently in the process of documenting my goals and the design for the main application. Once that's done, I'll get started with the fun stuff. I've got a lot to do and it should be a fun ride. I hope you enjoy following along!

After a year or so of serving up content, it managed to handle a couple of Reddit submissions without much of a bother! I was suitably impressed.

But there comes a time when you can't help but wonder what else is out there. For me, that time came a little while ago when I boosted the number of plug-ins that I use on this site. Litespeed took longer to serve pages up and I couldn't help but notice it. I'm certainly not blaming Litespeed, because the obvious solution is to remove the plug-ins! But I didn't want to do that as those plug-ins provide features for this site that I don't want to lose. So my quest to find another web server began.

Then recently I started researching ideas for developing software in Erlang. I've been reading up on the language for quite a while and I'm getting to the point where I intend to build something. My first effort is going to be a web application that uses Mochiweb, Webmachine and CouchDB. I know that at some point I'm going to want to have this thing run on the web so that other people can play with it and that would mean that I would have to have a web server available that could also route requests to my Erlang server. Of course, I want it to be quick.

So after a bit of deliberation and research, I followed the footsteps of some big players and ended up installing Nginx (which I believe is pronounced "Engine-X"). I kid you not, this thing is amazing! I'm not going to give a full review of it here because I haven't used it enough to know how good it is. But the speed-up for this site in particular is obvious (at least for me).

My mate Dan's site absolutely flies!

On the whole, Nginx gets a huge thumbs up from me thus far. If you're looking for a speedy web server that can do reverse proxying, dish up static content like a maniac and handle forwarding of requests to a variety of other servers then you should seriously consider taking a look at Nginx.

Thank you, Igor!

• Introduction to Functional Programming - by Brad Clow
• Haskell 101 - by me!

There are still spots available if you're keen to come along. It should be fun!

I'm always up for some public scrutiny, so come along and bring your rotten tomatoes.

If you can't make it, I'll post the slides for the talk on this site, and on Meetup.com, when the event has finished so you can see what was covered. Feel free to ping me or ask questions.

Update 19th Aug '09
The talk seemed to go quite well. I had to motor through the material quite quickly due to the late start, but on the whole I think it was well received. I haven't had any negative feedback so far

Slides/content are now up for grabs!

Communities are arguably the life blood of technology. Without a good community the likelihood of the technology catching on is drastically reduced. Those communities which lack individuals that are happy to put time and effort in to help get others up to speed tend to stagnate. Any community which involves members that are abrasive, rude and downright offensive is destined to suffer long term.

The level of suffering will vary depending on quite a few things. Those things include existing user base, the age of the technology and the number of different ways that a given n00b can get information about that technology.

IRC is a very common and popular means for members of communities to interact. It provides a real-time element that you don't get with blogs, forums and other media like Twitter. It satisfies every geek's desire to get the answer and get it now. Experiencing support in real time via IRC can be extremely helpful and rewarding. It can work wonders for the popularity and image of the community and the technology itself.

If you're interested in seeing some active and extremely helpful communities, you should take a look at #haskell and #mercurial. Both of these channels are generally very active. The people that spend time in them are both helpful and friendly. Both of these channels indicate to me that there is a very healthy and vibrant community behind each of these pieces of technology.

Unfortunately, this kind of communication also has a downside. The real-time nature of IRC allows people to vent anger on newcomers without any means of moderation. The net result of this is that other individuals become to scared to offer their view or provide support for fear of receiving the same treatment. This goes for members with any level of skill or knowledge. There are some community channels out there containing hundreds of people, and yet there is no conversation. When questions are asked, nobody responds.

After my recent experience in a channel that fist this description, it's easy to see why. In less that half an hour of asking for clarification on certain points, I received a barrage of abuse which, in my view, was totally unjustified.

But let's say, for the sake of argument, that it was justified. That for some reason I annoyed someone in such a way that bombarding me with many 4 and 5-letter expletives was acceptable. Do you think that it paints a good picture of the community?

I think not.

In less than half an hour I went from excited to deflated. I lost interest in the piece of technology and lost faith in the community around it. Was my response justified or understandable?

I'm not sure about the answer to this

I feel that it's the job of the community to moderate other members of their community. If people get abusive then other members should step in and prevent it. In my case this wasn't possible due to the fact that the person in question was abusing me via a private chat so that the channel couldn't witness his venting. I'm guessing this wasn't the first time that he's done this to someone, nor will it be the last. I wonder how many others have suffered the same fate? If the silence of the channel is anything to go by, I'm guessing quite a few.

I guess what I'm trying to say here is this: don't underestimate the value and importance of your community. It's one of the most frequented faces of your technology. If it's bitter, unwelcoming and unsupportive, you will not only lose valuable newcomers who come looking for information and support, you will also lose future users due to the poor reputation. Ultimately, your tech will suffer.

If you're part of a community, do your bit to police it. Help those who need help. Stop those people who are abusive.

.. and if you don't have anything nice to say, then don't say anything at all!