|What more can you ask for…|
Which is the author’s way of asking you to take total responsibility for any piece of work you have touched. As the book continues: “If you accept responsibility, you are in a position to do something about it … … There are no excuses.”
|“If you are using arguments on the left to justify
refactoring, you’re screwed” – Martin Fowler
By letting go of the excuses and taking responsibility, one can look for and find ways to do what’s needed. An example would be to follow the experts in the field and figure out where things may have been done wrong, as I found out when I came across the tip from Martin Fowler given in the picture on the right/above.This should lead to widening your horizons and looking at beyond your role in the team and appreciating what restrictions those higher up the chain are under. Helping them work around those without stepping on their toes would be an ideal solution, if possible.
An important idea here is to embrace constraints: there’s never enough to go around. It is unlikely that any project you work on has everything provided ideally – from the resources to intangibles like motivation/knowledge of the team/management. For example, a team/company that has not experienced an Agile workflow or the benefits of a loosely coupled, well written code base will not immediately agree to Scrum/Kanban or TDD respectively. Assessing what’s possible and implementing that change in a way acceptable to the majority can be a worthwhile goal in a difficult situation. To take the first step on that journey, the idea of owning all that you work on would be a good start.
Another way this kind of responsibility can be expressed is by looking out for ways around potential blocks you can visualise in future. I’ve had a chance to do this by volunteering to work on porting a MVC2 project to MVC4 along with replacing the DI layer over the Christmas break. More recently, when that project had to increasingly call our second big application, on the suggestion of another developer, we’ve started implementing micro services for the newer functionality as a start of breaking down the two monoliths instead of tightly coupling them by dll references.
Having personally worked with people who do put in this type of commitment to their daily work, I am certain this is something everyone should aspire to. Even if not all that is desired for is not achieved, the project and the team members are better off for such efforts, as I hope you’ll find out if you give this a try. If you do, try and let me know how you get on.