Category Archives: Career

Thoughts on Thoughtworks Australia Team Hug September 2010

Posted on
2

I haven’t started yet at Thoughtworks (it’s still a week away), so I felt very privileged to be invited to the the bi-annual Thoughtworks Australia Team Hug over the weekend in country Victoria.

The weekend consisted of a series of talks and heaps of fun. I really enjoyed the talks by Martin Fowler on DSLs (Domain Specific Languages) and Chris Bushell on how to avoid branching code which was interesting as it relates to the new focus on Continuous Delivery.  I also enjoyed the two Dev-Ops talks, one frightening story by Tom Sulston and a much calmer one by Evan Bottcher. I need to look more closely into the Twist automated testing tool after seeing a demonstration of its features.

Besides the talks, there was a great Wild West themed party on Saturday night, complete with a photo booth that produced lots of hilarious photos. I dressed up as a cowboy, complete with chaps, boots, hat and guns. People went to huge effort in getting dressed up, there was even someone in a giant cow costume!

I managed to fit in a nice morning stroll on Sunday morning to enjoy the fresh country air and surroundings, which was very pleasant as I live in the city-city.

It was a great introduction to Thoughtworks culture and people and an all round enjoyable event.

A ThoughtWorker to be

Posted on
6

I’ve recently accepted an opportunity with Thoughtworks, who are setting up a presence here in Brisbane, Australia.

I am thrilled to be offered this opportunity to work for a company who is passionate about revolutionizing IT and is so well aligned with my values and ideas. I found the Thoughtworks recruitment process to be very thorough, whilst not over the top, and actually enjoyable. This is because it gave me a great insight into the company as I got to meet a lot of thoughtworkers, and I felt very confident to  accept the job offer without any reservations. Thoughtworks thoroughness in assessing candidate’s technical ability and aptitude also made me confident that I will be working with other very capable individuals.

I look forward to beginning at Thoughtworks in mid-September as a Senior QA Consultant, and in the meantime I will be having a short break with my family.

Why I do automated testing

Posted on
6

I often get asked the question: “so why do you do automated testing?” both in job interviews and from people I meet. My answer is always pretty much the same; being that it provides me with exposure to a variety of business domains and technologies, and allows me to write code.

Let me expand a bit further on this. I like writing code but I’ve chosen not to be a software engineer. The reason is that I have met lots of different software engineers that have responsibility for one area of a system. They become the expert in this area of the system, hence when you find a problem in that area, you know who to speak to. Often time these people don’t really know much outside their area of expertise in the system, so when the problem is outside their own area, you need to speak with someone else. There’s nothing wrong with this, but it just isn’t me.

I like to know, or attempt to ‘work out’, how the system functions as a whole. I usually achieve this on a project I join by writing an automated build verification test, or ‘smoke’ test, that verifies the system functions as a whole. I love writing these kinds of tests because you need to know how the entire thing works, not just the isolated components. Software testing is one of the few areas where you get this broad level of exposure, and this keeps things interesting.

Another added bonus of doing software testing, is that your skills are pretty transferable, both across business domains and different technologies. For example, so far in my career I have tested systems that:

  • manage job advertisements, job seeker matches and interviews;
  • process immigration and visa applications;
  • manage disability support and funding;
  • produce electronic school report cards;
  • optimise large scale open cut mines;
  • monitor health of heavy machinery; and
  • manage large funds for people’s retirements.

These systems were developed in various technologies including:

  • Java;
  • Microsoft .NET;
  • Cobol;
  • Powerbuilder;
  • Web;
  • Active X;
  • Terminal Emulators;
  • SOAP web services and;
  • CICS.

The point I am trying to make is that if I decided to be a Java Software Engineer when I finished university, because that’s why I studied, I wouldn’t have had exposure to so many technologies and business areas that I have had as an automated software tester.

Sure, I could become a business analyst, because they work across business domains and technologies, but business analysts don’t code, and I do like writing code, that’s why automated testing is perfect.

The final benefit I see in automated testing is that you can apply your skills in particular testing tools to other tools fairly easily, as the concepts are the same. The biggest issue I see with people doing automated testing isn’t picking up a new tool, but rather developing a maintainable and easy to use test framework. Once you have developed a few frameworks for various business domains and technologies, it is easy to apply the concepts to other testing tools.

