When in React

For the past few years I have spent most of my time working on applications in Ruby on Rails. When I was the Berkman Klein Center I also had an application in a Javascript framework called Meteor.js but for the most part we prioritized back-end functionality over front-end interfaces. This means that for applications like Lumen Database the front-end was written in HTML and embedded Ruby. This past week at MAPC has been a whirlwind of updating my front-end web development skills, primarily by learning React.

The thing I like most about React is the quality of the documentation. The official React tutorial is well written and I refer to it often. Since a large number of developers are thinking about and trying to write in React there is plenty of third party material as well. It is supported by Facebook which is nice to provide assurance it will not be abandoned. There is also a testing framework called Jest that works with it as well. This is clearly mature and well adopted technology.

React is not without its downsides, however. For someone used to using embedded Ruby, the amount of effort required to build something in React is significantly more than simply doing the same thing in ERB and HTML with some vanilla Javascript. Not only do you need to know Javascript concepts but you need to learn about the JSX template language. Doing something in React requires having more understanding of state and where things live than a vanilla JS implementation. React likely shines in complex front end interfaces, which I have not played with yet, but feels more like an anchor than an engine when you’re looking to sprinkle in some front-end magic on a mostly vanilla website. One thing I continue to think about is whether there is something more appropriate for basic websites than using React.

The weird thing about Javascript is it is a language with the wind both at its back and sides. The implementations of Javascript, its package management, and frameworks is large and can easily lead to decision paralysis. The question is rarely whether Javascript itself is future-proof and accessible but whether your flavor of it is. Today React is the safe bet, but tomorrow is anyone’s guess. The world of Javascript changes quickly. This is fun for folks who enjoy learning new technology and frameworks all the time, but less enjoyable for people like me who view code as a tool for building product.

Randy Pausch on Time Management

This lecture on time management is full of great advice:

A Set of Values

As I think about my own philosophy towards software development I think it is useful to consider it in the context of values. When trying to make decisions what are the yard sticks that are used to measure them? Here are some of the values I have and use in making my decisions:

  1. Open is better than closed. All things being equal it is preferable to give a client and/or the public a view into the work and its process. Code and prototypes do a better job of communicating the current state of things and how I see a project than any other form of communication. Clients can elect to engage as much or as little as they want.
  2. The well worn path is better than new. All things being equal if something can be done with a battle tested technology it is preferable to use that than something that is brand new.
  3. Adoption matters. All things being equal the more people that use something, the more likely bugs are to be found and documentation is more likely to be available to help resolve challenges with a product.
  4. Stay in your stack. All things being equal you are better off coding something in the technology stack that you and your team have experience with than trying something new.
  5. Avoid premature optimization. As Sandi Metz has noted, there is no perfect code, just code that works for the needs of today. Whether it is code or in other things, there are lots of ideas that seem like good ideas on their own merits but are not yet necessary for today. When your application struggles to get users then security (unless you are storing sensitive information) matters less than marketing. Servers can be rebuilt, passwords can be reset. Apps can be updated or redeployed. It can feel good to secure your apps and spend time making your code even better but ultimately you need to ship your product and not go crazy. The good news is as you get experience you can build optimizations into your muscle memory. They get cheaper as they become habit. That is why people pay more for more seasoned developers.

Begun the Campaign Season Has

This past weekend was the Connecticut Democratic State Convention in Hartford. When I was younger I attended the state convention all the time and even had the opportunity to go on the floor as a delegate once. Now that I live in Cambridge I have to watch this through the eyes of others. It was a surprising challenge.

On the Internet the convention felt like 2006 all over again. Ned Lamont, who ran for senate in 2006, was nominated for governor. A few of the bloggers from the 2006 Connecticut political sphere returned and were tweeting. I enjoyed seeing some tweets from CTBob and CTBlogger. Unfortunately despite the rise of Eva Bermudez-Zimmerman and theme of new voices, the online conversation did not seem to include many new voices. The land of steady habits remains steady.

The one upside is the folks at CTNewsJunkie did yeoman’s work in getting news out. Besides tweeting, Christine Stewart was live-streaming from the floor. Despite their smaller team, they felt like they had a larger presence than the larger media outlets in the state. I am of course a bit biased because I work with Doug and Christine, but looking at the hashtag on twitter and my general Facebook feed, I did not see other news outlets pushing nearly as much from the convention. They clearly won covering this.

Sometimes the Struggle is Bad Writing

After years of learning new things in fields like business, law, and software I have learned that the biggest variable in understanding something is the quality of writing and communication. Communicating well is hard and in technical fields not enough value is placed on good writing. Communities like Ruby are lucky to have folks like Michael Hartl and Sandi Metz that are gifted with the written word. All things being equal I will typically choose a tool or programming language that is better documented than one that is new and shiny.

When I was faced with some legacy code bases at MAPC that felt bad I struggled to articulate what was bad about them. It took more than a few hours of Googling to discover Martin Fowler’s concept of code smells. These code smells provided a menu of issues that might exist in a code base along with recipes for refactoring away these issues. If you do not have the right vocabulary you will struggle to communicate. If your audience consists of experts you can assume a shared vocabulary and knowledge base, but if your audience is not then you need to start from the basic concepts before explaining the more complex things.

If you are a beginning software developer the best two things you can do are to find good writing about software, and to try and teach what you have learned to others. By getting experience in communicating new concepts to other software developers you can see where your ideas and metaphors fail. You can also better articulate the reasons for why you do things in your programming language. Communicating what you are doing well not only helps you write better code, it helps you identify good writing yourself which makes learning new things easier.

Follow Zagaja.com posts: RSS Feed
This work by Matt Zagaja is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.