Code for America Summit 2018

Much of the break in blogging for the past week has been the result of spending the latter part of last week at Code for America Summit in Oakland, CA. I traveled to California on Wednesday with co-workers from my group at MAPC and friends from Code for Boston. It was great to see many facets of Boston’s civic technology ecosystem represented in the talks and sessions. Conferences are important both for taking time to meet and learn from peers, and to take time to be reflective. I was lucky to experience both.

One session that stood out was one on agile software development put on by the Code for America engineering team. One of my goals for my own engineering team has been to adopt more agile practices. Having an example in the civic technology world of another team that follows these practices is a helpful role model. In government it can be challenging to be the first one to adopt something, so having peers that have adopted it first makes a big difference when going to management. While I am a strong believer in meeting people and organizations where they are, sometimes people and organizations need to realize they are not special exceptions where the best practices will not work.

I also experienced my first AirBnb. It was not a bad experience but certainly less convenient than a hotel room. While we had a very nice apartment, the apartment we rented for the weekend was not in the convention center and only had two pairs of entry keys for three people. While the price and value of the apartment we rented was fantastic, having an entire apartment with a big kitchen felt like overkill merely for sleeping at night. Finally in a conference situation there is lots of time with people, and while I enjoy my co-workers company, it would have been great to have a space to be completely alone. Overall while I am willing to use an AirBnb again, I will likely prefer a regular hotel room in the future.

Getting to Inbox Zero

For the most part I try to keep my inbox “near zero” but know that getting to real zero can be a challenge. The first part of the challenge is mental. No matter how hard you try it can be difficult to stop your inbox from becoming the “place where important stuff stays you do not lose it” which it should not be. The second challenge is that it can also become your to-do list. Most people suffer from the worst possible scenario: it becomes the place where important stuff stays and also your todo list and it becomes hard to distinguish how much is from one bucket or the other.

I have a few components to processing my inbox. First I have mastered GMail’s keyboard shortcuts. With single keystrokes I can open, reply to, and file away emails. This lets me rip through them at a much more aggressive pace than with other clients. Second is I take time to unsubscribe and filter emails I receive regularly from vendors. This part sucks but it pays dividends down the line. Each unsubscribe lowers the daily noise of my inbox. Third is I use filters to “skip the inbox” for things I want a record of and receive regularly. Most often these are recurring bill notices that are already on auto-pay. I wish I could have a “negative filter” on these that would alert me if I did not receive an expected one. Ultimately the goal is to automate as much as possible and find signal in the noise.

The weirdest part of email is that while it appears to have been solved in a web client, mobile remains a free for all. Apple’s Mail app on iOS works fine but lacks some of the polish and features of the Gmail app. However the Gmail app struggles to work well with Siri and contain all the offline archiving of my messages that the iOS app has. Personally I miss the Mailbox app.

Ultimately the state of my inbox is usually a reflection of how on top of things I am in life. The more frazzled the inbox is, the more behind I usually am in life. It always feels good to get back on top of the inbox and todo list. Spending time to do this pays many dividends as I go through my week.

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.
Follow posts: RSS Feed
This work by Matt Zagaja is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.