Forem: Shai Mendel

The Last (Engineering) Dance

Shai Mendel — Sun, 26 Jul 2020 13:27:00 +0000

Watching The Last Dance was an incredible experience, much more than watching Michael Jordan or specifically to sports - I treated this series as a team building tutorial.

So many team building and personal growth topics were raised there, I just found myself sitting after every episode and thinking on the episode's relevancy to my work as team lead and what I can learn from it.

tl;dr

This blog post is about taking lessons from The Last Dance and applying them to the engineering world.

I'll focus on the processes that took place in the Chicago Bulls that converted them from a great team to the best group of their time. A lot can be learned from the different approaches that the coaches took and the different behaviors of Michael Jordan that led to this improvement in the team's performance.

Comparing a basketball team with an engineering team

I’ll begin with doing a basic mapping (as I see it) between the series characters to an engineering org:

The coach (Phil Jackson and Doug Collins before him) — the team lead
Michael Jordan — a senior engineer
The rest of the Chicago Bulls team — non-senior engineers in the team
Jerry Reinsdorf and the rest of the Chicago Bulls mgmt — different stakeholders, “upper management”
The fans and the crowd — customers

Now that we have this comparison in mind we can begin with the real fun :)

The team lead’s approach to winning

The coach/team lead have a lot on their minds:

Satisfying all stakeholders inside the organization — bringing money in by winning/selling
Satisfying the fans/customers in the long term
Satisfying the team itself — personal growth, ego, salaries
Satisfying themselves — let’s not forget that the coach/team lead wants to develop and enjoy as well

Let’s compare the two approaches of the two coaches in the series:

Doug Collins — win by maximizing reliance on Michael Jordan

Doug Collins was a coach that brought great results to the team by putting all the focus on Michael Jordan, all the game moves and tactics were built on Michael Jordan’s abilities. This is an example to a team lead that puts the weight of the team’s ability to deliver only on the senior engineers in the team:

Difficult and complicated tasks are assigned to the senior engineers
The non-senior engineers’ purpose is to let the senior engineers run fast and deliver

This made the Chicago Bulls a great team because they had one hell of a senior engineer :) but they could not win the championship. There are a lot of disadvantages to this approach:

The team’s ability to deliver is equal to the senior engineers’ ability to deliver
The ability to improve is equal to the ability of specific senior engineers to improve
This is not scalable and relies too much on too few people in the team
The non-senior team members do not improve, this approach perpetuates the current “snapshot” of the team — the seniors will stay seniors, the non-seniors will not be promoted.

So even though the results were good, they were not great. Remember all the concerns team leads have on their minds? this approach led to unsatisfied internal stakeholders (not winning the championship), unsatisfied fans/customers (not winning the championship => the product quality was limited and did not improve), unsatisfied team (they were all a shadow of the senior engineer with no future to be seniors themselves), which makes the team lead itself unsatisfied — and who can blame them, how can you be satisfied when everyone around you is not?

Phil Jackson — win by maximizing the team performance

Phil was hard to process for the team, he arrived with a completely different approach which turned upside down the way the team behaved so far.

The discussions and plans moved from “what can we do to make Michael Jordan score?” to “what can we do to win in the long term?”. This is a huge difference that made the real change in the group.

Phil put emphasis on team building, made everyone focused on the target of winning and to rely on each other. “There is no I in team”.

Phil was a true inclusive leader, fostering collaboration (reducing the bus factor) and not necessarily hiring new team members for their resume but their ability to complement the team.

After some adaption time there was a huge difference in the team performance that led to winning the championship. All the disadvantages from before disappeared:

The team’s ability to deliver is equal to the entire team’s ability to deliver
The ability to improve is equal to the entire team’s ability to improve
This is as scalable as it can get — it relies on everyone in the team
The non-senior team members improve because the senior team members push them to excellence

This approach makes the stakeholders, fans/customers and the team satisfied.

When you put weight on the long term goal and make sure everyone on the team improves you get the best outcomes. Focusing on one person or on short term goals (winning only the next game and not the next seasons) doesn’t get you to your maximum. No shortcuts here.

The role of the senior team member

Doug Collins believed that the senior engineer’s responsibility is to bring success by leading the team and carry it forward.

Phil Jackson believed that the senior engineer’s responsibility is to bring success by pushing the team to excellence “from behind”, being a servant leader that defines success by the team’s success and not by personal success.

Phil: There is no I in team

Michael: But there is an I in win