So that’s why I do automated testing, and I proud of it.

Austin Workshop on Test Automation (AWTA) 2009

Posted on
2

Watircraft are organising the Austin Workshop on Test Automation to be held on 16-18 January 2009 in Austin, Texas.

I have been approved to attend. It means three long flights from Australia (about 25 hours each way) but I am really looking forward to attending and meeting different people who are involved in Watir.

I haven’t been to America before either, so it should be really good.

Personal Business Cards

Posted on
Reply

Even though I do a lot of networking via the web these days, I still appreciate meeting people with similar work interests in person at events and conferences.

Although it may be considered old fashioned, I think it’s a really good idea to have business cards to share with others you meet so that they remember you and can connect with you later on if they want. Although some places provide business cards to their staff (like my current job), these are often quite bland, so I think it’s a good idea to have your own personal business card. A personal card is more likely to stand out and show who you really are. You can also put your personal contact details on it, like the address of your blog and your LinkedIn page, and have no hesitations about handing it out.

My favourite site for creating these cards is Moo, an online print shop that is located in London but ships worldwide. They use high quality card and inks, and send witty emails as well. I created some MiniCards a while back for my right brain blog, which are really cool, and I noticed last night they now do full size business cards which I ordered last night for this blog.

When coming up with a design, I considered designing a card with my name on in my own handwriting because of an excellent article I read recently. But I ended up with a different design because the handwriting was too risky. On one side I put the header of this blog in bright red, and on the other side some simple type with my details, but written in ruby syntax. I used ruby syntax to make it look clever and relevant.

They should arrive in the next few weeks (the express shipping was too expensive) and I’ll scan one and share it on here when they do arrive. I can’t wait.

Weird ways of working, car indicators, and shoshin.

Posted on
Reply

Have you noticed how weird you think things are when you start in a new organisation?

But then things slowly become normal, even though the ways of doing things don’t change?

For example, I bought a new car at the start of this year. In the first few weeks of driving I noticed that the indicators were weird; they made a loud clicking noise from the dash. Loud enough for passengers to hear (and comment on). But soon I stopped noticing them; my weird indicators had become normal. Last weekend I hired a car in Canberra for the weekend. The indicators were so quiet. Weird!

This concept is known in Zen Buddhism as Shoshin. From Wikipedia:

Shoshin (初心, also pronounced nyuanshin) is a concept in Zen Buddhism meaning Beginner’s Mind. It refers to having an attitude of openness, eagerness, and lack of preconceptions when studying a subject, even when studying at an advanced level, just as a beginner in that subject would.

This is a pretty powerful thing to have, but after starting in an organisation it’s also pretty easy to lose it. That’s why things no longer seem weird even though they haven’t changed.

As a new starter, make sure that you jot down all the weird things from day one, so that you can remember them. You can then organise a meeting with your manager a few weeks (or months if that’s more comfortable) and discuss these things. You should frame them in a positive way, that way you won’t come across as criticising things.

As a manager, you can make sure you capture all this powerful information by organising regular but succinct one-on-one meetings with your new starters and asking them what they think is weird and how things could be done better. Because It’s going to get harder to capture this information as your new starter slowly loses their shoshin and begins thinking of things as normal.

Contract vs Full Time IT Salary Rates in Australia

Posted on
10

I have worked as both a IT contractor and also as a full time member of staff. I found there are benefits with  each form of employment.

To me, some of the benefits of being a contractor are:

  • Ability to change projects more readily;
  • Shorter term commitments to work; and
  • Networking opportunities working across various companies/contracts.

To me, some of the benefits of being a full time member of staff are:

  • More stability in times of turbulence;
  • Greater continuity of work;
  • Greater ability to borrow money from banks;
  • Availability of professional development and career opportunities;
  • Employee fringe benefits (shares/bonuses/insurances); and
  • The feeling of belonging and providing value to an organisation/team.

A lot of people I meet prefer contracting because they think it pays more. I am personally not convinced that contracting is much more lucrative. Let’s compare the same theoretical IT job as both a contractor and a full timer.

