This blog post explains how a high level of craft is kept up and shared amongst our 40 plus engineers. Part two explains what the NCU is and how it integrates into your journey.
We’re a digital product agency, and we try and deliver the best value for our partners through mobile apps and digital transformations. We’ve found through excellent communication, constant feedback loops and the art of crafting, we can deliver value over an over for partners.
If you haven't read part one yet, you can find it here.
Novoda Craft University
We’ve created Novoda Craft University (NCU) to help people with their journey. This is the company trying to support the learning of our individuals.
Your company should be helping you with your journey. They can give you options and opportunities, opinions and a choice of directions.
Employees can take this journey together. Helping support one another, learning and teaching. Improving.. as a cult, as a team.
What is the NCU?
This is our guidebook to help people begin and continue their journey. It’s an attempt to show learning from multiple different aspects. To help direct and show the different areas learning can happen in. It has 5 Modules, each targets a different learning area. We set it out in a very target orientated manner.
Module 1 - Platform & Process
First, is learning the Platform and Process. We want people to understand our processes when they join the company. This means learning how the teams collaborate over GitHub, with pull requests, comments etc. It also means understanding the Novoda code style guidelines. Understanding project layout and Novoda conventions.
We want people to take a fresh look at the platform they are going to work on by implementing a simple app or library. Each person tries to learn something they didn’t know or refreshes old knowledge about the platform.
They could take an online Course, for example, Udacity or Coursera. They could do a Google code lab for a new feature. Or anything else they want, we try to apply structure but then leave the learning very open-ended.
We also have them read “Clean Code” by Uncle Bob and then share back some insight or knowledge they have acquired.
Writing code and reading other people’s code is a major part of a developer’s day. Some statistics even indicate that reading other people’s code occupies a larger percentage of a developer’s time than writing code. Therefore, it makes sense that a software crafter should hone their skills relating to writing code. The better code one writes, the easier it is for everyone to read, understand, and maintain that code.
Sharing is usually done in the form of a hack and tell.
This is where one person gives a brief talk 10-20mins about what they have learnt on a Google Hangout, and everyone in the company is invited to come along if they want. It’s also recorded for those that can’t make it.
The idea is twofold, first, it encourages the person to share their learning and learn how to explain what they have learnt. Also, it encourages others to seek out learning and be enthused by what they see.
Module 2 - Best Practices
While Module 1 emphasized platform knowledge and platform coding strategies, different programming languages have their own sets of best practices and standard conventions.
The first task in this module is to read one or more books from a list of what we at Novoda, consider to be some of the best language specific programming books. We have a buddy system as well for discussing what book would be appropriate. Then we ask the person to take a learning from the book and enact a change on one of our projects or open source repositories. Which encourages code reading as well as refactoring and cleaning up.
Finally, we ask the person to take part in a Kata usually run by their buddy in the company, this show’s them the kata process. A code kata is an exercise in programming which helps programmers hone their skills through practice and repetition. A simple task is setup and participants repeatedly solve it, perhaps with different rules or set of tools they need to use.
Module 3 - Testing
Code written for consumer applications is never a static entity. Requirements and designs often change many times midway through development and, even when they don’t, there’s never any guarantee that the code written will work as designed because errors (bugs) do happen, no matter how experienced and knowledgeable the developers are.
In light of that realisation, two questions come to mind:
How can we write code that is as bug-free as possible?
How can we write code to account for design changes, in a way that keeps the code clean, maintainable, understandable?
Like Module 2, this module requires a book. This time around, they’re asked to read Growing object-oriented software, guided by tests, by Nat Pryce and Steve Freeman. Additionally, it is your turn to run a coding kata.
For running a coding kata this book by Emily Bache is amazing. The Coding Dojo Handbook. It has lots of examples of Katas but also discusses how to set up the space and organise the event.
Module 4 - Agility
There is one aspect of true software craft that we have not addressed yet: being part of a team.
Large projects are generally far too complex to be developed in isolation and involve a team of people with various responsibilities and skills, from different departments and, sometimes, even from different organisations.
At Novoda we always try and explain, “we don’t do agile”, we are agile. This means being flexible in our approach to work and offer value rather than just offering an inflexible solution. So this module was really hard to put across, we’ve come up with a list of books that attempt to convey this but I feel the more important part of the module is the practicality.
We ask for them to run a retrospective and a workshop. Running the retrospective allows them to take a step out of their normal role and see how the team acts from the other side.
I’d like to point out two things, first Scrum: a Breathtakingly Brief and Agile Introduction, has only 50 pages with each page having 4-5 words on each page. It really is brief, and it represents how we see agility and being reactive and agile should be.
The other is ‘the nature of software development by Ron Jeffries’, this really cuts to the chase about what I was saying about value. Do your processes and practices bring value? If they don’t why do you do them. Great book.
The workshop is a flexible meeting. Workshops are group discussions, usually with a specific methodology and a specific expected outcome. Typically these aim to either define, clarify, or spread knowledge of aspects of the product being developed. So for example, a workshop could involve a prioritisation session for new features, or brainstorming with the 5 whys about a recurring but non-fatal error that should be fixed.
We believe each person should have the skills to run one of these meetings, to be able to solve problems through collaboration and group discussion. Rather than always flying solo.
Module 5 - Professionalism
Novoda is a service provider, crafting products and providing guidance based on the partners brief and our own experience. Our clients will generally have greater knowledge of their brand, target market and domain, while we are likely to have a higher level of expertise in the platform and ecosystem they want to target.
This requires constant communication on the client’s needs, internal demands, potential solutions and trade-offs. Communication is hard.
A software crafter will have developed knowledge of coding, testing and platform specifics. Now we expect them to give effective explanations, use appropriate language for the audience they’re addressing and present written and spoken communications in a positive manner to partners and colleagues.
It’s important that we can discuss technical problems together, understand other people's points of view and contribute constructively to meetings.
Module 5 aims to help build professional behaviour and communication skills in each of these areas, in order to achieve and maintain a level of professionalism.
We have a choice of books for module 5 and are always interested in learning about new titles. We have Sandro’s great book, that describes professional behaviour and your career. We have Getting to yes, which can help with discussions and conflict resolution.
The other half of this module is a reflection on past behaviour. We’ve identified common scenarios where communication issues can occur. We ask these to be considered in the context of your own experience, thinking about how you might adapt your approach and develop your communication skills in the future.
The problem areas we find are:
- Giving constructive feedback on pull requests
- Discussing a technical problem
- Speaking with colleagues
- Speaking with partners
- Proposing alternatives (aka saying no)
Here we ask for a blog post or a H&T to show the importance of one of these behaviours.
One more point, each of our chapters has references to previously completed works by other students.
This shows potential ideas, but also that the NCU is a collaborative effort and others have been where you are.
Completion is celebrated and everyone is notified. We do give a little celebration gift when people complete, but it is (or should) never be expected.
Learning is a journey, so what have we learnt through the creation of the NCU.
When trying to make complex & iterative mobile products, it's one thing knowing what to do, but it’s another teaching it to others.
Mobile is a young field, some best practices have now been established but there is a constant evolution in the approach.
With writing the NCU down, we found two issues:
We had to define what best practices where for us and cement our beliefs
We had to then maintain this documentation and ensure it is kept up to date.
It is extra overhead but we find it worthwhile for new starters.
Building Android & iOS products can be like working on two separate islands. However, at Novoda our cross-platform-ness works in terms of our architecture decisions and discussions around the domain.
Creating the NCU for Android and iOS wasn’t a perfect process. The different teams seem to have different cultures. Learning was gone about in different ways, and best practices across platforms aren’t at the same level.
This is an ongoing challenge for us, we’re taking feedback and iterating, but it’s always important to think about the bigger software picture, make sure you haven’t taken the wrong abstraction and are now in too deep. We are trying to take a step back and look for similarities all the time.
Read part three here: