jamesladdcode.com

I was inspired by this post by Kent Beck to write a fan letter to Redline Smalltalk, written in the voice of a deliriously satisfied user. This is an excellent way of articulating a vision.

Dear Redline Smalltalk,

I have been using Redline Smalltalk at work and in personal projects for a while now and I just had to let you know what a joy it is to use and how productive I am with it.

My work situation means I have to work on the Java Virtual Machine and I have been looking at alternatives to Java so I could be as productive as possible and stay away from those little Java annoyances and hurdles that slow me down. Having a background in Smalltalk I jumped at the chance to put your Redline Smalltalk through its paces and I have to say I couldn’t tell the difference between your Smalltalk and the others, in fact I think yours was a little faster.

At home I like to use IntelliJ and your plug-in support in the IDE is brilliant, the mix of old style Smalltalk-80 browser, refactoring and file based support is smooth and complete and just what I needed, especially the source level debugging and profiling which I could not live without.  At work we use Eclipse and I can’t tell the difference between the plug-ins so now I’m getting a few other developers to try it, and I think I made some converts.

One developer at work, Steve, keeps banging on about how Ruby On Rails is this and how Ruby On Rails is that, how we need rspec, gem, rake, and how awesome it is to script things and try stuff out with irb. You should have seen his jaw drop when I showed him how I can do all that in Redline and how quickly I could create, test and deploy my Seaside Web App and then push changes to different environments with a simple commit, even while they were running. You really did think of everything to make things complete and integrated with Smalltalk everywhere.

I wondered what you could add in the next release and I just can’t think of anything but if I do, Ill be sure to let you know.

Thanks for a wonderful product that has really changed the way I work and made it fun again.

Regards,

John Q. Geek.

We coders are probably all familiar with code smells that possibly indicate deeper problems in our code, and the need to refactor when they are found, but do you see interpersonal smells and the need to refactor yourself?

I often reflect on the interactions I have with team members and think about how those interactions went, mostly when I feel the outcome is negative or not what I expected. To me, these situations are interpersonal smells that possibly indicate a deeper problem in my interactions. Some interpersonal smells may be serious and some not, but I analyse each just like code to determine what if anything should be refactored in myself.

Just like code smells there is often a subjective judgement as to whether an interpersonal smell is really a smell or not and sometimes you need to call on others to help hold a mirror to your behaviour so you can make an informed decision. This is hard for a number of reasons, not least of which is having some good colleagues you can call on that will be honest and frank, as well as having the courage to carry out this reflection. Having others help you reflect is very important since a real interpersonal smell is like body odour, something that offends but the offended have a really hard time telling you that you have it. So how can you find out what you don’t know about yourself?

Depending on your circumstances you can just ask people you trust or you can use a more formal approach like that described in the Johari Window. The Johari Window is also referred to as a ‘disclosure/feedback model of self awareness’, and by some people an ‘information processing tool’. The Johari Window actually represents information - feelings, experience, views, attitudes, skills, intentions, motivation, etc - within or about a person - in relation to their group, from four perspectives. I have not used this model myself, but I know from research that it is apparently the thing to use. It can be used with groups as well. In my case I didn’t want to get that formal.

I asked some people I have worked with over the last five (5) years to give me a list of strengths and weaknesses so I can reflect on them and refactor my interpersonal smells. This is a hard and daunting task and one helper said “it really is ridiculously brave.” I suggest you also ask for strengths since you can read a weakness then a strength and use this to keep things positive and in perspective.

Here is a list of some of my strengths, as viewed by those helping me:

• Innovative and creative –> “an ideas man”
• Highly focused and results driven
• Always striving for a better outcome
• Technologically ‘hip’
• Protective of his team
• Values and encourages team input
• Highly congruent behaviour - Acts consistently with stated values
• Constantly learning and encourages team learning
• Customer and User focused
• Constantly identifying new ideas/opportunities that can exploit your technical skills/knowledge.

I’m not going to give the list of weaknesses as they are smells I am working on and hopefully going away by the time you read this. I am really glad to say that there were no surprises which means my process of reflection is working! Reflection on myself to identify interpersonal smells is important to me and my career. I encourage you to do it as well, and although it can be confronting the results are worth it. Let the refactoring begin.

I will be presenting at the next Melbourne Patterns Group on LISP. It will be a quick and simple introduction to the language and why I think you should use it.

There will be two special guests to support my presentation !!

The date and time is September 3rd at 6:30pm and the address can be found at the web site linked above.

I hope to see you there.

I am passionate about every aspect of design, and not just software or user interfaces, but other areas too. Architecture, Industrial Design, Clothing and many other aspects are of interest to me. This is why I read the book “Sketching User Experiences, getting the design right and the right design.” by Bill Buxton.

The book is inspirational and educational as well as long and with small print. It makes you think about the role of design the the importance of taking the time up-front to do designs. It also takes you through many practical approaches to designing for different mediums, including the User Interface. I practice Agile XP software development and I think there is still a need and a place for design, but I wont discuss that now. If design and the process of designing is important to you, then please get this book.

