1. “I got it all figured out. What’s next?”
   Never stop learning. When you think you have got it all covered and there are no more challenges for you, think again.
2. “This is not what I have expected. What’s next?”
   Don’t try only to make the workplace change for you. Adapt to be the best solution to what the workspace needs from you.
3. “Hiding your needs from your team lead.”
   Just read what Iris Shoor wrote here https://irisshoor.com/blog/how-to-impact-your-manager/
4. “I don’t plan, I do”
   Write design documents. Communicate in writing your plans to align expectations.
5. “Using the wrong people for guidance”
   Search for 3–4 mentors. Always use your judgement when taking advices.
6. “Linkedin and GitHub are for seniors”
   No they are not only for seniors, but for juniors as well. Invest in your personal brand and utilize popular professional social networks.
7. “Focus on the code, not on the system design”
   Understand the context. See the bigger picture, not only on the task at hand.
8. “Stackoverflow is better than the docs”
   Don’t be lazy. Understand the core, the “why”, the DNA of the tools you use. “Reading the docs” can be the perfect simple source of knowledge you need.
9. “I am a tech professional first, and a team member last”
   Be your team lead’s right hand. Teach. Listen. Document. Show respect. Be open minded. Foster good relationships. Care about being a good team member. Work with people, not only with the code.

People

Friendly

I have never had such a positive and friendly interviewing process as I had in Check Point. My jaw just dropped when I left the campus on the technical test day. Everyone who I met was so nice, professional and pleasant. I’ve heard so many great things about the people I will be working with. It was all so quick and professional. Check Point takes recruiting very seriously. The facilities in the TLV office are very impressive as well. Candidate experience makes the difference.

Diversity

Check Point strives every day to increase female representation and continues to promote campaigns and partnerships with relevant organizations to increase the number of women in technology-related positions and train them to increase their skills in cybersecurity. More than half of Check Point’s top executive management today are held by women, such as the Chief Product Officer (CPO), Chief Financial Officer (CFO), Chief Operating Officer (COO) and Chief Commercial Officer (CCO)

Winning

I love to win. To take part in a winning team. Something big is happening in Check Point and I expect big wins soon for this company for the following reasons.

“You Deserve The Best Security”

This^ is the new mantra leading Check Point, published earlier this year (Jan 2022). So many people, companies and institutions are suffering from cyber attacks. For example: It’s expected that ransomware costs to reach $265 Billion by 2031. Check Point is focused on that domain for more than the past 25 years. A giant that can lead the world. We deserve being protected. That’s a meaningful purpose to get up in the morning for.

“Second Best Will Get You Breached”

With the financial reports of 2021 published, Check Point shows to the world who is really the boss when it comes to the Israeli cyber industry, getting back to leading the board with the highest worth among all Israeli companies, $17B. It’s also not afraid to compare its offering to the competitors and shows how it has the widest and best products so any usage of others is a meaningful risk to get breached.

“Best Security All The Way To The Space”

Check Point hosted the control and communication of the first-ever commercial astronauts mission to space, and the biggest scientific expedition ever conducted in the international space station right from the Tel Aviv Headquarters. It has ended successfully utilizing the company’s products to protect this important mission. See the following video:

Size

Check Point provides the most comprehensive and cutting edge cyber security technology to more than 100,000 organizations of all sizes and millions of users around the globe (including most of Fortune 500 companies)

Join that to the impressive but clear “Infinity Vision” unified solution:

As a Cloud Advocate I get especially excited from their cloud offering:

Process efficiencies and increased network agility are driving SaaS, PaaS and IaaS technology adoption at a rapid pace. This new infrastructure is also presenting businesses with a unique set of security challenges. Check Point CloudGuard provides unified cloud native security for all your assets and workloads, giving you the confidence to automate security, prevent threats, and manage posture — everywhere — across your multi-cloud

Winners Everywhere

Check Point has bought a couple of successful cyber security startups (few examples: Avanan, Protego, Dome9) and especially Spectral just recently (Spectral’s security tools support a wide range of automated code security use cases). Working in the same team with successful, capable and ambitious groups is an amazing experience. I was impressed they live to the standard of allowing many agile organizations within the backing of the corporate resources.

My Role

