Continuous improvement and change is one of the constants at REA. Hence it comes to no surprise that we also think about ways on how to further improve our culture. We have many people who are passionate about implementing new ways of working together. They come up with ideas and experiment on them within their teams. This is a great way to pivot and see which of these ideas work, how they work best and which ones don’t work at all. One of these cultural experiments was the so-called “Speedback”, which evolved from an experiment in one team to a ritual in many teams. Read about our Speedback sessions @REA in Ilya & Greg’s post.
– Victoria Schiffer
One to one speed feedback sessions help to build trust in a team, and contribute to creating an environment of learning. Trust is important because it enables the team to have quality conversations, for example about contentious topics. An environment of learning enables teammates to grow in areas relevant to their personal development goals. Helping individuals achieve mastery is a great way to keep motivation high. Below are the key properties of the feedback sessions we run in some teams at REA. Continue reading
Hi, I have a very direct, blunt style of writing.
My name is Stephen and I’m a Devop working at REA with about 7 years experience writing Python.
Communication is difficult. I don’t think I’m alone in this but it’s certainly something I’ve battled with over the years. Nothing is more daunting to me than a “clear communication skills” requirement in a job posting.
I even nearly failed TEE English! My final year of highschool I got 20% in my English exam in the first semester. That was a disheartening point in time. The good news is I learnt from that failure and put in a lot of effort to actually pass (barely!) in the second semester.
The great news is form isn’t as important as intent. This is why we can have such internet phenomena as doge (much internet, so hilarious) and dolan. It’s why we can have conversations over twitter and facebook comments.
Writing a blog post is daunting, especially if there is a chance many people will read it. All kinds of insecurities rise to the surface. Especially in the face of the great internet force of grammar Nazis.
I’m not quite at the point of my own public blog (where would the content come from?!) but I have an internal company blog I write to, I started using Twitter (that’s a micro blog right?) and I’m writing this.
Step 1: Put out content
Step 2: ???
Step 3: Profit
Communication is hard, but that shouldn’t stop us.
This blog post was inspired by Jonathan Ferguson (@jonoabroad) where the exchange started.
@jonoabroad “Does anyone have an agreed term of what micro services is?”
@joneaves “Does it need one?”
@jonoabroad “yes. How is it any different to SOA?”
Recently, I presented a talk at the DevOpsDays conference in Brisbane, Australia on how a team of people can utilise the best of DevOPS to deal with legacy applications. Specifically how migration, ownership, maintenance and handover of legacy applications can be handled.
The below video is a tale of such a journey that my team undertook recently.
DevOpsDays Brisbane 2014 – Mujtaba Hussain – Acquisition, Ownership, and Migration of Legacy Applications from devopsdays on Vimeo.
How REA challenged Call Centre preconceptions
There is a lot of bad press about Customer Contact Centres; callers usually dislike having to deal with one, and people working in them are rarely proud or engaged with their jobs.
But is it possible to create a Contact Centre where callers are left happy and valued, and the people working within them feel empowered and enjoy going to work?
And is it possible to achieve all that while moving the key metrics that matter to the business?
Yes, yes and definitely Yes! But you will have to be bold. You’re going to have to try a few unorthodox moves when it comes to Call Centre Operations. Continue reading
Please don’t use mocks or stubs in tests. While they are seemingly ubiquitous in enterprise development, they have serious drawbacks, and typically mask easily fixable deficiencies in the underlying code.
Even their most ardent defenders concede that mocks and stubs have flaws. These include:
Dependence on fragile implementation details
Mocks and stubs require intimate knowledge of how code interacts with other modules. Even if the implementation is correctly refactored without altering public contracts, these tests will tend to break, and draw your attention away from more productive tasks.
Testing incidental properties with no bearing on correctness
What is the point of this code? This is an essential question to ask, in order to understand it. Tests have a story to tell here, and mocks invariably tell the wrong one. Is the point of makeCoffee() that we made a coffee, or that we opened the fridge to get the milk? When we payShopkeeper(), do we care that we completed a transaction, or that we rummaged though our wallet for change? When mocking tests fail, the poor maintainer is left to reconstruct the real intent from a trail of indirect clues and anecdotes.
Web of lies
It is good practice to write data structures that are correct-by-construction; any constructor or sequence of method calls is guaranteed to leave the data in a meaningful state. Stubs introduce test-only fictions that are stripped of any of the safety latches and guarantees that may have been built in; they introduce fresh sources of error that are not present in the codebase. There is no value in detecting any failure that arises in such a way.
As time goes on, lies beget more lies. It is not unusual for a stubbed input in one place to result in another here, and another there; the fiction leaks and spreads into some kind of evil facsimile of the original code, but with more bulk, complexity and defects.