What We Do Not Do Well

When we run Code for Boston the majority of our new members find our group on Meetup and do not have a great understanding of who we are or are. In order to help people understand what we do we run an orientation session for all the new members. It helps them understand our organization and how we work. We spend most of this orientation explaining what we do, but we also spend a good part of it explaining what we do not do.

The main thing we disclaim expertise in is teaching people to code. The reason is that people who are good at coding are not necessarily good at teaching people new to coding how to do it. Furthermore most of our members do not show up to Code for Boston hoping to teach others how to code, but rather to contribute to a specific project. There are different phases of learning and we are good at taking folks who have taken a boot camp or gone through their own tutorial and project and helping them learn how to contribute to software projects in a group setting and give them an opportunity to be mentored and learn from peers.

Another thing we know we are not skilled at is marketing and user acquisition. Although we may have some members with skills in those areas, most of our members are not MBAs. So we get around that barrier by making sure our projects partner with a government or non-profit that has an existing user base they can reach out to. We often tell people that our best projects “help the helpers” do a better job. I have yet to find a marketers for Boston that can help us with this part of the equation but whenever someone wants to collaborate with Code for Boston and thinks that we’re going to bring the users, I usually warn them that is not the case.

These are not the only things we do not do well, but it is always helpful to understand some of the things we do not do well so that partners and participants are not disappointed. It also helps us shape our projects to work around these barriers and find partners that can help with that. We also see these as future opportunities for our own growth. It is clear to me there is demand for workshops so we are working on putting together workshops on topics like data science so people can learn more skills and participate in future projects.

Legacy Software

I thought that Mark Headd had an interesting tweet yesterday:

This tweet gave me a few thoughts from my own experience that I shared:

After a couple legacy app rewrites (not from mainframes but old Python Django —> Rails) you quickly learn how tough it can be when the best you can do is “match” what was there before. Apple still has whiplash from Apple Maps and that was years ago…

Things I’ve discovered about legacy software:

  1. Undocumented functionality is discovered by users. Turns into an “important feature”
  2. Users map their own abstractions into the existing system as the real world system changes but software stays stagnant.

Also after writing software on a rather stressful deadline for a City of Boston project I expected it to get junked after. Instead they opted not to rewrite. It’s not the best code I’ve written, but it was battle tested. Never realized how important that was until gov’t.

Ultimately rewriting legacy software often “feels” like the right thing to do but the distance of the rewrite feels like it is less than it actually ends up being once you attempt to do it. It is not that it is never worth doing a rewrite, but the value of the rewrite often is less than you initially think it will be.

Apple is Rebuilding Apple Maps from the Ground Up

Interesting to see Apple’s deep focus on updating maps:

It’s doing this by using first-party data gathered by iPhones with a privacy-first methodology and its own fleet of cars packed with sensors and cameras. The new product will launch in San Francisco and the Bay Area with the next iOS 12 beta and will cover Northern California by fall.

The Magic of the Stars

One of the tricks I have recently learned for Slack, the chat program, is that they have a star system for messages. The star is a feature I have seen but I did not understand how to use it that well. After reading a page in the Slack documentation I learned stars are a todo list. It is not to be thought of as a bookmark but as a way to keep track of posts that you have to take action on. Suddenly the stream of overwhelming stuff is tamable.

Once I learned that trick, the stars in Gmail suddenly made a lot more sense to me as well. Now I use Gmail stars as an indicator of things I need to take action on or am waiting for others to take action on. No longer do those messages sit in my inbox. Stars no longer indicate random emails I thought were important. Instead they are this special place where I go to get things done.

The lesson of this is that sometimes the purpose of a feature in software is not obvious. While many software developers have done a great job of designing their software to be usable without a manual, sometimes reading good documentation can make a big difference in making the most of my tools. The best part is when different developers follow the same patterns or trends, learning something in one software program like Slack then easily transfers to Gmail. Everyone wins.

(Also if you need keyboard shortcuts for a web application try hitting “Shift+?” on a website. You will often get a reference card with keyboard shortcuts.)

The Sleep Experiment Part 2

After spending a week trying to increase the amount of sleep I get I have been unable to push myself to be in my bed for than seven and a half hours. However the difference between under and over seven hours feels like the world. Yesterday waking up with nearly six and a half hours was a bit of a struggle for the day. This morning I woke up with seven hours and twenty minutes and I feel great. I am not sure if I will ever successfully push eight hours, but today writing this blog post was easy, while yesterday I missed it.

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