I recently finished reading Thinking, Fast and Slow by Daniel Kahneman and highlighted around 30 different passages. One of the benefits of taking a bus to work is having time set aside to read everyday! I’d like to write a number of shorter posts on different highlights, but we’ll see if it ends up happening. I’m a huge fan of the book and everything it exposes about human psychology. The central thesis of the book as described by Wikipedia:
The central thesis is a dichotomy between two modes of thought: “System 1” is fast, instinctive and emotional; “System 2” is slower, more deliberative, and more logical. The book delineates cognitive biases associated with each type of thinking, starting with Kahneman’s own research on loss aversion. From framing choices to people’s tendency to replace a difficult question with one which is easy to answer, the book highlights several decades of academic research to suggest that people place too much confidence in human judgement.
Here’s my first highlight:
Why is it so difficult for us to think statistically? We easily think associatively, we think metaphorically, we think causally, but statistics requires thinking about many things at once, which is something that System 1 is not designed to do. The difficulties of statistical thinking contribute to the main theme of Part 3, which describes a puzzling limitation of our mind: our excessive confidence in what we believe we know, and our apparent inability to acknowledge the full extent of our ignorance and the uncertainty of the world we live in. We are prone to overestimate how much we understand about the world and to underestimate the role of chance in events. Overconfidence is fed by the illusory certainty of hindsight.
This book changed the way I view events — I think a lot more about statistics now. The hard part about this is that it’s really unpopular because people prefer what they know and don’t want to engage their System 2 to even consider alternative viewpoints to their own. Also the backfire effect is real, so generally it’s not even worth the time trying to convince anyone to try to look at the statistics. Separately, I get self-conscious anytime I do the “well, actually” because people’s eyes generally roll over — I learned a long time ago this doesn’t make you many friends, though truth is so important. The reality is that you can’t speak truth into people’s lives if you can’t develop a relationship with them first, so you have to pick and choose your battles in your want to spread the truth.
This is where the name of the blog (Stichomythia) comes from — I’ve learned mostly when to keep thoughts to myself vs when to share/convince, but it’s hard to stop the thoughts that go back and forth in my head.
Last night felt especially random as I sat inside of this private social club next to @jasonchumusic and @chaumeleon and we were just talking about life. @chaumeleon had shared this article earlier in the week on open vs closed networks as a predictor of success and it made me reflect about my past and my path to the present, where I was sitting next to a touring rapper and a grade A balls businessman who have fast become friends and somehow I was the connector! If you had only known teenage me, you would be surprised. Maintaining open networks and going out of my comfort zone (often times unintentionally) have been major factors in my life.
You’d be surprised because in some ways I grew up the stereotypical Chinese American male — focused on academics (math was a strong subject, of course), played violin, quiet, socially awkward (but my AIM game was on point, say hello to asianexpress713!) — I’ve never been a fan of stereotypes, but I knew I played into many of them. Connecting people when younger me could barely connect myself to people? Crazy talk. That said, I love breaking stereotypes — partially because I’m a purist in some sense when it comes to facts (stereotypical engineer?), where folks are way more than stereotypes would have you believe (you don’t have all the facts). This is part of why in high school I dropped private violin lessons to go all-in on track and field (and soccer to a lesser extent). Don’t worry, I still played in orchestra, though my violin teacher told me I would regret the decision for the rest of my life (ouch) because she said that when I’m old I’d still be able to play music, but I can’t run track. To my mom, track was just exercise. To me, well, my way of breaking stereotypes was breaking 6 school records and winning the crown jewel race for a sprinter — the 100m dash at the state championship. One of my teammates overheard one of my black rivals (from O’Dea) talking to his teammate say “Victor deserves to be black” — as a nerdy Asian kid, this was the ultimate compliment. With regards to busting stereotypes and struggling to overcome the negative ones (keeping you on the sidelines), this J. Cole song comes to mind, check the lyrics:
Cause can’t nobody tell me what I ain’t gonna be no more
You thinking I’mma fall, don’t be so sure
I wish somebody made guidelines
On how to get up off the sidelines
[Verse 2:]
Up in 1st class, laugh even though it’s not funny
See a white man wonder how the fuck I got money
While he sit at coach, hate to see me walk past ‘im
Young black pants sag, headphones blastin’
Know what he askin’, “how did he manage?”
“With all the cards against him, he used them to his advantage!”
Slang we be speakin’ probably soundin’ like Spanish
Then I fuck they heads up when a n**** show manners
Funny thing is, I started listening to a lot more rap because of my friends in high school track — I gained a whole new appreciation for hip hop, wordplay and poetry in general whereas before I didn’t really get it. People in my honors classes weren’t into it at all so I was never exposed.
Track/soccer was transformative for me — I was in the same honors classes with mostly the same people from middle school until the end of high school. It could have been a closed network (as the article describes) where I was only friends with the same people all in the same context, but I was fortunate enough to be involved with folks in different contexts through sports, church and music/orchestra. Not by my own doing of course as it was unintentional, but like the article mentions, I never felt like I had a place where I belonged because I was interested in all these different groups, but never felt like I fully fit in in any of them. It was lonely and I didn’t really have close friends in high school.
People in open networks have unique challenges and opportunities. Because they’re part of multiple groups, they have unique relationships, experiences, and knowledge that other people in their groups don’t.
This is challenging in that it can lead to feeling like an outsider as a result of being misunderstood and under-appreciated because few people understand why you think the way you do. It is also challenging, because it requires assimilating different and conflicting perspectives into one worldview.
That was me in a nutshell. I had groups of friends (acquaintances?) in track, soccer, classes, orchestra, church and even within my own neighborhood. As an example in college, when it came to being an athlete/teammate, I was Christian and didn’t know how to reconcile my faith and all the partying. Being young in my faith, I didn’t know how to reconcile that with all the partying in general. I ended up being super legalistic/judgmental/unloving — which was totally the wrong way to go about it.
I’ve been blessed by connections in these various groups. It was through a friend in college track (thanks Matt!) that I was given my first taste of startup life as an intern for Justin Kan and Emmett Shear (of Justin/Twitch.tv fame) at their startup at the time, Kiko. In fact I was there before it was even named Kiko and we had a pretty funny night of us all trying to come up with company names in one of the residential college butteries (late night eateries). I was a freshman hanging out with seniors. I didn’t contribute much at all, still being socially awkward and inexperienced with programming, but it was a good learning experience.
It was through my brother’s friend I was able to intern at yet another startup, where I would meet PaperG/Thunder’s future VP Engineering (my boss at that startup). And it was through church I met one of my cofounders of PaperG/Thunder.
Networking being good seems obvious to most people, but the important part is that you network outside of your clique/comfort zone. When I accepted the Gospel of Christ towards the end of high school, it was something that the pastor had talked about at a retreat — the need to get out of your comfort zone in order to know God better. To take that leap of faith if you really want to know what it’s all about. It’s all related — if you want to be a better friend, significant other, manager, co-worker, whatever, you have to get out of your comfort zone and start hearing (being open to) new perspectives. You can only learn so much from introspection and one group of people. I live in a Silicon Valley echo chamber — and I’ve found balance through folks I’ve met in church, SF natives, homeless folks I’ve met on the street. They all help keep me grounded and give me fresh perspective with which I can cross-pollinate other groups. I’m comfortable with who I am now, even if I never feel like I fully fit in to any one group, because I’m better at reconciling the dissonance with being in groups of differing perspectives.
Creativity is just connecting things. When you ask creative people how they did something, they feel a little guilty because they didn’t really do it, they just saw something.
It seemed obvious to them after a while. That’s because they were able to connect experiences they’ve had and synthesize new things. And the reason they were able to do that was that they’ve had more experiences or they have thought more about their experiences than other people.
Unfortunately, that’s too rare a commodity. A lot of people in our industry haven’t had very diverse experiences.
So they don’t have enough dots to connect, and they end up with very linear solutions without a broad perspective on the problem. The broader one’s understanding of the human experience, the better design we will have.
That’s Steve Jobs telling you to get out of your comfort zone.
If you have trouble relating to folks outside your comfort zone, then have no fear, because I used to have tons of problems with that too. The trick is remembering that every human is unique and has their own story, their own context for why they are the way they are. Sure some stories are more interesting than others, but to find out what really makes a person tick and what drives them, that’s the buried treasure. There’s something to learn from everybody and while what you learn may not come into use immediately, you can file it away subconsciously. And this works both ways — this is why it’s also important to be your authentic self, rather than just another clone. You have a story to tell and lessons to teach whether you believe it or not. Sometimes it just takes getting out of your comfort zone to draw it out.
Every month I take a trip to Seattle to visit my company’s Bellevue office since most of the engineering and product team is there and tonight I felt particularly encouraged by the past few days in the office. I’m proud of the team we’ve built over the years and just how far Thunder has come. When I’m in town, I usually hold office hours so that any employee can stop by and ask questions 1-1. Multiple coworkers told me about how excited they are about what they’re working on and how much they enjoy working here (mostly unsolicited). One person told me that they have full faith in the executive team and that we’ve been making some great decisions this past year in terms of fostering an excellent work environment. (!!)
An email I received today from a new employee (fresh perspective is super helpful) really stuck with me:
…I must say that Thunder has continued to blow me away and vastly exceed my expectations. I am very impressed at the culture here in Bellevue. Everyone is very friendly and eager to help, but more so I’ve noticed an extremely collaborative environment…more so than I’ve ever experienced before.
There is something incredibly satisfying in knowing that others find joy in something you helped build. The more I think about it, the more thankful I am for everything I’ve learned in running this company and the amazing coworkers who make the company what it is today.
I don’t take the time to think about accomplishments very often, nor am I very good at taking praise, but it’s something I’m learning to do as I realize that it’s important to recognize others and these two things go hand in hand sometimes. It can be hard to recognize others for their accomplishments if you don’t spend any time recognizing accomplishments in general. Part of it is just the way I was raised (almost never praised for accomplishments), and another part is just usually focusing on what’s next in terms of goals and what needs to improve (very self-critical), rather than dwelling on the past or present. But everyone can change, and I plan on doing that.
I’m really proud of Thunder and just how far we’ve come. Pride comes before the fall? Hopefully not in this case, unless we’re talking about the season 😉
Someone asked a question awhile ago on a CTO mailing list I’m a part of and I wrote a longish reply — finally got around to posting it here:
a) Did you go through a similar growth path (10 to 20 to 40 people on your team) as a CTO over the last few years and would have some wise advice for me?
b) Thoughts on what the division of labor between a CTO & a VPE is?
I’m coming somewhat fresh off of this the last few years. With PaperG, we went from 5 to 25 in the first 6 years and then to 60 people in about 12 months — so very similar to your situation. We have about 35 engineers/PMs/designers now. Asking for advice earlier was something I wish I had done. It’s important to connect with other CTOs/VPEs who have been through this (part of the how I ended up on this list in the first place) — definitely tap your network for this, whether personal or via your board/advisors. One of our advisors set me up with some meetings that were incredibly helpful with other CTO/VP types.
I’ve read a lot of the VP vs CTO articles (such as the Mark Suster one linked earlier[1]), but have concluded, as with many things, it just really depends on your company’s needs. So first step is figuring out company needs out and then your own personal strengths/weaknesses. Finding someone to complement you is probably most important. For example, I wasn’t even a college grad 9 years ago, whereas our VPE already had over a decade of MSFT/startup experience. I had no experience with management and he was able to help me grow a lot in that area (fun fact: we met because I was an intern at his startup — funny how that works). On the flip side, me being young/naive and uninfluenced by any corp/company culture allowed me to think outside the box a lot more and challenge him.
I feel really fortunate to have had our VPE since around the time we hit 25. He originally started as a lead (with much more experience than anyone else) when we were about 10–15 and eventually promoted him as we grew. Couldn’t have scaled up without him. You need someone mentoring people properly — I’m a big fan of weekly 1–1s, but you can only have so many. So you need to start raising leaders and you don’t have to time to do that on top of everything else.
Just as there’s often a focus on scaling infrastructure/technology, you have to develop scalable processes for the team, especially if you know you’re growing a lot in the near future. One thing (of many!) we encountered as we grew was engineers starting to wonder how could they progress in their career. What does a promotion look like? Are there promotions? Is management the only way up? Only you know what sort of culture your company has and what would work best with it. With our VPE handling the day to day management of engineers, it allowed me to research and think about these sorts of problems and in the end I decided a ladder system with internal/external titles (different but equal titles/levels for ICs) would be the best fit. Levels so that people could see their progress more often internally, and title changes at certain levels so that they could have something external to be proud of and share with others. Some will argue that I was doing the job of the VPE in thinking about this, but when it comes to a startup/small company — what do titles really mean? There are certain problems you’ll encounter, and certain people will be more fit to solve them — it’s my job as CTO to delegate within the engineering org since I have the most complete picture of the company as a whole. Really important to tackle these things now, because you won’t see the fruit of your efforts for awhile (our eng culture has transformed in a really good way since we spent more time on the processes, but took awhile to see it — you need to set it before you do your hiring so that new people can help usher in the new age)
Again, this is just how it happens to work out within my company. While people on this list can give you their advice/opinions, it’s up to you to synthesize and figure out your own solution for your unique position.
That said, with regards to what Scott said about not hiring a VPE quite yet, I’d have to agree for the most part, at least in the way he seems to have defined what a VPE does. A VPE at a smaller startup is really just a lead. When you double in size, they become a lead of leads, perhaps. Our company is now at a point where I feel like the VPE role is necessary (or at least, something beyond just a lead — you can call it a director or senior lead or whatever you want). I met with Airbnb’s VPE (thanks @mikecurtis!) and he told me that when he came in, he helped established a lot of processes — everything from establishing a career ladder, more focus in their language/tool choices, to recruiting process that helped them go from 30 to 80 engineers in 6 months (!). This is what Airbnb needed at the time.
Last comment for now is that keep in mind that if you hire a VPE now, it’s harder to hire someone above that — there aren’t too many more titles above it. So if this person isn’t VPE material, either you’ll hire someone into an SVP position (doesn’t seem as common in eng orgs), or you demote this person, or you replace them altogether. In this way, titles matter in the long run.
Hopefully some of that was helpful — there’s definitely more I could talk about if you’re interested.
Not to be confused with Dijkstra’s paper[1], this is more about an attribute many great programmers embody—humility (Dijkstra’s paper has a great quote[2] relevant to this post). This term is often misunderstood, but let us define it here as “thinking of yourself less often (and subsequently, think of others more)”, as opposed to “thinking less of yourself.” This has a number of implications:
When you write code, you’re thinking of others and how this will impact them. You end up with more obvious, more easily reviewed/maintained code. Potential impact on other systems is addressed, rather than ignored or left for someone else to find.
In arguments, people can take a step back and listen. With mutual respect, it becomes easier to discuss and tempers don’t flare up. Approaching a conversation with the possibility of a flaw in your idea totally changes how you talk about it and your willingness to listen to criticism. There is a fine line between confidence and arrogance.
No problem is just XXX team’s job. Are the test tools not working? It’s not just the test team’s job — it affects all of us, try to pitch in (without hindering others with too many questions or poor suggestions of course) instead of just waiting around, especially if it blocks you.
Blaming others or constantly complaining won’t get you anywhere — help figure out a way forward, or provide feedback. Big pet peeve of mine is people who just sit around and complain — inaction contributes to the problem.
Humility is not nearly as loud as arrogance, so we will rarely see examples of people being “humble” within the community. We experience humility without realizing it, so perhaps the best way to recognize and encourage it is to publicly praise those who get stuff done without all the drama.
[1] http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD340.html
[2] “The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.” (found in [1])
Deploying a Clojure app using AWS Elastic Beanstalk (EB) is relatively simple — I ran into a few issues that I want to document in case anyone else runs into the same issues. For those unfamiliar, EB is Amazon’s Platform as a Service offering, with a super straightforward CLI (though they do offer a GUI as well). I used lein-elastic-beanstalk as my plugin of choice, which uses the Java AWS SDK to interface with EB. It’s a fork of lein-beanstalk (both of which haven’t been updated in awhile, but lein-elastic-beanstalk is a little more updated). It’ll package your project into a WAR file, send it to EB/AWS and then be served via Tomcat.
I wish I could say I was able to automate the whole thing from start to finish, but I’d have to dig into lein-beanstalk in order to fix one of the issues I was running into. Notes:
Make sure you specify the stack you need, in my case: 64bit Amazon Linux running Tomcat 8. Otherwise lein-elastic-beanstalk’s default is 32bit Amazon Linux running Tomcat 7, which isn’t the version I needed — I ran into an error message similar to this: org/eclipse/jetty/server/handler/AbstractHandler : Unsupported major.minor version 51.0.
I wanted to use a t2.nano instance, but this requires VPC. In theory, this is all you need in project.clj (once you’ve set up VPC):
But I ran into this: com.amazonaws.AmazonServiceException: Configuration validation exception: Invalid option value: 't2.nano' (Namespace: 'aws:autoscaling:launchconfiguration', OptionName: 'InstanceType'): Value is not one of the allowed values: [t1.micro, m1.small, m1.medium, m1.large, m1.xlarge, c1.medium, c1.xlarge, m2.xlarge, m2.2xlarge, m2.4xlarge, m3.xlarge, m3.2xlarge, cc2.8xlarge]So somewhere along the way, t2.nano is not accepted, probably because t2 didn’t exist until relatively recently (and t2.nano wasn’t enabled on EB until January 2016). Based on the error message, lein-elastic-beanstalk probably needs an updated version of the AWS SDK. Will probably have to submit a pull request if it seems like the owner is still looking at the repo, otherwise I manually went in, copied the environment but made sure it deployed instances within VPC so that I could change the instance type to t2.nano via the GUI.
Be careful about deleting any security groups, or copying environments. Sometimes this will prevent you from terminating old environments or deleting applications. If you do get in the situation, seems like the best thing you can do is deploy the latest version you want into a new environment, and everything it needs will get constructed, allowing you to finish terminating other instances.
Once I did the slight manual fix to enable t2.nano, running lein beanstalk deploy dev started to work without any issues (to be fair, it worked fine with the old t1.micro outside of VPC).
Overall, I wish there was a way to deploy faster, but it’s not a big deal in this case since I just wanted to put up a super basic site: http://victorjcheng.com. I know it was overkill to use Clojure for what is essentially basic HTML, but I’m a big fan of the language[1] and wanted to deploy something via EB.
[1] You should check out one of my favorite books on Clojure: The Joy of Clojure
Avoid gossip at all costs and resolve issues directly.
Conflict comes up all the time — rather than avoid it, it’s important to develop a framework for resolving it. You can get pretty far avoiding it altogether, but if you do that, you’re really just setting up ticking time bombs. It’s better to address it as soon as possible (timing is also important, though — make sure you’re in a coherent state yourself).
At the root of conflict lies a rift within a relationship. Either there is a disagreement or misunderstanding and one or both sides feel wronged. Or perhaps you feel like someone else is doing the wrong thing and you want to point this out. Here’s a framework[1] for conflict resolution after seeing plenty of conflict in relationships/friendships and while running a 60-person startup:
Resolve conflict 1–1, don’t involve others. No gossiping/tattling! Most of the time, conflict is resolved in this step, but few are good about taking this first step.
Not getting anywhere after multiple attempts? Involve someone else. This might mean including a mutual friend or two. In the workplace this might mean another peer or manager. Ideally it’s someone you both respect.
You may be tempted to talk to everyone else and complain about these issues, but you’re doing more harm than good by “getting it off your chest” — there are rare exceptions to this, but it’s generally a good idea to be direct (as opposed to passive!). How many times have you run into a situation where you hear someone complain about you behind your back and you think, “why didn’t they just talk to me directly rather than telling everyone else”? That’s what we’re trying to avoid here.
If you don’t spend enough time on the first step (resolve 1–1), you run the risk of having them feel like you’re betraying their trust or gossiping — it only serves to damage the relationship further.
Perhaps there should be a third step for: What if you really just can’t see eye to eye? Generally you can resolve most conflicts within the first step, and the exceptions within the second step — though this does assume both sides are somewhat reasonable. When dealing with unreasonable people…well that’s a discussion for another time (would love to talk over any particular situations people might have in mind).
I might write another post about the first step because even if you finally get some direct conversation going, there are good and bad ways to conduct yourself within that context.
