If you’re a developer trying to understand what may be required to take a step up, then you’ve come to the right place. In this article, we’ll discuss a few of the traits that we look for when hiring or promoting into Tech leadership roles:
Embedded capabilities
Continuous Feedback – Peer Review for the 21st Century
One of the hardest things for any company to do is to foster an environment in which employees feel motivated and that they have the ability to improve, both as skilled employees and as people. For the last few years a fierce debate has emerged over the effectiveness of annual performance reviews and the merit they have in the 21st century workplace.
Our Favourite Retrospective Ideas
Ah, the sprint retrospective. When I first joined Made and found out about retrospectives (I’d never had one before), I couldn’t conceive of the idea that there would be any value in such a thing! So you’re telling me, I said, that we get together and do group exercises? Not about the work that we’re about to do, but work we’ve already done? I assumed that it must be a whine-fest about tasks we found tricky, or rationalising out loud about why something took so long to do. I was wrong.
Mob Programming
At Made, we’re always looking for ways to improve the quality of our code, and anything that can help us do that while also encouraging us to solve problems as a team is something we want to spend time trying out.
How To Build An Agile Team
There are many challenges in building an agile team. We hear about self organising teams, but how can a CTO ensure a roadmap is kept? We hear about #noestimates, but how can we plan anything without estimates? Failure is an important part of agile, but how can we accept failure in production? Communication is key, how can we encourage it?
An APPLE a Day: The Key to a Successful Presentation
My name is Pedro Martin, and I began my career as a programmer in late April 2015, when I started the Web Development Immersive course at General Assembly.
Busting Agile Myths: Story Points and Time
In my last post I mentioned a common controversy linked with story points. Common wisdom asserts that they shouldn’t be used to represent time, but this is on over-simplification which inhibits good estimation.
Tell, don’t ask. It’s a matter of principle.
When we design software with maintainability in mind, one obvious goal is to keep the unnecessary lines of code to a bare minimum. The less you need to see/read that is not vital to your understanding of the domain model, the better.