Job Details

Hours of work: 7.5 hours per day
Public Holidays: 11 public holidays per year
Annual Holidays: 4 weeks (20 days) per year
Sick Leave: Assume we take 5.
Professional Development: Attend 1 course and 1 conference per year. 5 days off work and $5000 in attendance costs.
Work Days In Year: 52 weeks * 5 days = 260 days
Days Off From Work (see above): 41 days
Actual Days Worked: 219 days
Actual Hours Worked: 219 days * 7.5 hours = 1642.5 hours

Full Time – $80,000 year base + superannuation (9%)

Total Salary Package = $80,000 + $7,200 super + $5,000 courses = $92,200 p.a
Effective Rate per hour: $92,200 / 1642.5 hours = $56.13 per hour.

Contracting – $60 per hour net including superannuation (and agents fees and insurance already paid)

Gross Amount Received: 1642.5 hours * $60 per hour = $98,550
Effective Base Salary: $98,550 – ($8,136 (Super) & $5,000 courses) = $81,412.84 p.a

You can see that the financial difference between earning a salary of $80,000 per year and earning $60 per hour as a contractor is nominal.

But what if you worked, and billed, much longer hours as contractor? You could earn more, but that’s not really comparing apples with apples is it?

In conclusion, it does pay to think about what a full time salary means and what an hourly rate means. $60 per hour might seem like a lot but when you take into account all the extras that full time employment provides (continuity, superannuation & career development) you may not be getting a bad deal as a full timer after all.

Photo by jsarcadia (creative commons)

Five organisations I would love to work for (geography aside)

Posted on
4

I believe that it’s a good idea to keep a wish list of companies that you’d love to work for. This is not just to make sure you keep an eye out for opportunities at these companies, but also to discover what it is that makes you want to work at these companies. This makes it easier to chose other jobs that have some of those same qualities.

Your wish list also guides you to make decisions that open up opportunities at these companies, whether that talking to your work collegues about what it would be like to work there, or doing a LinkedIn search to see if anyone in your ‘network’ already works there.

Your wish list doesn’t even need to be realistic. None of the companies on my list are based in Brisbane, and only two are even based in Australia. I’m pretty much set on living in Brisbane; I love it for many reasons. The main reason is the proximity to my family and inlaws. At the moment, no job could be better than that.

But here’s my list:

  1. Threadless: I think this article pretty much sums it up. I also love this other quote about when they were deciding on how to make more money: We’re like, “we should give them stickers because stickers are awesome.”
  2. Atlassian: They make rock solid products (Confluence, JIRA…), aren’t afraid to take on the big players, and strongly support open source. I also love their mission and culture.
  3. Automattic: – Any wordpress user would know why I would love to work for Automattic. They advertise jobs such as Happiness Engineer and state that… everyone who joins Automattic, regardless of position, does support for 3 weeks.
  4. The Big Issue: Not only do The Big Issue support a great cause: homelessness in Australia, but the magazine is a really good read too. There’s no other mag that I enjoy reading more. This is truly a dream job though – they only have a full time staff of… three!
  5. 37Signals: Who wouldn’t want to work with the creators of ruby on rails and the authors of Getting Real? They also write one of my favourite blogs. But the real reason is that they really dig writing skills, and I dig that.

Software Testing Career Development

Posted on
2

I am very interested in actively driving my own career in software testing. I believe that everyone should take responsibility for their own professional career development whether or not they get support from work to do so.

Ian Clatworthy recently shared his own professional development framework aptly named M.E.T.A. – Management, Engineering, Technology and Applications.

The framework is great in that it superbly breaks down technical professional development into four dimensions/pillars. The M.E.T.A. framework is probably better for software engineering so I have remixed it into something that suits my own software testing context better.

Leadership (Ian’s Management)

