That one project I've worked on: in conclusion
This September is Spectory's last month with one of our projects, a startup based in the US. After close to a year of working with them, I'd like to take a moment to look back and summarize what we - the developers - have learned from it.
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 gonna be so much fun, working on a classic Michael Hartl style Rails & Bootstrap application. No matter that it's 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 one: look for patterns in data flow to understand the architecture better. There're always patterns, because creating patterns is one thing that developers are good at.
And, by the way, lesson two: 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, and it turns out they weren't happy with the 11 hours gap between us at all! Huge surprise. Think about it: there're customers dealing with sensitive data 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 fix it as fast as you can, or 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 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. It brings us to lesson three, the one we usually learn the hard way: if you have to collaborate with another party, make sure you understand them and, more importantly, 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 the basics! That's right. And the previous dev 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 an overkill, I call it caring about the project and the people who will work on it after you.
Lesson four - care about the code, but care even more about the people.
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 did our best to follow the example set by the company CTO and their previous team of developers, making the 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, guys.