Talk
From your workstation to the client
The journey a line of code takes from the moment somebody types it to the moment it runs on a thousand servers and every human agreement it has to survive on the way.
- Event
- RubyConf Kenya 2019
- Date
- 25 to 27 July 2019
- Location
- iHub, Nairobi, Kenya
- Length
- 33 minutes
- CI/CD
- Code review
- Testing
- Deployment
- Team practice
- Ruby
Takeaways
The framing is that you will almost never write software alone and you will almost certainly not use it alone, so at some point you have to ship it. Everything between those two facts is collaboration, communication and automation.
Shipping is a team problem before it is a tooling problem
The question is not which pipeline to buy. It is what the team has agreed happens between a developer typing something and a client using it.
Code review and what it is for
Should you review at all is a real question with a real answer and the answer shapes everything downstream of it.
Testing and deciding what deserves a test
If you write tests, what should be tested and does the team work TDD or BDD? Answering that once, as a team, is worth more than any individual's preference.
Branching is a social convention with a technical shape
How branches get merged is a policy your team picks. Most of the pain people blame on git is really an unmade decision.
Automation is the cheapest teammate you will ever have
This is the argument I have kept making since. Get your pipeline right and it does the work of an extra person, every day, without being asked.
Watch the talk
The abstract, as submitted
Captions are turned off on this recording, so unlike the other talks here I have not been able to reconstruct it line by line. What follows is the abstract as it was published for the conference, which is the most faithful record of what I set out to cover.
You will rarely write software alone and you will most likely not use it alone. You need to ship it. The talk covers how to collaborate effectively on software projects and the ways of getting the result out into the world. Collaboration, communication and automation.
What really is the best way to work in a team collaborating on software? How does a developer just write code, then have it find its way to the server? Working in teams is a challenge and some of those challenges look like this. Should you do code reviews? Should you write tests? If yes, what should be tested and should it be TDD or BDD? How should your git branches get merged?
The session answers those by following the journey of code from the moment it is written on a developer's workstation to the moment it runs on one or a thousand servers, in front of real clients. The intended outcome was practical: better teamwork and a smoother deployment than the one you had before.
Where I was standing at the time
The speaker bio from the programme places this fairly precisely in my career. An open source enthusiast, a remote volunteer developer with the open source community AgileVentures and by then a member of Podii, the software company based in Kisumu. Before that, remote work as a coach and developer at Craft Academy, the Swedish academy and company.
Ruby on Rails was the day job. Elixir and Phoenix were the growing interest. That interest is what the rest of this page is mostly about.
The thread that runs from here into everything since is the last one. A year later, in the ElixirConf EU keynote, I was still making the same argument about pipelines being an extra employee, from the other side of a language change.
Think your organisation has outgrown its systems?
Let's figure out what is actually broken.