Depending on the individual, when a question arises that they don’t know the answer to, some people will resort to making something up. They may even become defensive and bluster when challenged or if additional questions occur.

I believe the correct response, and in fact the hallmark of a professional, is admitting that you don’t know and indicating you will find out. Importantly you need to then deliver on that promise.

But what about the alternative response? 

Ignoring the obvious unprofessionalism of it, at some point the person will be found out. When that happens, it will call into question everything they have said, including the things they do know about.

"When you refer to your coworkers as "the business" you degrade the responsibility of those people to treat IT like human beings"

by Jason Montague

How many times have you heard the people in a development team referred to as “resources” but then heard the developers refer to management and sales teams as “the business”? It seems to me that we all suffer from a need to make people outside of our group “faceless”, but at what cost.

Over the years I’ve heard developers use the term “the business” when talking about the people outside of the development team and as a manager, I constantly hear developers or employees referred to as “resources”. We even use the term “resource management”.

Now I understand that when planning a project, it’s simple to bundle people along with hardware and software into your resource list to determine what it will take to complete. However people aren’t interchangeable in the same way as other resources. You simply can’t locate another developer with the same or similar skills and expect them to be able to replace someone else without a significant cost to your productivity and success.

But what about developers using the term “the business”? Is this any better than a manager referring to developers as resources? No. By referring to the other people within the company as “the business” developers are creating “the enemy” that binds them together.They are forgetting that the success of a product spans many groups either side of the development team but that ultimately we are all working towards the same end goal, the successful use of our product by a customer.

In both cases this terminology may seem harmless enough but ultimately these are all people, with the usual raft of issues, strengths, prejudices and capabilities. By removing the humanity from the label, you are changing not only how you think of them, but also how you interact with them.

In the following examples I assume you have a reference to the editor (ed). This may be as simple as getting the activeEditor.

var ed = tinyMCE.activeEditor;

Unlike the insertion of content at the current cursor position, which simply uses the selection object

ed.selection.setContent("some content");

insertion of content into other parts of the document require the dom object.

Let’s start with inserting into the end of the document. Fortunately TinyMCE provides a dom api call to add an element. So, if we provide a reference to the document using ed.getBody(), we can insert a new element. For example

ed.dom.add(ed.getBody(), 'p', {}, “some content”);

inserts a new paragraph at the end of the document.

Inserting content at the beginning of the document however is a bit more tricky. In this case, there isn’t a helper, so we need to first create the new element, and then insert it before the first child of the document. Again, there is a dom helper to assist in the creation

var el = ed.dom.create('p', {id : 'test', 'class' : 'myclass'}, 'some content');

We then use the insertBefore() method providing a reference to the firstChild of the document.

ed.getBody().insertBefore(el, ed.getBody().firstChild);

"Mostly, I couldn’t work out what this blog was about. The older posts, while truthful, felt stuffy and unreal. Constructed because they were going public."

After neglecting my blog for most of last year I, like Charlotte, have asked myself what I want out of my blog.

When I started this blog back in 2007 the aim was to write about management as I progressed on my transition from developer to manager. It was also to provide others with an insight into me, be that employees or employers. This limited brief resulted in a very stifled and often "dry" set of articles.

In late 2010 I decided to add a bit of flavour with my "West End Wandering" posts. This provided me an avenue to write about my other interests, be it graffiti, coffee or food. The problem I found was that if I had a number of interesting ”West End” posts, they would “drown” out the more business related ones that the Hamstaa blog was about.

So what is it that the Hamstaa blog is about, and what do I want to get out of blogging?

For starters, the aim of the Hamstaa blog remains similar to it’s original brief. It contains articles on topics within my profession that I find interesting. They include comments on Agile, management, design and the art of creating software.

Blogging however is a way to express myself and my varied interests. It ensures I continue to improve my writing skills and provides me with a way to contribute back to the online community. With the relaunch of the blog, and the embedding of Hamstaa into a larger blog it gives me an opportunity to write about other interests I have while not detracting from the articles I have related to the software industry.

So welcome to the new Hamstaa blog.