As mentioned, Check Point has a large offering in the Cloud Security domain. It has hundreds of developers pushing through products on that domain. All those products are using a unified infrastructure of authentication and “application marketplace”. I’m going to lead not only a group of highly skilled engineers that develop excellent products, but also connect with hundreds of engineers to let them plug into the infrastructure to be served to Check Point’s clients. We’re a versatile group of engineers using the state-of-the-art engineering tools- NodeJS, ReactJS, Kubernetes, AWS, Prometheus, Grafana and many others.

Focal Point

Developer relations, application workflows and reliable infrastructure are going to be meaningful pillars of my work. The best ingredients I enjoy working with. Being in the center between dozens of dev teams and the infrastructure connecting workflows and technology while we scale our offering is going to be an incredible challenge.

Production All The Way

Full stack development on SaaS products is not only writing code locally. Our engineers in the Cloud Infra group must get comfortable in production. Aside from making clean code one must also think on monitoring, metrics, alerts and cloud architecture.

Join Me

You felt this part is coming right? :) Here you go:

The World's Leading Provider of Gen V Cyber Security Solutions

Shali Mor, thank you for accepting me to join the ride and your assistance with making this article 💪

Yours,

Regev Golan

Let’s start

You have a working, in use with data, standalone mongodb server. Take an image from it and create another server from that image. It’s very useful to do so also to have a backup of course before you start messing with it. Now you have 2 identical standalone mongodb instances.

Now this is the most important point to follow that is not mentioned in the mongodb docs: They assume your new mongo instance is a clean one. A mongodb that was just installed without any auth, users or data. This is not true if you have created the new server from an image of course. So go ahead to that new server and stop the mongod, remove all of its data folder’s files and start mongod back again. Now it is running a clean mongo that is ready to become a secondary.

On both servers edit the mongo config to have a replSetName:

replication:
  replSetName: myReplica

On the designated primary (not the one from previous step of course), run:

rs.initiate(
   {
      _id: "myReplica",
      version: 1,
      members: [
         { _id: 0, host : "mongo1.mydomain:27017" },
         { _id: 1, host : "mongo2.mydomain:27017" },
      ]
   }
)

This will make the new instance start getting data from the original instance. Now you have a working primary and secondary. It can be verified by running rs.conf()

Wait, you are not done yet

The final super important point to mention that is missed in MongoDB’s docs, is that a primary-secondary cluster is not good enough for mongodb’s high availability- meaning when the primary crash, the secondary won’t be able to “vote itself” to become the new primary. You must have 2 secondaries at least for that to happen, or an arbitrer.

Option 1: Creating another secondary

Just take again another server from the image you have, clean its mongo data files, update replica in mongo config and this time run on the primary rs.add("mongo3.mydomain:27017") to add the new secondary to the cluster. This means of course you need to pay for the same machine size and storage costs. If you don’t need extra survivability or read replica continue to the next option instead.

Option 2: Creating an arbitrer

Just take again another server from the image you have, clean its mongo data files, update replica in mongo config and this time run on the primary:

rs.addArb("mongo-arbitrer1.mydomain:27017")

Summary

Congrats! You have made a standalone into a replicaSet in a few clicks. Of course the best option is to write an automation to create replicaSet clusters from the first place but for a manual one time process for an already in use mongodb I hope this quick tutorial was nicer to follow :)

Yours,

Regev Golan

See the system log for errors:

Seeing volume mounting issues? It means you need to fix the /etc/fstab using another machine. Follow these steps:

1. Create a new machine with the same instance family you want to recover.
2. Before starting the new machine, detach the root volume from the machine you want to recover and attach it to the new machine. Rename it in case you have the /dev/sda1 in its Name tag (in AWS Console) to make sure AWS won’t attach it as a root volume to the new machine as well.
3. Start the new machine
4. If it is not started (due to the same root volume conflict probably), try to snapshot the old root volume, then create a new volume out of it, and then attach the new one. Sometimes volumes get messed up and the snapshot trick will fix it.
5. lsblk to see the name of the attached volume
6. mkdir /mnt/recovered
7. mount -o nouuid /dev/nvme1n1p1 /mnt/recovered
   The -o here is to overcome the issue (mount: unknown filesystem type '(null)') of root volumes having the same UUID
8. cd /mnt/recovered/etc
9. vi fstab
10. Add ,nofail after the defaults . This will allow the old instance to start and for you to do the right thing and change your /dev/nvme2n1 with a proper UUID to prevent it to change after a restart (to get the UUID use blkid).
11. Shutdown the new machine. Detach the recovered volume and attach it back to the original machine (make sure to name it sda1 when prompted to be able to start it, otherwise you’ll get the “no root volume found” error). Start it. Done. You’ve saved the day :)
12. Remember to terminate the recovery machine $$

