My Year in: Software Development

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.

Live gut reactions to learning Ember.js

I am starting on a new project that uses Ember.js.

I started learning it from scratch a few days ago. Thought it would be a good opportunity to log my gut reactions while I find out how it works.

My main term of comparison will be React.js, which I started learning in about February 2015. I have spent a decent amount of time working with it. Far less than on jQuery-based projects in the past, but still. I also know a bit of Angular 1, so that may come up too.

I will go for free-associative, bullet-list, initial reactions for this post.

  • Official website is organized and pretty enough.
  • Really easy to download and have a local server running with a blank app.
  • No webpack. I like that.
  • ES6. Great.
  • Official tutorial does tests. Awesome.
  • Tutorial is very clearly written. Can’t compare to what I came across when I started with React.
  • Handlebar templates. I don’t know about that. Better than jsx perhaps? I miss jade, slim, wonder if it can work with something like that.
  • Bower? Not happy to see that.
  • All package names seem to start with ember-cli. Welcome and scary at the same time.
  • What’s the difference between a controller and the other entities, helpers etc? Still pretty foggy at this point.
  • Easy to install Stylus for CSS. Heard about “ember pods”. Will investigate.
  • Extremely easy to deploy something crude to Heroku, even without doing anything about the env.
  • Oh gosh, there’s an ember package to load Google Fonts.