the juxtaposition of your face. and your breath.
upon my face. and my breath.
we make time forget to clock in.
the juxtaposition of your face. and your breath.
upon my face. and my breath.
we make time forget to clock in.
Our scene opens on a charming coffee shop on the edge of the Boston commons. It’s a crisp autumn day and I’m grabbing a midday pick-me-up with an aspiring entrepreneur friend, who has just informed me that she (or he) has enrolled in an intro to computer science course.
“Cool!” I’ll exclaim. Then, with a raised brow, I’ll often inquire, “What are you hoping to get out of it?”
Invariably, my friend will patch together a response involving some combination of the following two reasons:
…I usually respond with a dejected sigh. This is a scenario that I’ve experienced more times than I can count, and each time I’m two parts excited by my friend’s initiative and by the prospect of future CS-related banter, but one part concerned that my friend might not get what he (or she) wants out of the class.
The fact is, neither of the above responses are great reasons to enroll in an introductory computer science course (hereafter, “CS intro”), and here’s why:
If you’re looking for a high-level survey of technology, a CS intro might seem like a lot of strange “busy work” to you. This is because computer science is less about technology and more about mathematics and practical applications of theories, algorithms, and data structures. More than anything, studying computer science taught me how to think rationally, solve problems, and design and build machines that could do the heavy lifting. That knowledge has a very practical application in modern technology, but to think that CS deterministically leads only to that end would be a regrettably narrow interpretation of the science.
Now, by no means do I wish to imply that a CS curriculum won’t provide a great high-level survey of technology. It’s just that it’s not quite the shortest path to it.
Perhaps you may choose to take a CS intro because you believe that getting a taste of code will empower you to better communicate and connect with engineers. This makes sense, ostensibly, and indeed it is the most common reason I’ve heard for enrolling in a CS intro.
The sad truth, however, is that it would take years of learning and coding (plus a bit of talent) to really go toe-to-toe with a great engineer. And while you may gain some respect for completing a CS intro, that “Hello World” program isn’t going to make you any more relevant in technical discussions and decisions. In fact, your respect and relevance as a manager or colleague to engineers is probably most beholden to your effectiveness at translating business needs and managing resources and expectations. Computer science really has little to do with it. No doubt that CS literacy would help lubricate your interactions with engineers, but if you are currently a tech n00b and only have one semester’s worth of time, you would be better served learning high-level stuff and working on your communication skills than taking a CS intro.
As an aside, there are in fact a couple good reasons why I would recommend that someone take an introductory computer science course:
If you want to learn to code or you are considering becoming an engineer, an introductory computer science course is a great place to start. You’ll start building your development toolbox and learn the basics from which you can launch a great career (or hobby) in code. It takes time to gain a solid foundation, but it’s well worth the effort.
I am always a proponent of learning for learning’s sake. If you are interested in or passionate about something, by all means please do whatever it takes to dig deeper. At the same time, it’s important to know what you want to (and stand to) gain from an experience. Do things deliberately so that you have the best chance of accomplishing whatever it is you desire. And be in touch if you do end up taking a CS intro! Look forward to chatting soon.
Picked up an Ableton Push a couple months back. Finally found some time to play around with it – here’s the first track.
Think it probably sounds best with headphones; I don’t know how to mix/master.
The following is a thought piece I wrote for the internal Plastiq wiki. I wanted to share it in case others may find it useful for their place of work. Please be in touch with any questions, comments, or suggestions! A document like this only gets better with iteration.
Meetings are useful for two reasons and two reasons only: information sharing and decision making. A meeting should be called for one, the other, or both reasons.
Importantly, when I refer to “meetings”, I don’t mean ad hoc chats that may arise spontaneously around the office, although it’s important to be mindful of those too. Rather, meetings in this context refer to a time and place reserved for a set list of attendees to gather together and accomplish a well-defined goal. They can range from the informal (one-on-one catchups) to the formal (exec weeklys), and generally they would be well-served to follow some general guidelines.
So, without further ado, here are my 11 tips for productive meetings (in no particular order):
If a meeting starts at 2pm, that means all participants are prepared, present, and ready to collaborate at 2pm. Being ready and on time for meetings reflects not only respect for other peoples’ time, but also a mature understanding of the fact that as a start-up, time is the our most precious resource. Five people waiting five minutes for a sixth person to arrive to a meeting is nearly half an hour of work time that could be spent in more productive ways (including relaxation!).
Everyone should know the purpose of a meeting when they arrive (i.e., what information sharing and decision making will be expected). This enables participants to come thoughtfully prepared and ready to roll. If the purpose of the meeting cannot be clearly defined, reconsider whether or not it is really necessary.
A good meeting is both structured yet allows for open dialogue amongst anyone who wants to raise their voice. The agenda should serve the purpose (point #2) of the meeting, and outline what information may need to be shared and what decisions may need to be made.
Like a company, meetings need leaders to keep them on track. This is usually whoever calls the meeting, but may not be, provided the leader knows they are actually the leader. Good meeting leaders facilitate information sharing, constructive discussion, and decision-making. They don’t dictate, but bring everyone together toward achieving a clearly defined goal. Meeting leaders / facilitators are also responsible for stepping up to enforce the guidelines outlined here. For example, if someone violates the “every comment should be additive” guideline, the meeting leader should acknowledge it (and if necessary cut it short) in order to facilitate meeting progress. Importantly, leaders should not do this in order to call out a specific person as violating a guideline (indeed, sometimes the most important thing they can do is self-police), but they should make it clear that it’s for the good of everyone involved to keep the discussion moving.
As elephantine as we may believe our memory capacities are, things always tend to get a bit hazy with time. Notes don’t have to be as specific as “meeting minutes”, but they should keep track of points that drive a meeting toward accomplishing its defined goal. Good types of things to keep record of include:
Meetings are the opposite of Vegas – what happens in them absolutely should not stay within them! After a meeting concludes, here are some best practices to ensure that it ends up useful:
It’s just as important to consider who will not be invited to a meeting as it is to consider who will be invited. The invite list should be precisely tailored toward the goal of the meeting, and should include only those individuals absolutely necessary for:
Note that proxies for sources of information and decision-makers are often a good way to optimize a meeting’s invite list.
Meetings often follow the rule of diminishing returns – that is, it’s tough to be “on point” and productive for longer than an hour or so. If you see folks’ eyes glazing over, it might be worthwhile to take a break or cut the meeting and reschedule another time.
Non-adherence to this guideline is perhaps the greatest source of wasted time in most meetings I’ve attended. It’s very easy for this guideline to be broken because those three descriptors exist on a continuum of grey, rather than black and white. Therefore, it’s up to the leader of the meeting to play a big role in establishing an instinctual threshold for each (see point #4 for more information). Basically, comments should be:
It should be considered an incredible opportunity to have people join together for a meeting to accomplish a specific goal. Everyone should be engaged in the present discussion. No matter how well people think they can multitask, taking any attention away from the present dialog is a disservice to the other participants who are giving up their time to be present. Participants should keep each other responsible about this rule, because using electronics in meetings follows the broken window theory – one device in use begets more devices in use, until everyone except the person currently talking is on their phones / computers.
This is an extension of the notion of respect for peoples’ time, as it applies to everyone not in a meeting. I have seen meetings of five people interrupted by a single person knocking on the door to tell one of the attendees that they “sent you a response to your email about that thing”. Such distractions are just impractical. If someone really needs something urgently from an individual in a meeting, he or she should write it on a note and slip quietly into the meeting to give it to the relevant meeting participant.
An unabashed list of some of Dan Choi’s actual foibles:
My socks almost never match – not intentionally, though probabilistically. A year ago I threw away all of my black socks and now my drawer is entirely furnished by different pairs of Happy Socks from which I pull two at random each morning.
When I dress more nicely, I have a habit of acting more eccentric in public. My theory is that no one assumes a guy in a suit is a crazy homeless man, so I tend to take the opportunity to let my wild flag fly a bit more.
I meow. Unintentionally, most of the time. One time in front of a room full of strangers. Another time someone legitimately thought there was a cat in the room, and I was too embarrassed to say anything.
I buy dress shirts and blazers from H&M; purchase jeans, slacks, and polos from Banana Republic; wear Skagen watches; get suits tailored; and collect t-shirts from events, clubs, and companies. Almost without exception.
I make an active effort to not eat beef. I think it’s for dietary reasons, though I’m honestly not sure.
I habitually use too much laundry detergent and far too many dryer sheets.
I cannot functionally brush my teeth unless I’m standing over a sink the entire time. Toothpaste foam builds up in my mouth at an astonishing rate. I honestly don’t understand how people can brush their teeth while doing other things.
At the end of a long day, I have a somewhat strange unconscious ritual for taking off my socks. I pull one sock off using my toes on the other foot, and then I pull the other sock off with my newly freed toes, rolling the first sock I took off inside the second (all of this solely using my feet). I then swing the sock around, bashing it into my leg and other objects – the other sock in a ball at the end to aid in the momentum. I guess it’s kinda difficult to explain, but people who have seen me do this know what I’m talking about.
At almost all times, I keep a black or blue Pilot G2 0.7mm pen clipped into my left front pants pocket. When I’m wearing a blazer, it’ll usually occupy my left inside chest pocket.
I can be a crabby patty in the mornings. I started drinking coffee regularly two years ago, when I realized it made people fear me less in the mornings.