By Masha K.
Sep 26, 2017
This September is Spectory’s last month with one of our projects, a startup based in the U.S. After close to a year of working with this company, I’d like to take a moment to look back and summarize what we – the developers – learned from it.
While working at Spectory most of the projects I had prior to this one were AngularJS + Rails SPA, data-driven, client-side and server with json end-points apps. So, when I first looked at the source code, I was excited. Finally, clean Rails!
It was going to be so much fun working on a classic Michael Hartl-style Rails & Bootstrap application. No matter that it’s a legacy project – started in mid 2014 – as long as the code is readable and we’re given some time to learn the architecture, we’re good.
And time we were given. But who learns a project by reading code? Nobody does. You learn by doing, and if you’re doing and not learning, chances are you aren’t gonna learn at all, even by re-reading through all the codebase twice.
My first task took weeks to finish, not only because everything had to be rewritten a couple of times after code reviews with the company CTO, but also due to a complex architecture I had to make sense of in the process.
After that one, further tasks were much easier, because for each new module I studied, I could guess how it works based on what I’ve seen before.
Thus, lesson 1:
Look for patterns in data flow to understand the architecture better. There’re always patterns, because creating and detecting patterns is one thing developers are good at.
And, by the way, lesson 2:
Ask for external services credentials ahead, or face the consequences of two-factor authentication linked to a phone number that isn’t yours. I consider myself a time zone expert by now, but no level of expertise can help in getting hold of a person who sleeps when you work and works when you sleep. Well, at least they won’t bother you while you’re in the flow!
Another challenge we faced: communication with the account administrators. It turns out they weren’t happy at all with the 11-hour gap between us! Huge surprise. Think about it: There are customers dealing with sensitive data while using your website, and the website is full of bugs – of course. Support will write you an email with the magic word “urgent” in the subject, and then you either know what’s going on and can fix it as fast as you can, or you have no idea what they’re talking about. In the latter case, the fix is delayed at least until the next day.
Over time, we’ve developed a common language with the account admins, and making sense of the requests and bug reports became much easier. Knowing the architecture better, surprisingly, didn’t make a huge difference in our ability to understand and fix the issues. But better communication did.
This brings us to lesson 3:
This is the one we usually learn the hard way… If you have to collaborate with another party, make sure you understand them and, more importantly, that they understand you.
In short, don’t be like that dude who worked on the project before you. Their code is always the hardest to understand, isn’t it? Every time I start a new project, with each chunk of code I go through all stages of grief – denial, anger, bargaining, depression – before finally accepting my new reality.
A good developer will make a point of being understood by anyone who has to deal with their code in the future. That’s a sort of communication too! And a damn hard one to master.
So, how do you make sure you’re being understood by the poor soul who takes over the project after you’re done with it?
Good documentation. Or, better yet – good self-documenting code. Ah, I know this one – you say – that’s going back to the basics! That’s right. And the previous development team took these basics to the next level. When it came to writing feature and regression tests, their dedication is striking, for I’ve never in my life seen a project so thoroughly covered with tests. Some people will call it overkill, I call it caring about the project and the people who will work on it after you.
You should care about the code, but care even more about the people that must deal with it.
By the end of this week, the project will stop being our responsibility. Other developers will start working on it full time, and when (and if) they leave, the project will live on – hopefully.
I believe Spectory does its best to follow the example set by the company CTO and their previous team of developers, making a given project at least a bit better than it was before, and our successors will have as good a time working on it as I did.
It has been a great year working with you all!