2017 ends for me, at least in terms of software development, on a much higher note than it started.

From January till October I worked on a financial startup through Toptal. I was part of a team of between 5 and 15 people over the period, and my duties were far more restricted than what I’m used to: mostly markup and styling.

I did the work inside Ember but never warmed to the framework. I’m sure it was not because of technical matters per se, rather mostly because I perceived the framework as not picking up traction, therefore not deserving of much investment. It was hard to flow with it since auto-reloads were quite slow and the style of getting and setting values always felt strange to me.

There’s a lot I learned in this project in terms of organizing teams and the main lesson was: if you hire remote team members, embrace that fact full-heartedly. This is not to say that you either do it remotely or locally, but if you have even one team member that is working remotely, you should do everything as if the whole team was remote, otherwise the interactions will break down fast. I’d go further and say that dev teams should work as if remotely even if the team is local, persisting all relevant decisions in writing, avoiding one-to-one communication in favor of groups to save on recommunication and following the basic protocols of remote collaboration.

All the while, I kept spending some time on Elixir, and was always happy doing so even though the language has all but become hugely popular thus far.

Another significant change in my process was my move from Atom to Vim. Yes, the entry barrier is significant, and a bit more so since I use the Colemak keyboard layout, but I am very glad I did it. After a while you’re much more productive in Vim, and it’s a more direct connection between thought and writing. It took about 3 months for me to feel as productive in Vim as I had been in Atom.

Sometime in the middle of the year, a couple of fellows got in touch about starting a company in the real estate sector. After much talk we decided to join forces and we started EmCasa.com.

At EmCasa.com I was free to choose the stack for a greenfield project, and so I chose Postgres, Elixir/Phoenix and React for the web client. Postgres is the dependable relational database, with (I trust) more native support for geolocation, so I didn’t hesitate there. Elixir and Phoenix wasn’t much more of a difficult decision either: I trusted the language entirely, felt the tools are at a very reasonable point, enjoy using it a lot, and thought we could attract good developers to use it. So far it’s worked out that way, and as I get ready to hand over most of the Elixir side to a new team member, we talked to a number of pretty great developers that are fond of the language and excellent at it.

Finally, the React decision was a bit more difficult, and even though I consider myself a frontend developer, has been more fraught with difficulties. It’s hard to say I’d choose React again. I probably would, but I really don’t know if we’d been doing better with Vue.js or maybe even Elm.

EmCasa needs a lot of good SEO, so it needs server-side-rendering and very controllable html headers. It took me a while to sift through a few of the available possibilities, that being the main con of polylyths. Finally I made progress using Next.js, which has been a pleasure to use. I ended up throwing out Redux and I haven’t regretted it. I think Next.js has a good path ahead of itself.

We have a long list of ideas to implement at EmCasa, our backlog is public, and so are our backend and our frontend. If you’re reading this and would like to chat with us about joining the team, check out www.emcasa.com/jobs or write me at gustavo.saiani [at] emcasa.com.