The power of feedback
"Everyone has a story that makes me stronger." -- Richard Simmons
There’s something about feedback. Whether it’s the validation of your latest idea, a hit on your webpage showing up on Google Analytics, or something as simple as a passing test, it’s a valuable and important motivational commodity, which can also shape the direction in which we’re going very precisely.
The effect of feedback is the engine at the root of software techniques as diverse as pairing, TDD, BDD and the Lean Startup movement. Why is feedback so powerful?
Feedback shortens the loop
Any sort of feedback represents the end of a creative loop that started when we began to work on whatever we’re receiving feedback about. The shorter that loop, the more quickly we can respond to change, and the more agile we can be. It also helps us know when we’re done working on something and it’s time to move on.
That’s partly why TDD is so powerful: we receive instant feedback on what we’re working on and we are never more than a few minutes away from a fully working system. It’s also why good quality customer feedback is powerful: we’re never more than a few iterations away from the feature the customer wants.
Feedback validates us and our work
The validation of our work is one of the things that lies at the root of pairing: the constant code review and the camaderie keeps us motivated and working on something longer than we can manage on our own. I’ve found programming on Sol Trader alone to be an enlightening experience - I’ve learnt how important it is to have others working alongside me. I now have a graphics expert reviewing my code, and more design and artistic help to keep me motivated to turn out releases.
It’s also incredibly motivating to receive a “thank you!” or “looks great!” There’s a lot of power in simple encouragement. If we know our work is appreciated and valued, we’ll likely to work longer and with more energy on that next killer feature.
However, there’s a danger in only seeking pure validation, or (worse) coming to rely on it for motivatioW. If we receive too much positive validation, we’ll end up getting proud of ourselves and demotivated to push for excellence, and we’ll get terminally discouraged if we get too little. We should be seeking the kind of feedback that motivates us to shape our work for the better. We have to learn to ask the right questions.
Feedback shapes our work
If we let it, feedback will change the work we do and how we do it. This applies no matter how we receive feedback about our work - the different types of feedback will change our work in different ways, and we must therefore strive to increase both the quality and the variety of the feedback we receive, without falling into the trap of simple validation.
Done right, TDD offers more that just validation of our code; it gives us information about the quality of our code design. It causes us to shape our code differently and more carefully than code written without feedback. We can’t operate in isolation though: TDD without feedback from stakeholders (whether that’s through a technique such as Behaviour Driven Development or some other method) is incomplete: we get feedback that our code works, but nothing on whether it’s the right code.
There’s more: conversations such as Lean Startup are taking the BDD ideas one stage further. Instead of relying on the guesses of the stakeholders to determine what the right features are, how about harnessing feedback from the actual customers using the product? This can be done in various ways, through automatic metrics gathering and tracking experiments rather than features.
It’s my opinion that the Lean Startup conversation is certainly as important as the BDD conversation, and potentially as important as the Agile conversation, as it improves the variety of the feedback we receive on our work.
How are you finding feedback shapes your work? Are you getting the right kinds of feedback from a variety of sources? Or are you settling for pure validation?
Share
More articles
How To Avoid Bad Startup Culture
If you are not paying attention to your startup culture, I have news for you: you are already building a culture into your company. Chances are that is not the culture you want.
Every company has a culture. It is a summation of all the habits and practices that make up the work. It is every choice, good or bad, made by every person involved. Every action sets a precedent, a “how we do things here.”
This is how we are wired. We are naturally social beings and are strongly predisposed to fit in to the group we find ourselves in, and to emulate their behaviour. This reinforces culture further, and compounds when more people are involved.
A culture grows like plants in a garden. You cannot stop the life from growing, but you can decide how and where it grows. Left unattended, weeds will grow alongside the flowers. The key is recognising this and putting in the work to shape it.
Here is a quick primer on how to do the minimum to avoid bad culture, and how to get good culture going with a little attention every so often.
Read moreHow to Build a Robust LLM Application
Last month at Cherrypick we launched a brand new meal generator that uses LLMs to create personalized meal plans.
It has been a great success and we are pleased with the results. Customers are changing their plans 30% less and using their plans in their baskets 14% more.
However, getting to this point was not straightforward, and we learned many things that can go wrong when building these types of systems.
Here is what we learned about building an LLM-based product that actually works, and ends up in production rather than languishing in an investor deck as a cool tech demo.
Read moreThe Job Is Not To Build
Startup CTOs or founding developers are the first technical people in the business. It is natural to think your job is to write code and build software. This is backwards.
Your first job is not to build software. Your role is to use your technical expertise to help the startup figure out fast if you have a valid solution to a compelling problem, and then a valid product for a big enough market.
You might do this through building software, but you might not need to.
Here is a story of how I did this wrong, and how you can do it right.
Read moreYour Code Is A Liability
Every chunk of code you commit is more for someone else to read, digest and understand.
Every complex “clever” expression requires another few minutes of effort for each of your team. They must now interpret what you wrote and why you wrote it.
Every line you add limits your project’s responsiveness to change.
Your code is a liability. Never forget this.
Read moreThe First Thing A Startup CTO Must Do
Perhaps you are a technical co-founder who has managed to raise funding and you have been catapulted into the startup life. Perhaps you have just been brought in to handle the startup’s tech after the first round came in.
As the CTO, or the most senior technology person in the company, there are so many calls on your attention at this stage.
There is plenty of interesting new tech to build. There are potential customers to speak to (hopefully). There are investors to keep updated, who will want to know when the company is going to grow. There are people to hire. It can feel like you are drowning in possibility.
In the midst of all of that, we neglect this one thing at our peril.
Read more