Best,

Regev Golan

TL;DR

We, users of open source, need better tooling to quickly assess security, quality, maintainability and legality of open source repositories. I am a Computer Science Masters of Science student who is researching open source and creating a system to answer current gaps. In this article I am “open sourcing” the kickoff of my work.

Open Source

Open source has become a huge community of developers. Only on GitHub for instance, as of Oct 19, there are almost 33 million users. To put in perspective, it may not sound a lot compared to social networks with +1B users so to better understand this 33M number- it’s 7M more than the entire population in Australia! 🇦🇺). Those users are working on more than 29 million public repositories.

Our story begins in 1983

In 1983, Richard Stallman launched the GNU Project to write a complete operating system free from constraints on the use of its source code. This was the kickoff for the GNU open source licence which is one of the most popular licenses in use today (right behind Apache and MIT as of 2018) for open source projects ever since Linus Torvalds released Linux to the world back in 1991. People are using open source for more than 35 years now. Compared to a man’s lifespan- open source should now be in its golden time 👨 . Is it?

README.md is not enough

Meet Joe. Joe is an average developer who needs to build a web service in python. He doesn’t know which framework he should use. No problem. A bit of Google and Github scanning to find a nice article comparing all the most popular frameworks:

Joe thinks to himself: “OK, there are several here that can match my specific need. I’ll simply go for the most popular one.”

Wait, there is more

How would you define “popular”? Github’s stars? ⭐️ Forks? contributors? PRs count? Latest commit date? Insights? How do people talk about it on Stack overflow ? Twitter? and what about security? Is it safe to use? Is the license 👨‍⚖️ suitable for me? How clean is its code base if I’ll need to understand it deeper? How well was it documented? You see where I am getting. It can take Joe hours and days to examine open source repos.

Do you remember that commercial above? To educate against piracy of movies or music download, they used a car. Let’s go to the vehicle industry one more time to justify what I am about to say:

You wouldn’t buy a used car without getting your car mechanic to vet it

What makes Joe think he is qualified enough to vet an open source repository? There are so many things to consider, as I mentioned above. Where is the mechanic that can easily vet it all for Joe and give him a detailed report and summary on the repository in question?

Innovative inspiration- sourcecred.io

You can’t really get the picture of maintainers activity or community pulse by checking out the “committers count”. It is frustrating and misleading. Then came sourcecred.io (let me help you read it- “source-cred” as in “credit”). The idea behind it is that you wouldn’t say the USA All-Stars basketball team equals to your high-school’s team just because both of them have 5 team members and are playing once a week, right? sourcecred is doing an awesome work in that domain using open plugins architecture and community endorsement to close the gap of correctly estimating the credit of the contributors to the repository’s life.

This is what I need

We have talked about the background and the problems with using open source. Let’s get down to specify the requirements from a solution:

A system that will examine open source repository and will grade it for its quality, community, security, license, …. The list is too long. Every open source user cares about a couple of other things as well. We’ll need a pluggable system that will be easily configurable and extensible by the community. Each plugin will know to do a specific evaluation and the mother system will merge it all to a cohesive report and a final grade.

Meet “vett”. The solution.

vett will know to answer the following question:

Should I use this open source?

vett will utilize a pluggable design pattern to make it easy for the community to extend it with all the tools open source users need to vet open source repositories on all of the different aspects we have discussed. Each vett user will be able to assemble their own suite of plugins to look into what they care the most, or use the community/default standard to go through all the common practices.

Don’t get excited yet. Just tell me what you think

Nice to meet you. Thank you for reading thus far :)

My name is Regev Golan and I am a Computer Science Masters student who is starting his thesis project. I am researching open source and building this “vett” system. I will be happy to hear your thoughts. I believe in feedback prior to starting to code 💻

I am also a believer in experiencing from first hand any research you are doing, so if one is doing a research about open source- He or she should also open source the research itself. Right? :) Please see the following directory of articles I have gathered to understand open source better.

SoA

Main question I am asking and welcoming specific feedback to is what is the State-of-Art practices regarding evaluating open source? How do you do it in your company? What do you care about when asking “should I/we use this open source”?

Contact me

I’ll appreciate your claps to know you like the direction I am taking 👏