This is a conversation that blew my mind, it shows so clearly the difference between the two approaches. The problem is they are both right :) It took time for Michael Jordan to understand that there is indeed an I in win, but it had a different meaning than what he used to think.

Michael Jordan was a critical senior engineer in the team’s success:

He pushed the other team members to excellence during practices. He expected them more, pushed them to be better. He had high expectations of them
He pushed the other team members to excellence during games
He helped the team to stay focused when their spirit took a hit. Michael could stay focused and perform even when they were losing, and this approach led others to play accordingly

During their time under Phil’s leadership, the best time this group has ever had, Michael wasn’t the only scorer, the game tactics did not focus on Michael, and it took him time to process it. There is really no I in team.

When Michael saw the results of this new approach he was convinced that there is definitely an I in win, but only as part of a team.

The series demonstrated so well the most effective way we can define the senior engineer role:

The senior engineer’s success criteria is the team’s performance and not just their personal performance
Improve yourself by making others better — don’t be frustrated if the there is a gap of knowledge between yourself and the team, see it as an opportunity of personal growth and have high expectations from your team mates

Living in a roller coaster

Basketball/engineering team’s life is like a roller coaster, you sometimes get super high after a win and sometimes get depressed by a devastating loss. It is hard to create a strong team spirit like that, and I found the way the Chicago Bulls coped with it very interesting and we should all apply it to our engineering teams:

Celebrate successes
Learn from mistakes
Anyway, either after a win or a loss — stay focused

Every topic here should not be underestimated, it is a crucial part of forming a healthy team culture and identity while keep focusing on the right direction.

Summary

In case you did not watch The Last Dance from an engineering standpoint — I encourage to do it :)

Hoped you enjoyed my take on the series!

Originally published at https://shaimendel.dev.

Creating my open source dev blog

Shai Mendel — Tue, 19 May 2020 08:43:01 +0000

Why I chose to create my dev blog in a fully open source manner and all the advantages with this approach

tl;dr

In this blog post, I explain why I chose to create my dev blog in a fully open source manner and all the advantages with this approach. I planned creating my own developer blog for a while but wasn’t satisfied with the common setups normally chosen. As an engineer, I preferred to treat my blog as yet another software project and therefore had the following requirements:

manage everything (really, everything) in a single place — GitHub
the blog management interface should be done solely using git:
- git pull = get the latest version of the blog
- merge to master = publish a new version of the website
be able to run the blog locally and see how it looks before publishing
maximum Markdown as possible, ideally no CSS and html work. I admit, I’m not a CSS fan :)
the entire stack should be open source
both the website’s UI and the tech setup should be as simple as possible

The Setup

Source Code Management

Per the requirements I set, GitHub was a clear choice as my source code management. You can see the blog’s repo here.

Nothing special to add here :)

Static Pages Framework

There are lots of open source site generators, Gatsby and Hexo to name a few.

I eventually chose CodeDoc as the site generator for a few reasons:

I saw it in a Reddit and thought it would be nice to give a new framework a shot :)
it is really simple to use
the look and feel is very unique and simple, I looked for the simplest design as possible
it comes with some useful builtin features out of the box:
Markdown-based menu (table of contents) on the left
a small page-map on the bottom-right

Local Debugging

CodeDoc’s CLI has a codedoc serve command that automatically monitors all the local files, converts the relevant Markdown files to html and updates the local server, so http://localhost:3000 always has the updated version.

This allows me to see how the final website looks like during "development" (adding more content).

Publishing Website On Merge

This is exactly the purpose of GitHub Pages! I just configured my repository to publish my master branch as GitHub Pages and that was basically it. so simple and efficient!

Versioning

I used GitHub Actions to call Semantic Release upon merge to master. If you are interested — here is the action configuration.

This automatically creates a GitHub release and a nice and clear release notes, according to my commit messages. Feel free to see all of the blog’s releases.

Open Source Approach Advantages

This open source approach supplies some decent advantages, here are a few:

Ease Of Management

This approach makes the website development cycle a regular software development cycle, making it super easy to maintain:

local development in a code editor (for writing Markdown files and edit package.json mostly)
local debugging using codedoc serve -> I put it as my npm start command
build the website using codedoc build -> I put it as my npm run build command
merge code to master in order to deploy
The Semantic Release versioning gives the owner (and everyone who look at the repository :)) a clear view of what each website version contained
if bad things happen and the website doesn’t look as expected — reverting a commit will do the job
opening a PR is equivalent to adding new blog content — even this blog post was merged in a PR!

Security

I added Snyk’s vulnerability test badge at the page header, so every viewer can see the security status of the blog:

