Category Archives: React.js

My Year in: Tech

I started the year of 2019 as a front-end developer at Toptal’s core team. Just a few days later, I was invited to be Team Lead for a brand new team.

My emphasis turned, again, to working with people. That was a delight and I fully embraced the opportunity to help build a team. We had a few company veterans enlisted to start the new team, all of whom I had not worked with before, and we needed to hire two more front-end engineers.

The first recruitment process was for an excellent React engineer. It was done very deliberately and unhurriedly, to make sure we raised the overall level of the team on the React stack. It took us a little over 2 months until we found a great guy, who has contributed a lot this year.

The second engineer was a gift to us, as he was initially hired for another team. Happy to say he’s also doing tremendously well.

We quickly became a real team. It seems we did a few things that helped: communicating a lot, admitting mistakes and ignorance openly and quickly, and being real human beings.

One teammate brought along the Personal Questions call from his previous team. This call has a simple structure: one team member asks one or two questions, personal as the name says, to everyone on the team.

The questions are as simple as “What was the best trip you ever took?”, or “What is your favorite dish?”. It’s up to the team to let this call become just a little window on who they are, or a huge gateway to people’s souls. Yes, it’s possible to cry while listening to someone tell you about their favorite food once they tell you the story behind it. The bond I felt with the team was immense.

Dedicating at least one or two hours per week of each team member’s time to building rapport makes a big difference, particularly in new teams. Next year I will work to learn more ways of doing that.

I made my share of mistakes. The one that comes strongest to mind is about having patience before giving feedback to people you may like personally but don’t think are doing a good job — especially when they are not reporting to you. Convincing people to change is hard enough as it is, doing it without mutual trust and knowing their motivations is likely to backfire.

Another lesson I was reminded of by a mistake of mine is the “no surprises rule”. It’s often hard to know, in advance, how sensitive some task or decision may turn out to be. Next time something I do starts to deviate too much from what was agreed-upon, I should remember to share that early on, and avoid surprises, because the surprise itself may make people react negatively to something fundamentally desirable, or I may have the wrong assumptions or decisions and other points of view will help me see that.

I stayed with the team for a total of 9 months, we launched a good chunk of the new application we were developing, and then I was enlisted to start a new team from scratch: to recruit every single engineer, and help recruit designer and product manager.

It was painful to say goodbye to a team I loved so much.

Soon it was back to recruiting, this time a few weeks of full-time effort, and we are still at it. We seem to be close to hiring two people, and have one more front-end and one more QA person to bring onboard on the engineering side.

This recent team switch gave me time to study programming after a several-month hiatus. I am focusing on new React APIs, from Hooks to Context and Suspense, as well as testing, TypeScript and, soon, Apollo.

I did continue to study the Elixir language source, something I’ve done for maybe 3 years now. This year I did relatively little of it. I love Elixir just as much as always, and am thankful for having learned so much from its community.

I plan to go multi-team as soon as I have a chance, be it in an Engineering Manager or CTO role. Thus I dedicated more time than ever to reading about leadership, management and communication, often with a big emphasis on tech. Especially for people who are new to management, I recommend The Making of a Manager by Julie Zhou.

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.

React.js, Facebook JS SDK and a costly little mistake

Last week I spent much more time than I ever wanted implementing Facebook login in React.js.

As it often turns out to be, one mistake cost me about 10 hours net of investigation, and if you don’t have time to read further, here’s what was wrong: I had added all my <script> tags inside <body> in the html, and then used <body> as the element to replace when rendering my main React component.

That was it. But what about that mistake is making me stop and write about it?

First: my app worked perfectly for a long time just as it was. Weeks. In the beginning of the project I was switching back and forth between two different build systems, and when I decided on one I must have copied the main React component and nothing pointed out an error.

Second: Facebook login kind of worked perfectly in localhost. The only strange thing I noticed was that, as I loaded the js sdk into the html, the most important sdk method, FB.init, was never found.

Since I am no React master at this point and Facebook provides no documentation on how to integrate FB login to React, even though they’re all made by FB, I had many possibilities to investigate. And lo and behold, by moving the FB.init call to the React component inside componentDidMount, everything about the login worked in localhost.

When it came to the staging environment, however, things got weird. My app would not get the login status on load, but on clicking the login button, the modal dialog would open. Sometimes the window would come up blank, sometimes it would prompt for login and then never close, and many other different outcomes.

Since most recent blog posts on Facebook login deal with difficulties with OAuth settings, my investigation went that way, and there it stayed for a long time. No warning or error message ever gave me the slightest clue as to what I was doing wrong.

Thus a mistake that arguably should have made my app break on the very first run ended up taking many hundreds of runs before the bug was caught.

———————

Follow up:
React 0.14 warns against this.