Comment / connect me / join the gitter channel. Let’s talk! 📣

Stay tuned. Hopefully I’ll be able to share a quarterly article about my progress and open sourcing my findings, materials and of course codebase (star it⭐ ️and watch 👁 to be updated).

Thanks

1. “MTA, The Academic College of Tel Aviv–Yaffo” — The college I have the privilege of learning for the M.Sc, and especially Dr. Uri Globus for his amazing mentorship.

1. HiredScore — The revolutionising HR-Tech start-up I am a part of for the past 3 years as a software engineer. Thanks team for your support allowing me to expand my horizons with this academic degree.

Sincerely yours,

Regev Golan

Assuming you work on a MacOS:

It is hard to drive a car when you can’t see the road

Do yourself a favour and install a modern shell first! I recommend iterm2 + zsh + oh-my-zsh

brew install zsh
sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"

Now you can know immediately what is the current checked out branch you are on, the status, etc...

Make the basic flow of development

(starting with working directly on master for simplicity, later showing work with branch):

➜  git clone git@github.com:look4regev/git_lab.git
Cloning into 'git_lab'...
remote: Counting objects: 58, done.
remote: Total 58 (delta 0), reused 0 (delta 0), pack-reused 58
Receiving objects: 100% (58/58), 2.18 MiB | 265.00 KiB/s, done.
Resolving deltas: 100% (12/12), done.
➜  cd git_lab
➜  git_lab git:(master) git pull -r # Pull latest with rebase
Already up to date.
Current branch master is up to date.
➜  git_lab git:(master) git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean
➜  git_lab git:(master) echo "\n hello" >> moshe.txt # Make changes
➜  git_lab git:(master) ✗ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

modified:   moshe.txt

no changes added to commit (use "git add" and/or "git commit -a")
➜  git_lab git:(master) ✗ git diff
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
modified: moshe.txt
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
@ moshe.txt:6 @
Guess What ?

Oh My Fucking God !
\ No newline at end of file
Oh My Fucking God !
 hello
➜  git_lab git:(master) ✗ git commit -am "Add all files to commit in one command"
[master 24ee76e] Add all files to commit in one command
 1 file changed, 2 insertions(+), 1 deletion(-)
➜  git_lab git:(master) git push

Simple right? Let’s recape:

1. Clone the repo
2. Pull it (if it was already cloned)
3. Check for status
4. Make changes
5. See the changes (Highly recommended to work also with diff-so-fancy)
6. Commit
7. Push

Now to work with a branch

➜  git_lab git:(master) git pull -r
Already up to date.
Current branch master is up to date.
➜  git_lab git:(master) git checkout -b mywork # Create a new branch and checkout
Switched to a new branch 'mywork'
➜  git_lab git:(mywork) echo "hello from branch" >> moshe.txt
➜  git_lab git:(mywork) ✗ git status
On branch mywork
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

modified:   moshe.txt

no changes added to commit (use "git add" and/or "git commit -a")
➜  git_lab git:(mywork) ✗ git diff
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
modified: moshe.txt
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
@ moshe.txt:6 @
Guess What ?

Oh My Fucking God !
\ No newline at end of file
Oh My Fucking God !hello from branch
➜  git_lab git:(mywork) ✗ git commit -am "Commit from branch"
[mywork 01de354] Commit from branch
 1 file changed, 1 insertion(+), 1 deletion(-)
➜  git_lab git:(mywork) git push --set-upstream origin mywork
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 315 bytes | 315.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
remote:
remote: Create a pull request for 'mywork' on GitHub by visiting:
remote:      https://github.com/look4regev/git_lab/pull/new/mywork
remote:
To github.com:look4regev/git_lab.git
 * [new branch]      mywork -> mywork
Branch 'mywork' set up to track remote branch 'mywork' from 'origin'.

Pretty much the same except for the use of a new branch and pushing it to origin. Now to make a PR, let’s say in Github in this case- look how nice they are to suggest us the direct link to make a PR from this newly created branch. To merge the branch to master I recommend do it from the Github:

Be advised, when you merged from github it means that now your local repo is out of sync so to get the latest master changes:

➜  git_lab git:(mywork) git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
➜  git_lab git:(master) git pull -r

Now that was easy.

Aliases

If it looks long and tedious to write all this text, remember you can have quick aliases for everything. For your few weeks with the terminal make the full commands to make sure you know what is happening but then you can move to use the suite of aliases that are automatically installed with oh-my-zsh such as:

gpsup # git push --set-upstream origin mybranch

Problems

Get latest Changes from master

➜  git_lab git:(mywork) git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
➜  git_lab git:(master) git pull -r
git checkout -
Already up to date.
Current branch master is up to date.
➜  git_lab git:(master) git checkout - # Go back to last branch
Switched to branch 'mywork'
Your branch is up to date with 'origin/mywork'.
➜  git_lab git:(mywork) git rebase master # Put the branch ahead of master
Current branch mywork is up to date.
➜  git_lab git:(mywork) git push -f # You changed the history so must push force

Conflicts

When getting changes from master or to master you’ll probably have conflicts from other people’s changes. Don’t be panic, this is how you handle it like a boss:

➜  git_lab git:(mywork) git rebase master # Read what happens:
First, rewinding head to replay your work on top of it...
Applying: Commit from branch
Using index info to reconstruct a base tree...
M moshe.txt
Falling back to patching base and 3-way merge...
Auto-merging moshe.txt
CONFLICT (content): Merge conflict in moshe.txt
error: Failed to merge in the changes.
Patch failed at 0001 Commit from branch
Use 'git am --show-current-patch' to see the failed patch

Resolve all conflicts manually, mark them as resolved with
"git add/rm <conflicted_files>", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort".
➜  git_lab git:(549c327) ✗ cat moshe.txt # Git shows you the conflict:
123

Guess What ?

<<<<<<< HEAD
Oh My Fucking God !Big mess
=======
Oh My Fucking God !hello from branch
>>>>>>> Commit from branch
➜  git_lab git:(549c327) ✗ vi moshe.txt # Editing and fixing the file
➜  git_lab git:(549c327) ✗ cat moshe.txt # See how I want the final version will be:
123

Guess What ?

Oh My Fucking God !Big mess->hello from branch
➜  git_lab git:(549c327) ✗ git add moshe.txt # Mark the conflicts were resolved
➜  git_lab git:(549c327) ✗ git rebase --continue # Notice the branch is coming back to "mywork" after being on detached
➜  git_lab git:(mywork) git push -f

Recap of conflict resolving:

I rebased master to my branch which made a conflict. After editing and solving the conflict I am adding the file and continuing the rebase. At the end important to notice to push force again because the history was changed. If something goes off in the middle of the rebase you can always cancel it:

git rebase --abort

Summary

The terminal is great and gives a lot of visibility to what you’re doing. With time you’ll figure it easily how to solve edge cases but this workflow I gave you is sufficient to get you started. The terminal is your best friend once you know how to use it. Hope that this article made you closer ;)

Feel free to give a clap^)^ and connect through my Linkedin :) Regev.

Just like shooting a spaceship, you start working your fastest, and then reaching to new heights, environments and capabilities that push you to accelerate and to go faster. A great workplace, manager, a team and yourself are all critical to allow that. I work as a software engineer for a start-up named HiredScore which I see as a place obligated to that principle. In this article I’ll try to get into the details on what makes HiredScore to be such a place.

Management is about persuading people to do what they don’t want to do, while leadership is about inspiring people to do things they never thought they could. (Steve Jobs)

HiredScore — The Workplace

We are an HR-Tech company trying to revolutionise how enterprises hire better. How can a group of 35 people can achieve that? You take each worthy opportunity, push it fast, than accelerate it. The people will follow.

One place that immediately pops into my mind as a role model for this attitude is the amazing Jack Ma, founder of Alibaba, from this very early inspiring speech to his employees back in 1999:

https://www.youtube.com/watch?v=Up9-C4_8dVo

If you want to build a ship, don’t assign people tasks and work, but rather teach them to long for the endless immensity of the sea
(Antoine de Saint-Exupery)

Manager

A lot has been said about the importance of a manager on the people’s abilities and results. A great manager puts you in places that keep surprises you to achieving them.

Team

One can believe when he sees other doing the impossible. Be in a team of great people and you’ll find yourself soon doing more by yourself.

A bird sitting on a branch doesn’t fear that it will break- The bird trusts its wings and not on the branch that she sits on

You

People want to be all that they can be. I say there is no such thing “can”. Add or change something and you are in a new “can” state.

Work for a great company, be in a wonderful group of people, ask to be pushed and to help you go faster. Do it.

