But this post isn't about that. This post is inspired by the rules, combined with observations I’ve made about the way many developers approach software design in general. This particularly applies in the ASP .Net world. It’s as if they’re following their own set of rules.
Here are the rules in all their glory:
Problem statement: my children need to be at school by 8:45 AM each day. I didn't decide to do that; it’s a legal requirement.
My children are in effect customers of a service I provide. I must implement any plan I decide on.
Many other parents (the competition, as I call them) drive their children to school. Someone had the seemingly sensible idea of driving. I should validate that with my children (customers).
“Girls, do you want to go to school by car tomorrow?”
“Yay! Great idea, we love going by car Daddy! But wait, you don’t have a car!”
Here at Guestline, we love the idea of self-organizing teams but know that it doesn’t happen in a vacuum. Self-organizing happens best when teams have matured in their practice, likely through a lot of experience. We hire developers with a range of experience, and we’ve tried teams without experienced team leads at the helm and the results can be quite chaotic. We feel that leadership can help improve alignment within the team.
As a Team Lead, you should think about servant leadership. That is, you should operate through supporting, coaching, mentoring, facilitation and enabling. You should rarely have to use…
At Guestline Labs we want new hires to have a great onboarding experience. I’ve seen first-hand many times the huge positive difference that investing in new hires makes to the long term success of that employee.
This post describes what you might expect as a new developer joining the team. Internally, we are just starting consistently applying this process. With consistency, it gives us the opportunity to reflect on how the process itself is performing in a controlled way and therefore improve it.
As a new employee, the activities of the onboarding process should:
When a task becomes blocked, we want to have a clear indicator to the team that it can’t be worked on for whatever reason. Simply adding a comment on a task doesn’t give any indication on the board. Here is a set of screen grabs to guide you on one way you can do this in minutes using tags.
Here at Guestline, we are just starting to open new opportunities to drive our company to new markets and you could help us going to the next step. We’re trying to build a great development team and we want people who know the best practices of the industry.
Guestline is a company undergoing transformation. We aim to have a modern engineering culture and as part of that we, of course, now have a GitHub account and a handful of projects.
There are so many great open source libraries and frameworks available and we should prefer to use one. That said, there isn’t always good fit available for our problem and sometimes the best way forward is to build our own. We avoid reinventing the wheel by ensuring anything we build competes with alternatives.
When we build a shared component, we ask ourselves:
Seems like an obvious question but…