See this post from Casey Newton’s Platformer newsletter about Twitch engineers leaking the entire source code.

I wonder if there any effective way to prevent this from happening?

We don’t even know this problem exist. How do we know it is even needed? How do we get to a better state with these unknown unknown problems?

My co-worker Michael L. wrote an internal page about how he thrives on these type of Unknown Unknowns problems.

I’m reminded recently that I get a lot of my energy and fear from unknown unknowns, because they are the most interesting ones, but also very likely to fail.

This is quoted from his internal page

1. Known Known — I know exactly how to do it.
2. Known Unknown — I don’t know how to do it but I am sure it can be done in some way.
3. Unknown Unknown — I don’t know how to do it and I have no idea if it can be done.

If you want to be an effective engineer in our industry, get ready be good at the following

Basics 0 – This is the basic toolbox as an engineer

• Be proficient in your favorite IDE (Visual Studio Code seems to be the most popular right now) – my personal favorite is still VIM.
• git – be comfortable with simple git workflow, and also how to fix merge conflicts, branching, squashing and stashing
• docker – For the modern development company and also for you to be able to collaborate with your co-workers in CI and for you to share your work, you need a way for others to repeat the work you’ve done.

Level up 1

• Python – Being able to quickly script together a solution is a must to be a productivity engineer, even if it’s just to help yourself automating your work.
• Javascript – If you only had to learn one language, learnin JS. Which people are able to build backend and frontend applications.
• Golang – Golang is used to build backend API’s and systems that need more distributed work
• C++, Java, Rust, Ruby – These are nice to have and it’s company specific. So you might need one of these dependent on the company you join.

Level up 2

• React – This will allow you to build UI apps
• HTML/CSS – Only Frontend engineers need to work at this level
• Continuous integration – While this is not cool and sexy technology, not being well versed in Gitlab CI, Github actions or Jenkins will limit your growth in daily troubleshooting and your ability to help your team.
• Automated testing – Unit, service, cypress.io UI testing
• Kubernetes – This is defacto standard in running the services you’ve build. Not knowing this will drag you down as you build more services
• Package managers – If you use Javascript, get good a NPM. Java -> Maven. etc

Level up 3

• AWS – most companies will abstract you away from AWS, unless you work in the infrastructure teams
• GCP, Azure – After learning AWS, then you can invest in learning one of these cloud providers
• Security – Having deep knowledge in security will give you a leg up, but it’s a specialized skill

Specialize positions

• If you work on native mobile apps – Swift, Java or Kotlin is neccessary.

I’m sure I’m missing a ton of needed skills, ping me on http://linked.com/in/tonytamsf

I’ve had 39 submissions to my favorite Podcast App – AntennaPod in 2020. Which makes me #7 on the contributor list. That was a good learning journey for me. For the next leveling up to be #6, 140 of my submissions would have to be accepted. That would take 2.5 years given my current rate of submission. If I wanted to get there in 2021, that would mean 1.9 submissions per week.

20 years ago, while I was the lead engineer for Yahoo News, I was asked to build a very basic feature to allow users to send news articles via a simple email link. That feature was simple: let users click on a link to send the news article with the URL, title and a brief summary and email it to one or more people.

With this simple request, I built a generic ‘Mail To Friend’ feature that any web site at Yahoo could use with a simple set of parameters URL, property, country and everything else (spam control, sending the email, tracking what was sent).

After launching the simple feature, I was doing some validation of the system, looking at the data around what was sent. I looked at how many articles were sent, aggregated it by the top articles sent and I noticed that the top 20 articles were ‘interesting’ news stories that I normally won’t see on Yahoo News as a daily reader myself. Then I noticed the photos that people emailed, where the cute, or outrageous.

I built a script where I looked at moving window of the top 20 news stories and 20 news photos in the last 36 hours to keep the content fresh and showed it to my news producer (product manager) and that is how the most-emailed feature was borned. (NYTimes) https://www.nytimes.com/2001/01/29/business/new-economy-yahoo-charts-spread-e-mail-what-it-finds-itself-becoming.html

At work, someone wanted to talk with me about answering the question of “Do people at work feel zoom fatigue?” What would be a good way to look at this question from a data perspective?

I proposed the following question, now that we don’t have to commute, shouldn’t we

• have more time in the morning to exercise because our morning commutes are anywhere between 30 to 90 minutes in the bay area?
• Have lunch with our family and household because we are all home between 12 and 1pm?
• Take care of ourselves after work because we are saving time from the evening commute?

I am exercising a lot more because of 90 minutes of tennis in the morning, but I’m not having lunch with family because we are on zoom during lunchtime. After work, I’m still working because I don’t have a clear boundary of when to stop working.

To bring life at work to a new normal:

First of all, my own team and myself, I think we are zoomed out, and we should not work as if we were face to face, but replace the same way of working as if we were in the office. Even without evidence, we have implemented the following changes to our team of 14 people.

For 1:1’s. – For our team’s weekly 30 minutes 1:1’s, we are doing phone audio only on traditional phone calls, and I will offer a chance to do walking outside meetings. We can take interesting pictures along our walk and share them back with the team Slack channels. Here are some of my photos along the walk with my direct reports.

Standups: First, we are no longer doing scrum standups via Zoom. We will send via Slack our statuses, and people who have an interest in the status will reply in a thread to ask questions or offer help. We will use Zoom only for those people who need to get unblocked or do troubleshooting with the team or me.

On Mondays, we will just do demos and code walkthroughs and use that as a learning experience.

On Tues – Wed – Slack updates and Zoom unblocking (optional)

On Fridays – no face to face meetings on Zoom

My superpower in life and at work is “troubleshooting.” I’m an engineer who helps other engineers when they are stuck.

This could mean very detailed technical issues that engineers run into that takes them hours to solve. They will bring that problem to me, and usually, through some questions and answers with me, we can narrow down the problem and figure out the root cause.

For example, this week 3 separate engineers reached out about

1. He used to be able to ‘git clone’ via ssh, but now he cannot. We went through checking his ssh public keys, used ‘ssh -v git@host,’ double-check his permissions, and finally arrived at that he ‘mv ~/.ssh/id_rsa.’
2. 2nd engineer had weird ‘ssh disconnection’ errors to only a set of machines, but it was fine for others. We went through a zoom session where we tried to look for ssh configurations, create an ubuntu docker image, and ssh from there, and finally arrived at his VPN connection configuration. This is super odd since a docker container was able to ssh while the host machine could not.
3. A developer could not build source code from a particular branch, and I tracked it down to a specific change in the build script that was not honoring the Mac 10.x build toolchain.