Whilst I have been in direct Management roles in the past, I currently do not work in one. I believe that it is important to demonstrate leadership no matter what role you are in. Even if your are not given the title Manager or Supervisor, or even if you don’t have people to manage, you can, and should, still demonstrate leadership. This is why I renamed Management to Leadership. For me Leadership is all about:

 

  • Using the right side of my brain - being organised, tidy & efficient (following concepts like 5S), being emotionally intelligent and aware, developing creative solutions.
  • Having a project management focus – following sound project management techniques and conducting each bit of work as a small project.
  • Writing Well – following known writing guidelines. Documenting every bit of work. Sharing all knowledge and information.
  • Communicating Well – Documenting well. Communicating progress and issues in the right format at the right time.
  • Team Building – establishing productive relationships with members of teams working in and with. I can’t emphasise how important this is.
  • Finding Informal Career Guiders – always indirectly looking out for people who you can chat to informally about career stuff. This is where I have discovered great leadership styles and techniques. I call these people career guiders because I really hate the word ‘mentor‘.
  • Being ethical – Making sure I provide value and I am honest in everything I do.
  • Sticking up for others you work with – Making sure that your fellow team mates are well supported.

Concepts (Ian’s Engineering)

I personally have chosen to focus more on the software part of software engineering. For me the Concepts pillar is all about the concepts and theories behind software design, development and testing. This is the stuff that I learnt at University and is generally timeless. For me Concepts is about ‘understanding’:

 

  • Understanding Software Development Methodologies: how IT software design and development works as a whole.
  • Understanding Software Projects: how IT software projects work.
  • Understanding Programming: knowing programming concepts and techniques.
  • Understanding Testing: understanding testing best practices, test driven development, test automation, acceptance testing.
  • Understanding User Centred Design: focusing on usability and designing for users. Paper prototyping and iterative design.
  • Understanding Design: understanding general design principles.

Tools (Ian’s Technology)

I was going to leave this called Technology but I ended up changing it to Tools as this is pillar is essentially the tools required enable the ‘Concepts’ above. These are different from concepts in that while most concepts are timeless, the tools or technologies tend to change.At present I am focusing on developing skills in using open source tools. I find these are good in that they are open and free (as in speech). Some tools I know and/or use are:

 

  • Programming Languages: such as Ruby, Python, Jython.
  • Testing Tools: such as Watir, OpenQA.org and homebrew test automation tools.
  • Collaboration Tools: such as wiki’s, defect management, blogs.
  • Versioning Tools: such as SVN, Git, Mercurial, Bazaar

I guess that one component to this pillar that doesn’t fit under the term tools are the technologies that are worth knowing about and understanding (perhaps I should call it Technology after all!). Things like:

  • Ajax (Rich Internet Applications)
  • Web 2.0
  • Social Networking
  • Tag-based Folksonomies
  • RSS

Business-focus (Ian’s Applications)

I believe it is important to understand the business of where you work, as well as the applications that support the business. Even open-source projects have business, they are in the business of providing software developed by communities of people to be used by other communities of people. I often see IT staff that do not have understanding or respect for the business. For me, displaying a business-focus means:

 

  • Understanding business goals: why I am employed in the first place.
  • Understanding business applications: what they do and how they fit into the business processes.
  • Understanding business processes: how business is conducted, with or without IT.
  • Understanding how business and IT collaborate and partnership: Hoping that the tail doesn’t wag the dog!
  • Providing value to the business: continuing to be employed.
  • Keeping up to date with the business: knowing what the business industry/competition is doing and about the other happenings in the business domain.
  • Understanding how executive management operates: because they usually pay you and maybe you would like to be there someday.

Conclusion
As Ian covers well in his post, the pillars make a great ordered list of dimensions in terms of career mobility. As I renamed his Applications pillar to my Business-focus pillar, I tend to consider my Business-focus pillar to be equally as or more important than my Tools pillar.

 

This means that my ordered list of dimensions is essentially Leadership, Concepts, Business-focus & Tools.

Like any contextual approach, everyone’s pillars will be different. This is a good thing. Although sometimes an unbalanced focus on a particular pillar can cause problems in your career. For example, focusing mostly on the Buiness-focus pillar may mean you can’t easily move jobs into a different organisation/industry when you want to.

What’s worse is not thinking about your career at all. Organisations may consciously develop their staff (as good managers do) but as staff are becoming increasingly mobile and contracted, the responsibility for career development is being pushed back upon the individual. This is when coming up with a personalised, balanced and ordered career development framework (and continually revisiting it) is so important.