The Elevator Pitch

One of the biggest challenges of my work is communicating it. Both at MAPC and Code for Boston we do a lot of things that people do not have foundational knowledge about. When I meet people outside the technology industry for the first time and describe what I do, they need to have some kind of foundation in about thirty-seconds or they are going to get lost and confused quickly. They need the elevator pitch.

The interesting thing about the elevator pitch is first getting the reaction of someone to it. Did I land it with my description? What is their first thought or question? A lot of times they do not even know what question to ask. Often it takes me giving an example or two of one of the projects that I have worked on until they understand my work.

Once I explain I work with algorithms people often see their interest peaked. Artificial intelligence and algorithms are two topics from technology that have permeated mainstream culture, but people are still struggling to figure them out. Are they really going to kill us? Will they take all the jobs? There is definitely a sense of caution and fear. The dry and mechanical attitude I see at data science conferences is quite different from the attitudes I see when I talk to lawyers and others studying them. Algorithms and artificial intelligence are going to greatly impact what machines can do, but industry is doing a poor job of communicating what the impact really will be.

Talking to a group of folk that are not inside the tech industry last night gave me a chance to evaluate how I talk about algorithms and AI. I like to talk about how we built our Youth Match algorithm with young people to help them. I am sad I did not think to explain to my fellow law school alumni that lawyers will be the ones buying algorithms and other technologies for local government. They are going to need to understand these things because they are going to impact the citizens they work for. Hopefully I do a better job of remembering that part of the story at my next event.

Security is the Opposite of User Experience

One of the annoying truisms that I have learned is that security is the opposite of user experience. Nowhere is this more evident to me than with Google and Gmail. For some reason I seem to be logged out of my Gmail account nearly once a week, if not more. This has grown frustrating because I recently installed an app called Kiwi which is supposed to make Gmail more usable by enabling some MacOS native features with the mail client. Unfortunately it means 1Password will no longer auto-fill the login. Therefore I find myself going through extra steps to log back in to my Gmail accounts on an almost daily basis.

As I build software I continue to learn that security is the opposite of user experience. In order to verify someone’s identity or make sure their data is more protected I almost always need to make a trade-off that makes an app more difficult to use. It makes it less likely they will use it. When making a game or other small stakes app this is not a big trade off. But when the stakes are either someone can apply for a summer job or not, the calculation is different. Suddenly this security is impacting their livelihood.

Ultimately I am excited by companies like Apple that are managing to make security part of the user experience. TouchID makes logging in to most apps seamless. FaceID makes it even easier. The multi-factor authentication integrates across all devices and makes it easy to confirm you are the one trying to log in to a device. As I build apps I try to think about how I can make them more like that.

The Biggest User

One of the tensions in software is between ease of use and flexibility. A lot of companies attempt to build out easy versions of already established software and then market this to developers. Or alternatively they have already done a big chunk of complicated software development work for you and offer an API. An example of this would be the rapid prototyping that was enabled by the Sunlight Foundation’s APIs. You can build great products based on them, but eventually you run into their limitations.

Once you become the biggest user of one of these APIs you have three choices: try and get the folks to engineer updates that meet your requirements, engineer around the limitations of the tool, or make your own tool. Usually I prefer to take approach two. By engineering around the limitations of the original tool I avoid re-developing the tool all at once. The downside of this is that you are maintaining two pieces of software at once, but you avoid interrupting service to end users. In consulting and government this is almost always the better choice.

Learning Styles

By far my favorite way to learn a new subject is to find a well written book or tutorial on it. I have spent many years learning about software development but did not find it to be a true joy until I found Michael Hartl’s Rails Tutorial. I have attempted to watch and follow online courses but have found that I do not retain the information as well. I made a couple of failed attempts to learn Swift using Stanford’s online course but found picking up the professor’s book to be much easier to follow. I found the same be true of learning automated testing with RSpec. It becomes easy to figure out why companies like O’Reilly Media do so well.

Lectures, in-person teaching, and other techniques rarely worked well for me. However the explosion of YouTube and video lectures has been a big leap forward. While I can gleam concepts from lectures I really enjoy being able to rewind and replay videos to understand what the speaker is talking about. Harvard’s CS50 lectures are some of the best that I have watched. A well done lecture can augment learning, but I still rarely find them as good as a book.

The explosion of coding bootcamps, college courses, personal trainers, and other pay for teaching services shows that what works for me is not what works best for many people. I have come to recognize that I am not usual. However this unusualness gives me an advantage. Books tend to be much cheaper than courses and lectures. Unfortunately while organizations are happy to give folks professional development time to attend a course, it can be challenging to convince them to give you time to sit down with a good book.

The Password Life

One of the biggest banes of my existence is dealing with passwords. In order to manage my collection I have an app called 1Password that mostly takes care of my password management. However they recently released a new beta version that has proven to be buggy. Ironically I attempted to report the bugs in their beta form and after filling out their form failed to login. Then I attempted to recover my password by putting in my username and did not get a reset email. Maybe it went to an email address I no longer own. Either way I instead decided to report my bug via twitter.

1Password has shown me that I have a huge number of passwords. My 1Password database contains 872 items, and out of them 625 are over 3 years old. I rarely change my passwords and do not have the energy to go through 625 logins to be more secure. This is why I am excited by new systems like Apple using FaceID and Apple Watch to secure accounts. I would be able to authenticate without needing to know a password for each website. The most surprising thing to me is that you can already use Apple’s APIs for payment but they have not extended them for web logins yet. As a user and web developer being able to login using Apple’s system would be a huge leap forward in not needing to keep track of nearly 1000 passwords.

Finally the biggest challenge with password management to me is the fact I keep getting logged out. Despite trying to use a third party application to stay logged into Gmail and trusting my computer I am asked to sign in almost every other day. When I do certain things on GitHub I am also asked to re-confirm my password. Ultimately if I am using a device that I am authenticated to, I want to be able to stay logged in. It might not be perfectly secure, but the cost and annoyance of having to login all the time is huge.

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