From time to time people will ask questions about how to make TinyMCE do something that it's not really designed to do. This is mostly to output non-standard HTML and is usually due to the "client requirements". The most common one is the use of <BR> tags instead of <P> tags.

I'm not going to join into the argument of using <P> tags as a good friend and colleague posted a great round up of the importance of P tags already. What I'm interested in, is the way people respond both in terms of the initial question, and the followup responses.

From what I've seen, the response to these sorts of questions can occasionally be quite harsh and usually question "why" the person is even contemplating doing this. Now while I don't always agree with the tone of the responses, I can empathises, especially if they've had to answer the 100th question that has been addressed elsewhere, including the documentation.

The disturbing trend I've recently seen however is in the reaction of some people to this "criticism" or questioning. It appears people believe we should ignore the reason why someone is doing it, and simply answer the question. I tend to disagree.

As a developer I believe it's my duty to educate, as well as assist people. This includes both other developers and clients.

I believe that there are a lot of people out there who don't know any different with respect to the choices of output. By questioning why they are doing this and ideally providing the more acceptable alternative, the respondent is potentially educating them. Now it may be that the developer knows this already and is unable to educate their current client, but for others, they may now know an alternative. They still mightn't be able to change their clients mind this time around, but they will be better armed for future engagements.

The other day I watched a presentation by Jesse Desjardins called "You Suck at Powerpoint – 5 Shocking Design Mistakes You Need to Avoid".

Along with many useful design mistakes, he made an interesting observation that

Most experts say: An outstanding 1-hour presentation takes 30 hours or more of prep time.

— Slide 39

Shortly after I was doing a demo with our European sales rep. It was the first time we had demo'd together and during the post demo debrief our VP Sales, Tom Smith, observed that role playing the demo together could have smoothed out a few rough edges in our interaction. This was especially important given everyone on the call was remote from each other.

In the book "Great Demo", by Peter Cohan, he discusses the cost of a failed demo. As this can be quite significant, including loss of the sale, it pays to take the time to prepare properly.

Now this got me thinking – just how much time should we invest in preparing for a demo?

Obviously there’s the time spent setting up your demo environment, ensuring you have data/examples relevant to the customer and identifying the key features of your product that the prospect is really interested in. However there is also the time spent with the sale rep going over the "game plan" for this particular customer.

Now I normally work with our APAC sales rep and he and I have built a good report. Interestingly this was built initially face-to-face when he was on a sales trip to Australia. In the case of the demo with the European sales rep, while we had prep'd with the customer the technology to do the remote demo, we hadn't spent any time together going over how we would interact during the demo.

So, the time to prepare for a great demo can be quite significant and involve setting up the demo, and working through the approach with the sales rep. Of course, if you are doing a demo for the first time with a sales rep, then you need to invest even more time working out your interaction and how each of you prefers to work with the prospect during the demo.

At the end of the day, all of this effort is there to maximise your success in the demo and ensure you move even closer to closing the deal. So spending less time preparing could be lead to a failed demo.

I recently had a comment on my original post. In it the author indicated that "Competence" in their opinion was far better.

As they put it,

Capability always indicate the “possibility” that the person have to do something, but may be he can not really do it.
“I have the capability of speak in Chineese because i have all the neccesary for this, but i can not because i dont know chineese language”.

Competence is always the capability but shown in practice, This is not the ” possibility” its real, practical.

While I agree, someone who may be capable of performing a task may not really be able to do it, in the real world of IT, there are many situation where limiting yourself to just a set of competent skills may be detrimental. For example, it may mean you overlook an outstanding developer with the right development mindset but not a particular language, who would be able to take you and your business along with the changing landscape in IT.

The other problem I have with the comment is the example. I don't believe you can draw a parallel between a spoken language and a computer language. For one thing, the grammatical rules or "syntax" of a spoken language are significantly larger and more complex than a programming one. Now while I can speak, I therefore have the Capability to speak another language, I don't yet have that Competence. However, I am Competent in many computer languages, and therefore have the Capability to quickly and easily master a new one.

In the IT world, competence does play an important part, but I believe if you rely entirely on that alone in your decision to hire someone then you are selling yourself very short.