Summary

I hope I made it clear why I chose to build my blog the way I did, feel free to reach out for any questions!

Originally published at https://shaimendel.dev.

VS Code extension: building auto CI/CD with GitHub Actions

Shai Mendel — Mon, 06 Apr 2020 18:49:57 +0000

tl;dr

This article is about building a full CI/CD pipeline for Visual Studio Code extensions using only GitHub Actions.

My basic requirement was to build an automatic CI/CD that will allow me to do the following upon pushing a new commit to master branch:

Test: run the tests on Mac, Windows and Linux
Release: create a new GitHub release with automatic release notes based on Angular Commit Message Conventions
Publish: publish the new version to Visual Studio’s Marketplace

One last thing: I wanted to do all of that based solely on GitHub Actions :) So I need nothing but the GitHub repository to configure and run everything.

Motivation

It all began when I wanted to write a small VS Code extension that will allow me to right-click on a Yaml file and apply/delete it from my local Kubernetes cluster.
Very soon I realized that VS Code’s documentation to how to write an extension is really good — I found myself writing and locally-debugging my new Typescript extension in no time, but then it occurred to me that the full CI/CD for it that Microsoft suggests in their docs is a bit lacking:

Tests

This part is actually relatively good in the formal docs, they specifically mention a GitHub Action that runs the tests on Mac, Windows and Linux, and I definitely used it.

Release & Publish

The entire release and publish process is built on the vsce tool.
The first things you need to do to set the ground is to follow the publishing docs and especially do the following:

get a personal access token from Azure DevOps
create a publisher (the publisher name has to match the publisher section in package.json)

Once you have all that you can package, publish and unpublish your extension using vsce.
Those are manual steps needed to be taken, less than ideal!

In addition there is also a gap in how the extension version is set during publishing. there are a few ways to set that:

change the version field in package.json and call vsce publish
use vsce publish minor for example (or major/patch accordingly) to automatically increment the version
use vsce publish 2.0.1 to mention a specific version

This is really not handy, I want the version to be set according to my commit conventions automatically, with automatic release notes generation. Spoiler: I will use semantic-release for that :)

Let’s start!

I’ll follow the steps I went through and we’ll build our CI/CD pipeline step by step.

Create an extension

I followed the formal docs and relatively easily created a new repository with my fresh templated Typescript extension.
I then modified the functionality so right clicking a YAML file allows you to apply or delete it from my local Kubernetes cluster. super cool and useful to me!

Create an empty GitHub Actions workflow

Create an empty yaml file at .github/workflows/<workflow name>.yaml. I called it ci.yaml

Mention that the workflow should happen on push to master

Change you yaml workflow to be:

The upper paragraph tells GitHub to run that action when a push to master happens.
The lower part is the jobs that should be run, we will fill them soon.

Auto tests

As mentioned above I would like the tests to run on Mac, Windows and Linux. and the docs actually mention a specific action I will use now by adding a dedicated job:

As can be seen this adds a job called Test, that will run on Mac, Windows and Ubuntu.
this job contains 4 steps:

Checkout: use the builtin action to checkout the repo
Setup Node.js: use the builtin action to set Node 12
Install dependencies: run npm install
Run headless test: runs the tests using the GabrielBB/xvfb-action@v1.0 action, as recommended by the formal docs (plus some improvements)

After this step I saw that on the Actions tab:

where each test had the following steps:

Publish and release

Let’s add a new step, which looks like the following:

We’ll go slowly through this, don’t worry!
So we begin with the previous steps of checking out the code, setting up Node 12 and running npm install. The next two steps are the most important ones, and deserve sections of their own.

Release

The purpose here is to create and publish a new GitHub release with proper release notes.
In order to do so I basically just call semantic-release :) This action runs through the commit messages, builds release notes and creates a new GitHub release with a semver version corresponding to the commits I added.
It also sets that release version in the package.json, a useful fact for next phase.

In order to properly configure semantic-release you need to:

pass theGITHUB_TOKEN env var (as GitHub secret): your personal GitHub token, with minimal repo permissions

pass theNPM_TOKENenv var (as GitHub secret): your npm token to release your npm package. In my case I didn’t want to release an npm package. In order to do so you need to configure "private": true in your package.json. after you do so you don’t have to pass this env var (found this fact here).
install @semantic-release/github as a dev dependency
configure the following in your package.json:

Once this step was done I could start seeing proper GitHub releases

Publish

