Javascript Tips and Traps

I have been spending a lot of time learning modern Javascript over the past month or two. From this there are a few key tools and tips I have picked up:

  1. The filter and map functions are the main tools you end up using to manipulate arrays and hashes.
  2. You can avoid lots of scoping problems by using arrow functions. However you cannot always drop arrow functions into non-arrow function examples. A lot of it has to do with understanding the use of this for scoping. Many times if something is not working as expected, sit back and evaluate your scope.
  3. The debugger; command can drop you into your console at any point in your code. It is the Javascript equivalent of binding.pry.
  4. If you want to make it easier to debug your code in the Javascript console make sure you are generating a source map with your code. Some frameworks give this to you by default. Some frameworks require you to specify this in your configuration file.
  5. In Sublime Text using full project search can give you lots of noise when globally searching a Javascript project that compiles to minified code. Make sure to ignore your compiled source directory when configuring your project file or you can globally ignore directory names if you use the same names consistently.
  6. If you need to grab a JSON representation of an object JSON.stringify(emberModelObject); can be your friend, at least in Ember.

Setting the Right Goals

I really enjoyed John Doerr’s TED Talk on OKRs:

However I found the Google OKR playbook to be extra helpful. I have not used OKRs in the past but found the challenges with them to be well enumerated in this Google document.

Team managers are expected to assess the resources required to accomplish their aspirational OKRs and ask for them each quarter, fulfilling their duty to express known demand to the business. Managers should not expect to receive all the required resources, however, unless their aspirational OKRs are the highest priority goals in the company after the committed OKRs.

In some ways the magic of OKRs appears to be that everyone in the organization is setting their goals and resources are being allocated in the same way. The act of writing goals down in a big organization and having folks at the top write their goals down before the folks that are individual contributors helps create alignment. OKRs are a two way street. If the folks at the top are not doing them, then it makes it much harder for folks at the bottom to write OKRs that are in alignment with the goals of the organization.

The Punt

One of the biggest cultural transitions from working a political campaign to working in government and running Code for Boston is that I am no longer surrounded by Type AAA personalities that all want to be leaders. When I worked for the Connecticut Democratic Party you would go to a meeting and folks would fight for their ideas. There would be a battle for the floor in meetings. People would press each other to make decisions. This difference in personality brings a lot of strengths to the group. Empathy, compassion, and openness. However it also leads to one pattern that is very challenging: the punt.

The punt is paralysis. When a group of people are charged with making a decision and do not know the answer they can be quite skilled at not making a decision. Sometimes it is to avoid conflict. They do not want to appear to disagree with others and upset the group harmony. Other times they do not want to take on the risk of advocating for a position that later fails. The punt happens when an email is ignored. A decision can be tabled at a meeting. Discussion happens but a conclusion does not. Suddenly the group lacks a mandate or direction.

Solutions to the punt can vary. You can simply charge ahead. However you risk wasting time and effort if the group does not follow through. If the folks in charge are the ones punting then there is not much you can do other than press them on making the decision. If you can find urgency to force a person or group to make a decision then they will do it. Otherwise the punt may simply be a pocket veto. Often times folks are too afraid to say no to something so they punt instead. In politics they teach us that maybes are often the same as a no (and a yes can be a maybe).

My favorite way to handle this is the Jeff Bezos’s disagree and commit framework:

Second, most decisions should probably be made with somewhere around 70% of the information you wish you had. If you wait for 90%, in most cases, you’re probably being slow. Plus, either way, you need to be good at quickly recognizing and correcting bad decisions. If you’re good at course correcting, being wrong may be less costly than you think, whereas being slow is going to be expensive for sure.

Third, use the phrase “disagree and commit.” This phrase will save a lot of time. If you have conviction on a particular direction even though there’s no consensus, it’s helpful to say, “Look, I know we disagree on this but will you gamble with me on it? Disagree and commit?” By the time you’re at this point, no one can know the answer for sure, and you’ll probably get a quick yes.

The punt is a challenge I still am trying to find good patterns to surmount. However I am a strong believer that making clear decisions quickly often is a better alternative to making decisions later.

What a Strong Economy Fixes in the Labor Market

An interesting insight from Annie Lowry at the The Atlantic:

More than that, Iowa’s tight labor market has forced employers to offer training, reach out to new populations of workers, and accept applications from workers they might not have before — expanding and up-skilling the labor pool as a whole as a result. “Their attitude really seems to be changing,” said Soneeta Mangra-Dutcher of Central Iowa Works, a workforce-development nonprofit. “They are looking at populations differently, who they they should be looking at when they have jobs to fill, or people being screened out for things that really don’t have an effect on the job.”

Often times “we cannot find the right worker” is simply code for “we are not willing to pay the right worker” or to train them.

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.

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