Thank you, my great TEAM at HiredScore, for empowering me to start fast and together to keep accelerating.

Regev Golan

Have less bugs and better code style in Python with Pylint static code analysis- This is how to do that (With PyCharm IDE):

Install pylint: pip install pylint

Use pylint as an external tool- unfortunately PyCharm doesn’t support changing its python linter:

Go to Pycharm > Preferences > Tools > External Tools > Add (“+” sign) > Fill in the details of pylint:

Pay attention I am not calling the pylint program, but a script I have. This script is in order to have one centralized place that holds the pylint run configuration, able to run on a single file or on a complete dir tree and finally it knows to work inside your python virtualenv (to be able to validate imports):

run_pylint_validation.sh:

#!/bin/bash

# No files argument will run on all dir tree
FILES=${1:-"*.py"}

# Should get path from inside the virtualenv
PYLINT_PATH=${2:-"pylint"}

# Disable common bugs with pylint 1.6.4
find . -type f -name "$FILES" | xargs $PYLINT_PATH --reports=n --disable=C0111,E0401,W0621,E1129,E0202 --rcfile=~/.pylintrc

One final very useful thing to be able to shoot up the pylint validation on the file currently active on PyCharm is to link it to a keystroke:

That’s it! Now you can mark your code on the editor > right click > tools > pylint. This will show you a report of the errors.

Happy coding :)

Regev Golan

Yarn is the new Javascript package manager in town, created by Facebook, and it is so cool, useful and easy to adopt, that NPM may soon become obsolete. In this short example I’ll try to clarify this key killer feature of Yarn, that is the hardest one to understand: The yarn.lock file.

Let’s say Alice did a small change in the package.json of our project and committed it to master.

Bob pulled locally, and did a `yarn install` but then his git showed uncommitted differences on the yarn.lock file even though Bob didn’t changed anything. Why?

yarn.lock file actually warned us that something is not right by showing the uncommitted changes. Alice touched the package.json but didn’t actually re-run the `yarn install` creating a “non synced” package.json and yarn.lock. This is exactly the big value of yarn over npm because Alice “caused” a situation in which our web-service is going to be different than what Alice have locally, which is a bad thing and can cause “but it worked on my environment” problems.

With the lock file, yarn shows the power of another layer of validation between environments.

See great further reading on this amazing package manager from https://yarnpkg.com/

Last point I want to share from my experience is that migrating all of our production services and development environments from npm to Yarn went very smoothly and easily.

Goodluck!

Regev Golan

1. GIT source control- learn to work with the CLI. Every company has their own set of tools so instead of learning yet again a new GUI, the CLI is unanimous and powerful.
2. GitHub- learn to work with a known git repository such as GitHub and make a full common dev flow including branch-PR-review-merge. In addition to knowledge, your style is also important so use git like an open-source pro with following git commit style.
3. Time is money- your time as a software developer is very expensive so every work you do should have a clear purpose and a problem that need to be solved so get used to thinking and acting that way.
4. VPC- servers should not be freely accessed for obvious security reasons so most tech companies put their servers behind a VPN (Virtual Private Network). Worth a few minutes of read time.
5. Cloud- AWS/GCP/Azure- cloud providers has so many services that tech companies use so go through them, understand their purpose and go attend a meetup or a convention about it.
6. CI/CD- get to know some continuous integration, build and deployment tools such as CircleCI, Jenkins & Travis.
7. Code style- learn the recommended style for your programming language and use it (for example pep8 for python). You’ll get rejects and be ashamed if you’ll have bad style in your new work.
8. Linux- learn Linux basic commands, basic shell scripting and using vim editor because most servers today are Unix based and with the DevOps methodology most companies adopted, you are likely to handle also some operations and deployments tasks.
9. Scripting- you’ll need to do some quick tools so play around with scripts in Python for example, learn to use a shebang and executable scripting grants.
10. Embrace tools to empower you- most people use oh-my-zsh add-on for the zsh shell in your new workplace? It’s probable for a good reason, don’t fear from new tools, quickly adopt and use them to make you work faster. It’s accepted to have first weeks of learning, use it.
11. Request access before you start- when you get to know your future work place, you can start learn things prior to the first day, giving you a head start and the time to acquire the skills needed for your new job.
12. Lastly, spend some time to learn cool tools and technologies to get to use to the shock of the full stack of technologies in your new workplace. Be at the top of your game.

Goodluck,

Regev Golan