As part of a new generation of leadership at Code for Boston my colleagues and I were charged with defining and building process for the organization. Some of this process was gifted to us via previous practice. Some of this process was thought out, and some of it was ad-hoc. Either way we thought we could be a better organization if we memorialize, communicate, and execute on our process.
Most recently we built a process for project intake. In our monthly leadership meeting we identified this need and decided to delegate the development of the process to a sub-committee of interested leadership members. People who felt strongly could be in the sub-committee while those who were not as interested in this particular process could sit out. As a rule we try and keep our meetings to 90 minutes in order to respect the natural attention span of attendants. In the meeting we brainstormed, discussed, and found agreement based on evidence and experience. We generated a document that was then shared and voted upon by the larger leadership team at our next monthly meeting.
What did we get for all this effort? First and foremost it made explicit the expectations by all the actors. We figured out that we needed a person willing to put in time to manage project intake. We made clear when and where leadership had to take a stance on a project proposal, eliminating the uncertainty around silence. Finally it gave clarity and certainty to potential external partners about when and where they could expect an answer to whether their project could be a part of our community.
The most surprising part of implementing this process is how much of a barrier filling out our Google Form is to proposers. Often people will on Slack or in person try and hook me or another leadership team member into a discussion about their project idea with an aim of making it an official Code for Boston venture. Despite informing them I am not empowered to make their project official and telling them they need to fill out our Google Form, many people still just want to talk about it and do not understand why their project cannot start next week. I am not sure why this is such a challenge, but my hope is that we are simply weeding out folks who would find other parts of running a Code for Boston project challenging and avoiding a bad fit.
I am in the process of reading A Swift Kickstart to learn the Swift programming language. Swift will be maybe the fourth or fifth language I am learning and so far I am enjoying it a bit more than many of the other ones I have tried to learn. Learning a language is about building the muscle memory around the words and syntax used to communicate in it. Many programming languages share similar concepts (like functions, variables, constants, etc.) and you need only map these concepts to the new syntax and conventions used by your new language.
The main thing I have learned from learning new languages is that good code can be good code in many languages and bad code can be bad code in many languages. More often than not the language itself does not impact whether the code is good. It is the skill of the author of the code that makes a difference. It is quite possible to write obfuscatory variable and attribute names in ruby as well as PHP or Python. At the same time I’ve rewritten beautiful VBScript code into Ruby with ease because the developer took the time to structure it in a way that was easily understandable.
Someone shared this article with me today and I felt the need to respond in poem.
This analysis does nothing to undo our paralysis.
The author tries hard to assign blame, but has no idea how to win this game.
He can paint people with a large brush stroke, but has he even talked to regular folk?
This was nothing novel; it was more of the same.
If government debt is our frustration,
Our solution must be innovation.
Last night I helped present a webinar for folks in the Code for America network about live streaming their events. Most of what I learned about YouTube and live-streaming came from my friend Lon Seidman whom I helped film and edit with at CES a couple years ago. You can spend a lot of money on live streaming but ultimately the goal is to get a decent picture of your presenter and really good audio.
If you are using an iPhone you can get an inexpensive lav microphone and a long cord, along with a tripod and mount to record individual speakers. However you can also invest in some fancier equipment. The equipment I used included:
- Elgato Camlink - connects camera to laptop for livestreaming purposes.
- Alta Pro Tripod - to better position the camera
- Sony a6000 camera
- Zoom/gun microphone for focused audio
- MacBook Pro
- Facebook Live
When recording I faced several challenges. The first was that the camera only transmits audio over HDMI when it is in video recording mode. Due to some EU regulations, video recording mode automatically stops on the a6000 after about 30 minutes. So I had to keep re-enabling recording mode. Another issue is that the a6000 does not recharge from its regular charging port while it is on. So having a backup battery or Sony’s official wire would have made it easier.
Ultimately it took a lot of tinkering to get to a setup that worked well and to understand the potential kinks. I strongly recommend testing your setup before trying to live stream for real.