There are some quotes from the book which I just have to share:

In reference to spending time on Design -

”

Let me end this section by addressing a comment that usually comes up at this stage:

This is all well and good, and in an ideal word this might be fine. But in the real world, we have to meet deadlines and work under limited budgets. We simply don’t have the time or money to add this kind of process. Shooting for the ideal is just not realistic. ‘Good enough’ is all we have time for.

My standard response to such comments nearly always takes the form of the following two counter-questions:

How is it that we can never afford to do proper planning and design, yet we always seem to be able to afford to pay the cost of products being late as well as the cost of fixing all of the bugs that inevitably result from inadequate design, planning, and testing?

How can this be when the cost of design and planning is nothing compared to the cost of being late to market or having a defective product?

”

Sketching User Experiences goes on to show how Design as a profession is as rich as math or medicine, and I totally agree. Here is another nice quote from the book to drive this point home:

“Being able to add up your grocery bill does not make you a mathematician. Likewise, decorating your home does not make you a designer.”

Design is everywhere, but not all design is good and not everyone can design although they can play a part in the process of design. The Design Files is a nice blog about the design in different products and industries. The content and imagery may move you, and that’s by design.

Good written and oral communication is much harder than writing software, at least for me it is. I learned a good lesson recently about writing in a confrontational and non-confrontational way. I hope this post helps you.

The building where I live has had some problems with lax security resulting in damage and theft and so I wrote a letter to the Body Corporate asking for more attention to security. I sent the email to a friend to proof before sending it onto the Body Corporate manager.

My friend responded saying that my “tone” was confrontational but I didn’t see why, all I did was state my case something like this:

Dear Manager,

I would like to meet and discuss the recent security problems with the apartment block.
Please tell me a time that we can meet?

Regards, James

So what is confrontational about this I wondered and I asked my friend to explain. He said that using words like “I” and “me” make the dialog direct and this directness can be confronting depending on the individual receiving the message. He suggested that I make the message indirect and therefore less confrontational. This is what I wrote:

Dear Manager,

Could we meet to discuss the recent security problems with the apartment block.
Please suggest a time we can meet?

Regards, James

Personally I would not have a problem with the first version if it were sent to me, it is clear and factual. However, I do want my communication to be effective and confrontation is not effective. From now on I will be trying to look for and adapt my writing to remove direct speech and incorporate more collaborative words like “we” and “us”.

This is probably not the best or most thorough explanation on direct and indirect speech, so if you see a better one elsewhere then please send me a link.

Aegeon (the best company I have worked at in my 23 years of work) are hiring !

I thought long and hard about putting this in my blog but the enjoyment I get from working in such a great atmosphere of empowerment, trust, learning and teaching have swayed me. We also have a great laugh or two. It wouldn’t be right for me to keep all this to myself; would it?

Aegeon do in house product development, in-house and on-site consulting, mostly in the Web 2.0 space. We are passionate about our culture, learning to improve our craft and to teach others. We are also active in our development communities and support user groups and open source.

We mostly use (but are not limited to) Java, Spring, Spring MVC, Hibernate, Groovy and Ajax toolkits. We practice Agile XP, Test Driven Development and use Continuous Integration tools. We focus on delivery and we routinely deliver solutions we are proud of.

Management at Aegeon rocks !

So if your interested in knowing more then contact me directly at Aegeon:  james dot ladd at aegeon dot com dot au

At the recent Melbourne XP users group Erik Petersen gave an introduction / discussion of Agile Retrospectives based on Diana Larsen’s and Esther Derby’s great book (in the top 10 tech books for 2006). This was a great session with 22 attendees and I’ll have to remember to order more pizza for next time.

One part of the discussion I would like to share and record here is a sort of manifesto for communication with which we should all be able to achieve communications with positive outcomes:

Focus On

• Inquiry
• Dialog
• Conversation
• Understanding

Focus Off

• Advocacy
• Debate
• Argument
• Defending

So rather than debate we should try dialog, rather than defending we should try understanding and so on.

A few months ago I received a piece of advice that is worth so much as to be priceless. I’m going to quote it as best I can remember:

Don’t speak to be heard but speak to ensure you get a desired outcome.

This follows the same lines as those covered in ‘Getting to Yes’, that taking a position is never a winning approach in getting to an agreement. This also reminds me of a sharp line my father used to always slap us with:

“Get your brain in gear before you open your mouth.”

but this wasn’t always to me, since I had two brothers

I’m trying to repeat this first quote in my mind before contributing to any conversation to ensure I have an outcome in mind before I speak and to ensure I say things that help achieve that outcome.

When you contribute to a conversation what preparation do you go through to ensure a good outcome?

Steve has done it again and produced a great set of slides to accompany Cogents introduction to Agile. I recommend you have a look at them, preferably with someone who knows Agile to explain along the way.

I’m just coming off a project where we introduced Agile to a company that got bitten hard by the BDUF monster and will write about the transition experiences very soon.

Over at Quick and Dirty Now they have the amazing Grammar Girl. She rocks !

To improve your communications I recommend a daily dose.