The best company I ever worked for
InakaESI is dead. The brand might still exist for a while — I don’t know the exact plans Erlang Solutions has for it — but whatever happens it will never be the InakaESI that I helped build and grow. The company, the projects, the people, the culture are there no more. But its legacy will live forever (or at least for a long time, you know how we hate infinities in our industry).
It’s Inaka!
I could’ve devoted this article to analyze why Inaka ended the way it did and look for reasons and causes. But on that front I still have more questions than answers, actually. And in true inaka-fashion I prefer a different approach: I prefer to focus on what was great about the company and its people. What made it my favorite company so far.
Ever since I left the company (not even a month ago), I’ve been telling Martina (ex-CEO) the same thing over and over…
We should feel proud. We did many amazing things there!
When I started with that, it was more a feeling of mine than an actual fact. But since then, I’ve been talking with many other x-inakos (more on that, below) and they all agree: The way we worked and the things we created at Inaka were impressively good. The lessons we learned while working there, we carry them on to our new jobs and they’ve proven successful over and over again.
So, I thought about sharing 3 of those lessons with the world. Maybe someone else can also benefit from them…
People Growth
Inaka always had a pretty horizontal company chart. We eventually ended up having a career path, but it wasn’t the kind of path you would find in other more hierarchical organizations. We actually encouraged people to be in multiple places within the career path. We privileged flexibility and personal growth over career growth.
That’s why many many inakos left the company with a triumphant exit: They started their own companies or joined a much bigger company as experts on their fields, even when by the time they joined Inaka some of them were junior devs.
And we still hang out together. We have a Slack team created by one of our most talented x-inakos that’s currently living and working from The Netherlands. While the company was active, we had that once an inako, always an inako attitude that allowed every x-inako to freely walk into the office and just stay with us there for as long as they wanted. And many x-inakos (either locally or remotely) gave talks and shared their knowledge with the current inakos freely, since the company provided a space for that.
I think the lesson to learn here is:
Don’t try too hard to retain your employees, help them grow and be proud of them when they do.
Software Quality
I think the other main characteristic of Inaka’s work, besides the amazingly talented people that worked with us (or actually because of them) was the impressive quality of the software we produced and the way we worked on it.
There are so many valuable lessons, including:
- Learning to see software through the computational models lenses and the heuristics Hernán Wilkinson taught us.
- Being ruthless in terms of automatic testing and code coverage (as you can see in all of our open-source projects).
- Defining guidelines (and sometimes even creating our own linters) on how to work in any language that we had to use and being super-thorough in applying them through honest and intense code-reviews.
- Always looking for the best tool for the job and not following the hype of the moment.
- Maintaining a constant eye on the evolution of our projects, the tasks involved in them, the milestones, deliverables, etc. and communicating appropriately with the clients.
- Dedicating time to manual testing and QA for all of our projects (including the open-source ones).
- Scale-testing all of our servers and performance-testing all of our apps.
…and there are many more. While working there, I thought these things were common practice among the software community. Given the sheer number of books, articles, etc. written and published about these subjects everywhere, I assumed at this point in time, every software developing company should be working that way (or in a different way, but following the same goals).
Turns out, that’s not the case. To exemplify, I’ll paste below a couple of (translated) messages found in conversations we have on our x-inakos Slack team:
- From an Erlang dev:
My fellows: never forget how wonderful Inaka was!
In the code I’m working on right now…
- Macros! Macros everywhere!
- header files
- dialyzer? what’s that?
- Elvis? The singer? He’s dead, man
- and don’t even get me started on testing and coverage!
- Someone who left Inaka not so long ago…
Same here. Many times I see stuff written without any thought and I faceplam heavily.
- Another dev that suffered my relentless write some tests for that! messages many many times…
Where I work they don’t have any kind of tests for their servers… and for the apps, they don’t even think that’s possible.
- From a developer with a lot of experience before Inaka…
Your “don’t use ifs” talk was a turning point in my professional life, Brujo.
- About code-reviews, pull-requests and the like…
> Worklfows? When I get to the company I asked what’s the workflow here and everybody stared blankly at each other… just push to master!
> First thing I thought when I saw /network in the repo I’m working on was: Brujo’s eyes would bleed!
- And look at this convo between 3 different x-inakos:
I just wanted to let you know that each day that goes by I realize more what a great technical and human level we had at Inaka.
I agree 100%… I miss the simple fact that we could think through a design before writing code and we were not constantly fire-fighting and dealing with shitty code because nobody takes a time to think stuff through properly.
Over here I work with two junior devs and they told me “wow! you have tests! That’s nice […] When we write code we only think of input and output. It doesn’t really matter how the code looks, if it’s tested or maintainable…”
As I said before, these things have been said all over the internet and outside of it as well for a long long time already. It baffles me how many people are not following good practices, like TDD, code linting, code reviews, proper git usage, etc.
Ensuring your code is maintainable should not be a second thought. It should be top-priority from the get-go. The tools to help you are out there. Use them!
Openness
The third characteristic I want to point out about Inaka was the way it was open to the world. From the very first days of the company, Chad and I forged a tradition of sharing everything we could through open-source projects.
That tradition evolved over time and by the end of it we not only shared code, we also shared our guidelines, the very definition of how we worked and many more things.
That focus on sharing lead us to have the amazing list of projects you can find at inaka.github.io. It also encouraged us to be an integral part of many developer communities and sometimes even build them from scratch. We were invited to talk at conferences and everywhere we went we could organize meetups and show local communities what we did and how. That, for each inako, meant that they can show the world what they do and that helped a lot with the Personal Growth I described before.
Also, having our code exposed out in the world meant that we had to have a keen eye on its quality. We were aware that our prospect clients would be able to see what we do for themselves and we loved that! We used (and we keep using) those open-source repositories to tell others: Look! This is how we roll! This is Inaka! And that contributed heavily to our passion for good software and quality in general. It’s all a virtuous circle.
If you are going to learn anything from this…
Be open! Expose yourself, your company and your work. When done right, sharing is rewarding in more ways than you can anticipate.
