WillRay
commented
6 years ago Here is one idea of how I think we could re-arrange the Graduate Developer role. It changes the examples to avoid using declarative emphasis (I am this, I am that, I do this), and emphasizes the important parts first.
I post this for conversation - I don't think it's the final answer.
Graduate Developer
I am a committed student of Readifarian values.
- I write good quality code that can be shipped to production.
- I show great enthusiasm and initiatives.
- I am an egoless, team oriented developer.
As someone who is a committed student of Readifarian values, I may:
- Be learning how to use a build and delivery pipeline.
- Be learning how to convert client requirements into deliverable units of work.
- Be competent with the tools and core building blocks used by our team.
- Understand the value add of different types of testing such as automated and manual testing.
- Be learning to implement design patterns that are widely used.
- Be learning about the infrastructure my code runs on.
- Be understanding the importance of PD and recognise the role it plays in my progress.
- Be learning the concepts of agile development and try to apply them within the project they are allocated to.
- Be aware of agile practices, and are actively learning how to apply them day to day.
- Be self-directed in my learning of technologies that interest me and seek guidance on technologies they should learn to progress my career.
- Be a team player who adheres to the team's conventions and processes.
- Not be afraid to provide my thoughts and insights to the team.
- Be professional and friendly to all my team members and fellow employees.
- Other team members genuinely want me on their team.
- I avoid going dark and I know when to call out for help.
- I am learning about all processes of the team and try to follow them (like maintaining accurate documentation, adding tests and so on).
- Continue to work enthusiastically, even when I disagree with something, while learning from the others in the team.
- Try to develop a friendly and professional rapport with my customer and their team members.
- Have net-positive, informative and helpful contributions to team discussions.
robdmoore
GianLorenzetto
glav
wtulloch
luizbon
andrewabest
mishrsud
The second line of our README states:
The bullet points are examples to provide direction in conversation; they are not a checklist to be ticked off.
We continually have to explain this point in retrospectives. I am continually explaining it to other Readifarians, some of whom have been at Readify for years.
A great example of this confusion is our application, which is designed for retrospectives, quite literally turns it into a checklist:
Which then iterates through each one, again reinforcing the wrong message:
This widespread misunderstanding indicates that we are not doing a good enough job of making MadSkillz GitHub documents clear in their intent.
While we have a sentence that attempts to clarify this, the document itself is structured in a way that encourages the opposite. Someone who has never seen MadSkillz before should be able to open up a page and understand intuitively that the items are examples.
What can we change in MadSkillz to make it clear that the bulleted items are not prescriptive?