The purpose here is to upload a new version of the extension to the VS Code marketplace with the correct version.
One of the benefits of the previous Release section is that the package.json now contains the right package version. all needed to do no is to call vsce publish -p <my token>.
I found an existing GitHub action to release a plugin, JCofman/vscodeaction. all you need to do is to pass it your PUBLISHER_TOKEN as an env var (again, using GitHub secrets).

After this step you’ll see a new Release and publish job in the Actions tab that contains

Result

You can now find my new extension in the marketplace and in VS Code extensions search!

You can find my repository at https://github.com/shaimendel/vscode-plugin-cicd-github-actions, with the workflow configured at ci.yaml.

Summary

We just build a fully automatic CI/CD for a new VS Code extension.
every time a new PR is merged to master we:

test the code in multiple operating systems
release a new GitHub release with super nice release notes
publish a new extension to the marketplace

and we did all of it purely using GitHub Actions!

Great success :)

Shai Mendel, Engineering team lead at Snyk

Modern cyber security tooling should empower developers

Shai Mendel — Thu, 10 Oct 2019 19:46:27 +0000

tl;dr

I truly believe in the necessity of Cyber products, but modern companies will truly improve their security if and only if their developers are engaged to the effort.
This article is about talking and surfacing the gap of the traditional Cyber world, which is stuck all the way to the right, waiting for dev-first companies to shift it left.

A bit about myself

In the last year I have been working as an engineering team lead in Snyk, a dev-first open source security company aiming to help developers use open source in an easy and secure manner. In the years before I was deep in the Cyber world, which is classically divided into major categories like endpoint protection, VA/VM, BAS (breach and attack simulation) and more. I have met closely some of the categories above during the years.
I have always worked as a developer/engineering team lead and wanted to share my perspective on why it is crucial to the Cyber world to shift left and give much more attention to developers.

The traditional cyber world

Let’s talk a bit about the traditional Cyber world! Traditional Cyber relies on the technologies that ruled the world and on functions that managed security in the past. Therefore most of the traditional Cyber products target the CISO/CIO/ops/security functions in companies, and in order to do so those products normally feature beautiful dashboards that can be showed in big SOC/NOC screens, extensive reporting options, SIEM integrations etc.

Additionally the traditional Cyber products are many times on-prem only, focusing on non-modern methodologies like using virtual machines in your production environments, relatively long deployment cycles and more. Thus the security/ops departments are the ones responsible to patch those virtual machines, setting the network configurations, the security configuration and more.

This gets a little twist if we look at a bit more modern Cyber companies, where the exact same concepts are applied to the cloud environments, targeting Kubernetes clusters or other cloud environments as the production environments.

Traditional Cyber divides the world into the good vs the bad, which are called by different names in different contexts: attackers vs defenders, red team vs blue team and more.

Enter modern Cyber world

The ops world is changing quickly, it moved from deploying on dedicated virtual machines in VPS hosting providers to virtual machines in cloud providers to container-based environments in the cloud.
As a result the operations ownership which was previously owned solely by the ops team gradually moves towards the ones who build the software and the containers wrapping them - the developers!
The security ownership also gradually moves left towards developers due to the exact same reasons.

So as I said, the traditional Cyber world is divided to attackers vs defenders, which leads to products that target the ops/security departments. This approach is missing the most important ingredient to actually improve your company’s security - the ones who are responsible to fix those issues, the developers.

Dev-first Cyber products

This gap of not targeting developers as consumers lead sometimes to some resentness from the developers towards the ones who order them to fix security issues in a non-actionable manner.
We, the developers, are a very different kind of people :) we don’t care so much about beautiful dashboards; we prefer a clear, simple and actionable tools. We want maximum value with minimum effort, and if some effort is needed it is better to be dev-friendly.

I truly believe in the necessity of Cyber products, but modern companies can truly improve their security if and only if their developers are engaged to the effort.

If talking in shift-left terms: from my experience I believe that the future Cyber world will be dominated by dev-first companies coming to the right rather than traditional Cyber companies moving to the left.
Therefore in order to keep the pace I think Cyber companies will have to adapt their products to the developer audience, which means to suggest remediation in a dev-friendly way, for example:

Convert traditional patch management systems to features that help developers reduce vulnerabilities in their container images
Opening pull requests to fix found vulnerabilities
Opening pull request to change network configuration in Kubernetes yaml files/helm charts to reduce security risk

The security world, with the Cyber security world as a subset, is owned by developers. so why not targeting it as consumers?
I hope this article will raise awareness to this gap, help developers realize it is our interest to own our own security, and for non-developers help us be part of it.