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?
Over several years of working at Cloud City Development, I’ve seen a consistent demand crop up repeatedly amongst our clients' companies: How can a team of software engineers hire aggressively to meet future needs, while still having time to meet current needs? How can developers (or their managers) find the expertise that they need to evaluate candidates, when it is precisely that very expertise that is needed for them to do so?
