When interacting with Ruby devs, Iāve heard a lot of feedback along the lines of āIāve heard that pairing is supposed to be good, but every time I try to do it I get more and more discouragedā. Other devs Iāve talked to have lots of great experience pairing with their peers, but arenāt sure how to work with someone more or less experienced than they are. The goal of this talk is to prepare you so that pairing is not only something that you can do with any other dev, but something that you want to do with any other dev. By the end of this talk, I want you to be ready have awesome pairing sessions where you are energized and excited by working together with other devs to conquer your shared problems. Pairing is a fantastic tool for your professional toolbox: letās learn how to design, discuss, refine, and refactorā¦ together.
We built TSOMI in order to see the interconnections of people listed in Wikipedia. However, much of this data is missing or is incorrect.
Most projects have some previous code written. As programmers, we have to figure out where and when to refactor and how much is necessary to bring something up to the new standards. We inherited a D3 project from a few years back and went to work on refactoring some of the code. The project is called TSOMI, which stands for āThe Sphere of My Influenceā.
Three years ago, my friend Robert HarrisĀ and I made a toy project to help some of our friends who were teaching in the humanities. They wanted ways to help their students understand who was connected to who. Being data visualization nerds, we wanted that too! We added connection lines and put people on a timeline in order to visually sift through who influenced who, and who were contemporaries.
As software engineers, we look for best practices throughout the whole software life cycle. We are constantly engaged in research and rethinking as we investigate new technologies and find tighter ways to factor complexity. However, developing better projects faster isnāt just about improving your tools; itās also about improving your developers. Therefore, we do our best to understand developer work and keep track of research that helps us to understand the coding process as a human process, a series of practices, and a discipline of the body and mind. Yet how do we know what we know?
