„Never stop learning new things” – wywiad z Emily Bache

Emily Bache pracuje w branży od ponad 20 lat. Na co dzień zajmuje się trenowaniem zespołów programistów w zakresie dobrych praktyk związanych z agile. W naszym wywiadzie opowiedziała więcej na temat swojej pracy oraz podejścia do projektów oraz podzieliła się wiedzą w zakresie złych praktyk, które często dezorganizują prace w firmach i startupach. Zapraszam do lektury.

You are an experienced Agile trainer and promoter of the „Samman” method. What is the „Samman” methodology and who is it aimed at?

Technical coaches work with software development teams to help them adopt better coding practices. The Samman method is a concrete approach that many technical coaches use. The focus is on iterative and incremental development practices. The Samman method has two main parts: learning hour and ensemble working.

In the learning hour the coach uses exercises and active learning techniques to teach the theory and practice of skills like Test-Driven Development and Refactoring. In the Ensemble sessions the whole team collaborates together with the coach in applying these development techniques in their usual production codebase.

The expected outcome is that teams work more effectively and consistently with iterative and incremental development techniques. Ultimately the organization becomes able to build new features in their software with a shorter lead time and higher quality. You can find out more about this coaching method on the Samman Society website.

Emily Bache jest jedną z prelegentek tegorocznej konferencji Infoshare 2022. Bilety na to wydarzenie z 15 proc. zniżką możesz kupić tutaj.

Can you define what good programming practices are for you?

I teach a lot of different techniques depending on the situation of the team I’m working with. A common theme is the ability to work in small, safe steps, sharing your work often, and designing code in such a way that enables you to respond to change. You want to have a codebase that you feel comfortable and happy working in, and that lets you quickly take advantage when you spot an opportunity to change something and create value for users.

It seems that you hear about good practices everywhere, yet many programmers write „spaghetti code”. What do you think is the most common reason for having bad practices?

I’ve certainly worked with a lot of developers that have “spaghetti code” and are not enjoying working on it. Their organizations are also suffering from the high cost of changing that software. I think there are two main reasons for this situation. Firstly there can be a lack of skill. Developers may not realize there are safe ways to improve the code, or perhaps if they do, they are not skilled enough to do it. Secondly there can be a problem with culture. Even if developers are skilled at improving code design, they won’t do it unless this behaviour is encouraged and rewarded.

So should programmers, engineering teams or team leaders of software development companies be trained directly to promote good practices?

All of the above! Everyone needs to understand what good looks like and pull together in the same direction.

How best to promote good practices, programming principles?

The most effective approach I’ve seen so far in my career is technical coaching at the development team level, together with agile and leadership coaching of the organization as a whole. Developers need to learn new skills and ways of working, and the rest of the organization needs to learn agile ways of working too. I often see organizations wanting to make improvements to lead times and deployment frequency and hiring a bunch of agile coaches for the process and leadership, but forgetting that developers need coaching too.

There are also some pieces of technical infrastructure that need to be set up in a way that enables developer collaboration. I mean infrastructure to support trunk-based development, ensemble working, continuous integration, continuous testing, self-service deployment etc. Developers need new skills but also to be in an environment where it’s easy and encouraged to do the right thing.

What can companies do in this regard, and what can programmers themselves do?

Decision makers could do worse than pay attention to the book “Accelerate” by Nicole Forsgren et al. There is a lot of advice in there that is backed by credible research about real companies.

Oferty pracy z

Programmers themselves can always choose to spend a small amount of their time at work learning and practicing new skills. Taking an hour a week of your normal working time shouldn’t get your boss on your back, especially if you can show after a few weeks that you learnt something that saved you time on one of your usual work items. You can spend that time as individuals reading books, watching videos of conference talks, or practicing on code katas. Even better if you can make it a team event and do it together.

If you can persuade your boss to let someone do some preparation for your team learning hour, they could use some of the materials on the Samman coaching website – you’ll find a lot of resources there for technical coaches and team leads. It’s all released with a creative commons license so you’re free to use it so long as you give attribution and preserve the license.

Perhaps they can be persuaded to stick to these principles by the numbers? Why does it pay to follow good programming practices?

I refer you again to the “Accelerate” research. Their advice matches my experience.

You have been working in the IT industry for more than two decades. What did this industry look like when you started your programming adventure?

In my first job I remember The Shelf. It held about 25 binders which described the development process our company had developed. I forget what the method was called, I think in practice it was quite similar to the Rational Unified Process. The shelf and the binders contained hundreds and hundreds of pages of detailed prose and diagrams describing exactly every stage of the development process. At this company we prided ourselves on the quality of this methodology – it represented our competitive advantage.

I remember hearing about a consultant who was out in the field working in a development project who phoned head office in a panic – “can you just check what I’m supposed to do in my current stage of the process? Can you read me the section on it in the relevant binder? I’m meeting the customer in 2 hours!” Crazy big process!

Was it easier back then?

I am not nostalgic for those days! We have much better development tools now, and we know far more about what works in software development.

What do you think makes a programmer’s job the job of the future? What makes learning programming today sure that in 10, 20 or 30 years we will find a job in the profession?

It’s a branch of engineering, and a relatively young one at that. We have needed good engineers for hundreds of years to build bridges, railways and all kinds of technology. I can’t see that changing.

What do you think is not talked about enough in the IT industry?

Ethics and diversity.

What advice would you like to share with our readers?

Never stop learning new things.

__

Emily Bache. Technical Coach with ProAgile. She has worked with software development for over 20 years in diverse organizations from start-up to large enterprise. These days Emily specializes in coaching development teams in agile practices like Test-Driven Development, refactoring and agile design. Emily has written two books, authored Pluralsight courses and regularly speaks at software conferences. Originally from the UK, she currently lives in Gothenburg, Sweden.