DEV Community: Gregory Witek

From init.vim to init.lua - a crash course

Gregory Witek — Mon, 01 Nov 2021 21:21:12 +0000

Earlier this year maintainers of Neovim have released version 0.5 which, among other features, allows developers to configure their editor using Lua instead of VimL. In this article I'll share a few basic rules on how to transition from one configuration to another. This is not a complete guide, but it covers almost 100% of what I needed in order to completely move away from init.vim to init.lua. In the bottom of the article you're also find a link to my config files so that you can look at them and copy if needed.

Lua in 1 minute

First, it's good to spend 10-15 minutes learning Lua in order to easily write the new config. I used the Learn X in Y minutes page, but I guess anything works. If you want to spend 1 minute instead, here you go:

-- this is a comment
num = 22 -- this global variable represents a number
local num2 = 33 -- local variable
str1 = 'this is a string'
str2 = "and so is this"
str3 = [[and this is a string too]]
str4 = "string " .. "concatenation"
val = true and not false -- booleans and logical operators

if str1 == 'something' then
  print("YES")
elseif str2 ~= 'is not equal' then
  print('Maybe')
else
  print('no')
end

function printText(text)
  print(text)
  return true
end

tab1 = { 'this', 'is, 'a', 'table' } -- aka array
-- tables are both arrays and dictionaries
tab2 = { also = 'this is a table' }
tab2["new_key"] = "new value"

print(tab2["also"])

require('plugins') -- will find and execute plugins.lua file

There's of course way more than that, but for me this + copying some stuff from plugins documentation was enough to write my config files.

Config basics

Ok, now onto the config. In Vim we use a number of functions that are dedicated to the editor configuration (the whole language is dedicated to it, really). In Lua we're using a general programming language and we'll use an API to interact with Neovim configuration:

vim.cmd("set notimeout") - this is a safety net, whatever string you pass as parameter to vim.cmd will be interpreted as VimL. For multiple lines, wrap string in double brackets:

vim.cmd([[
set notimeout
set encoding=utf-8
]])

vim.g.mapleader = "," is equivalent of let g:mapleader = ','; vim.g is a table represeting global variables
vim.o.encoding="utf-8" is equivalent of set encoding=utf-8; vim.o is for global options, vim.wo for window options and vim.bo for buffer options
vim.fn is a table representing functions. You can refer to a function thisIsMyFun using vim.fn.thisIsMyFun or vim.fn["thisIsMyFun"] and you can call it using vim.fn.thisIsMyFun() or vim.fn["thisIsMyFun"]()
vim.api is a collection of API functions. I used only one: vim.api.nvim_set_keymap that maps certain key combinations to some functions (more about it below)

Moving settings to Lua

Moving most of the settings is pretty straightforward. You just replace set x = y with vim.o.x = "y". There are however some catches:

pairs of boolean settings are merged into one setting, e.g. instead of set wrap and set nowrap you write vim.o.wrap = true and vim.o.wrap = false
home directory problems - I had issue using ~ as a reference to home directory for some backup files etc. so instead I set HOME variable that I used by writing HOME = os.getenv("HOME")
string concatenation uses .. operator, so to refer to my backup dir I wrote vim.o.backupdir = HOME .. "/.vim/backup"
double backslash - if you want to pass a special character \t to Vim, you need to write it as "\\t" in Lua

Mapping keys

The Lua API has a function to map keys to some functions. The function signature is vim.api.nvim_set_keymap(mode, keys, mapping, options), where mode refers to a letter representing editor mode ( n for normal, i for insert etc.) just like in original vim functions like nmap or imap, keys is a string representing a combination of keys, mapping is a string representing what the keys map to, and options are a table where you can pass some additional settings. Example:

vim.api.nvim_set_keymap(
  "n",
  "<leader>a",
  ":Git blame<cr>",
  { noremap = true }
 )

is equivalent of nnoremap <leader>a <cmd>Git blame<cr>.

I didn't check what are all the options that can be passed in the 4th argument, 2 that I used are noremap = true and silent = true.

I also wrote myself a few simple functions to avoid typing vim.api... every time:

function map(mode, shortcut, command)
  vim.api.nvim_set_keymap(mode, shortcut, command, { noremap = true, silent = true })
end

function nmap(shortcut, command)
  map('n', shortcut, command)
end

function imap(shortcut, command)
  map('i', shortcut, command)
end

With these functions my example above became just nmap("<leader>a", "<cmd>Git blame<cr>").

Package manager

It's very probable that you already use some package manager for Neovim, and when moving to Lua you don't need to change it, you can just wrap your whole plugin list in vim.cmd and continue using it as before.

I decided to try a new manager called Packer, which is written in Lua and requires Neovim 0.5. The installation was a bit troublesome, because I didn't know what packpath is and that Packer requires some very specific names of the directories to find packages. Anyway, I moved it to ~/.config/nvim/pack/packer/start/packer.nvim directory and it worked nicely (though I'm sure there's a better way to install it).

Besides the installation, Packer is both easy to use and has all the features I need (and a lot that I don't need). The basic config example looks like this:

return require('packer').startup(function()
  use 'wbthomason/packer.nvim'

  -- common
  use 'tpope/vim-fugitive' -- Git commands
  use { 'tpope/vim-rails', ft = "ruby" } -- only load when opening Ruby file
end)

If you need some more advanced functionality, I recommend checking the documentation.

Other plugins

There is a number of other plugins that are available for Neovim 0.5 and I found myself replacing some of plugins I had used before with the new alternatives. I won't cover them here (maybe in another post), but here are a few that you can check out:

nvim-lspconfig together with nvim-lspinstall and lspsaga.nvim use the new, built-in LSP in Neovim and provide some useful functions. Together they allow me to easily install and use language servers (e.g. to display function documentation or jump to a definition). Together with nvim-compe (autocompletion) I use them to replace Ale and coc.vim,
telescope.nvim replaces any search plugin you use ( ctrl-p, fzf.vim etc.)
gitsigns replaces vim-gitgutter

There are a few more like lualine.vim that can replace powerline or airline, but I'm yet to try it out.

Summary

The whole process of moving 350 lines of init.vim to init.lua took me around 2h, including time to organize the files (Lua allows you to use multiple config files, see my example below) and excluding time to play with new plugins. I spent around 1 hour moving 90-95% of the content, and another hour solving some issues like home directory or some broken config. In the end I found the whole process rather quick and definitely rewarding, though I'm sure a lot of things can be done better. If you plan to use new capabilities of Neovim 0.5 I definitely recommend moving your config to Lua.

My config in VimL and Lua: https://github.com/arnvald/viml-to-lua

Why nobody hires junior developers and what happens next

Gregory Witek — Tue, 28 Sep 2021 20:55:56 +0000

While the number of job opportunities for software developer skyrockets together with salaries all around the world, fresh grads and junior developers struggle to even get invited for the interviews. Why does it happen and can we do anything about it?

Tech industry has still relatively low barrier of entry, especially when compared to other well-paying jobs (think 5+ years of school for lawyers and doctors). However looking at the number of entry-level job offers on LinkedIn or other job portals, it seems that the golden days for bootcamp graduates and self-taught devs are over. Finding job as a junior has already been challenging in the last 2 years, but 2021 seems like a real bad time to be searching for the first job in tech.

In the last few years I've been heavily involved in hiring, I've worked with a number of recruiters, and I spent some collaborating with coding bootcamps. Based on my discussions adn observations, I believe there are 2 main reasons behind the current situation: tragedy of the commons and COVID-19. The first one has been a problem for years, the second one has amplified the issue.

Short-term gains, long-term loss

Imagine a following situation: a group of fishermen have access to a lake with fish. The lake does not belong to any particular person, and all fishermen go there daily and catch a few fish to feed their families and sell to fellow townmen. That situation lasts for years and remains stable. Then one day one of the fishermen figures out that he can catch more fish and sell them also in other towns.

Soon other fishermen copy that model and everyone happily catches a lot of fish and makes more money. Until one day the fishermen notice that it takes them more and more time to catch fish, until one day they come home empty handed. The fishermen never considered that they need to maintain the population of fish in the lake, and because of their greed they caught all fish and left the lake empty.

This kind of situation has a name - the tragedy of the commons - and you can think about it as a multiplayer prisoner's dilemma. The dilemma is simple - you can choose to cooperate with others (limit number of fish you catch with sustainability in mind) or betray them (catch more fish for higher short-term gains). However if enough people betrays others, eventually they deplete the resource they use and everyone loses.

Tragedy of the commons is not just a thought experiment. It happens in real life, too. A fairly recent case comes from Thailand and its famous Maya bay, featured movie "The Beach" with Leonardo di Caprio. Maya bay is a gorgeous spot located at one of the Phi Phi islands that every day used to draw thousands of tourists. Unfortunately the trip organizers were too greedy and the fragile ecosystem of the bay could not handle the number of boats and people, and the amount of trash left there. In 2018 the government of Thailand decided to close the island for recovery, and as of September 2021 it remains unavailable for tourists.

A photo I took in Maya bay back in 2017, while it was still open (though the damage was already very visible)

Too many betrayals among tech companies

What does all this have to do with hiring in tech? We're dealing with a similar kind of a problem:

everyone wants to have senior developers, because they provide value
in order to have a senior developer, we need a junior dev + a lot of time + proper training
in order to train junior developers, company needs to invest: senior developers spend less time on product (sacrifice immediate profit) so that they can support others (with long-term gain in mind)

Here's the twist - a company might invest in a developer, but not profit from them, because once that developer gains enough experience and skills to provide value, they'll start getting other job offers, and as we know changing jobs brings higher raise than staying.

Knowing all that, companies can take different strategy depending on their circumstances:

top companies (big tech, high growth startups) figure out that they don't really need to hire a lot of junior developers, they'll just hire the best seniors from other companies by offering them way higher compensation
above average companies (other highly profitable enterprises) figure out they don't need to hire that many junior developers either, they'll just hire senior or mid-level devs who can't get a job at top companies
the remaining companies know they are at the bottom of the food chain - they train developers that later find better paying options. These companies still hire juniors, because they don't have much choice, but their hiring becomes limited because there are not enough experienced devs for mentoring
software houses are a bit of a special case - since they charge per person per day, even less experienced developers quickly become profitable for the company. It's tough to convince customers to add junior dev to the team, but often software houses just promote people very quickly

We end up in a situation where the demand for senior developers far outweighs the capacity and willingness of the companies to train juniors. Up until recently it wasn't that bad though, we were in kind of an stable situation - the number of developers needed was growing steadily, the attrition was stable, companies were offering some internships and entry-level positions, universities and bootcamps provided streams of candidates. It wasn't very easy to get the first job in the industry, but with enough effort and determination it was possible even for someone who has just started programming.

And then came the pandemic.

Nobody hires juniors anymore

After the initial shock of the pandemic, all the hiring freezes and layoffs, companies figured out where they stand and started hiring again. The bounce was strengthened by sudden spike in demand for digital services (retailers moving to on-line, booming businesses like virtual events and all kinds of deliveries), influx of cash from investors, and the need to catch-up after the hiring freeze.

Together with a lot of burnout cases and people taking longer leaves, it created a spike in need for experienced engineers, and made almost no impact (or maybe even a negative impact) on a number of entry-level roles. With all the pandemic-related challenges and opportunities, investing in junior developers is not an urgent matter.

Remote work

Working from home comes with a lot of benefits, but also plenty of challenges - how to keep the communication effective? How to ensure people keep the healthy balance between work and time off? How do we make remote teams work effectively? How do we balance between seeing each others faces while avoiding the fatigue related to constantly being on the camera?

We all still struggle with that, but then comes another problem - how do we onboard new people? We need to deliver them the equipment, make sure they have all their need for their home office, but more importantly, we need to figure out how to share the knowledge and feel people excited about joining the company. There's no onboarding day anymore, we can't gather all new joiners in one room anymore to let them meet each other and to have a big welcome breakfast.

And then comes another complication - what if these people are fresh grads? How can we hire people for their first job while we struggle with onboarding in general? The answer is - let's put that on hold and figure it out later. Junior roles are traditionally the easiest to fill, so we can just stop for a few months and hire them later, when we are ready.

Everyone's understaffed

The 2nd effect of the pandemic is that everyone urgently needs senior developers. Gergely Orosz wrote a great blog post about it, where he explains in detail why there's a shortage of senior developers:

sudden demand for digital products and services means companies need to scale and, in order to remain competitive, keep innovating, so they need experienced devs
demand for developers (and limited supply) means companies have to pay more and offer more benefits
that means it's a good time to change jobs - new job usually means a nice raise, but this time instead of 20% it can be even 50-70%
that creates a lot of movement in the market, on one hand companies lose people, on the other bring a lot of new devs, so they need to spend a lot of time onboarding (which also puts pressure on remaining employees!)
on the other hand people are exhausted because of the pandemic and want to take longer break; with the huge demand for developers they feel more comfortable taking a few months off (so supply is even smaller)

Once again, this affects junior developers in a negative way. Since everyone desperately needs senior devs, nobody wants to put even more pressure on their devs to help onboard and train junior devs.

And because a lot of tech companies have been playing defectors for the last few years and didn't invest enough in junior developers when they could, now everyone struggles.

The way forward

The question remains - what now? Sooner or later the situation will become more stable, but is there anything we can do to help each other? None of us alone will make a big difference, but we still can help to bring a little bit of balance in the industry, and everyone can contribute.

Why should you care?

One thing that you might be asking yourself is "why do I care?". If you're a senior developer, you technically benefit from the current situation - you can easily jump jobs and get a significant raise every time. But even then, lack of junior developers has a negative impact on your career - when there are no junior developers, there are no people to teach, so you can't improve as a mentor. There are no people who can take easier tasks, so you have to do them. Finally, the teams can't grow as fast as they could, so even if you could get promoted to lead your own team, your company only hires senior devs, and it's hard to find them.
And if you're a lead dev or a manager, you should care about building a stable situation where more experienced developers can make a bigger impact by supporting junior devs and focusing on tasks that only they can do. Without junior developers, that balance is gone.

As a junior dev looking for work

If you're currently looking for your first job in the tech industry, there are 2 things that you should do: expand your search and make it sustainable.

Expand: reach out to companies directly. Smaller companies could offer you a position even if they are not actively looking for junior candidates. Attend events - there are a lot of virtual, free meetups where you can chat with people. Go beyond the stack that you know, if you know React check also positions for Vue or Angular developers.

Make it sustainable: it may take you even 12 months to find a job. Pace yourself, make a list of companies you want to write to and make it a habit to send a few applications a day. Take some days off, remember to relax, you are in it for the long term.

A year ago I made 2 videos where I talked exactly about this topic. Check them out, each of them is 5-10 minutes:

As an employed developer

If your company doesn't hire junior developers at all, understand why, see whether it's a rule or just nobody thought of opening junior roles. Suggest to your managert that it would help to have someone less experienced, so that you can teach them but also delegate simpler tasks that don't need someone with your experience. If not junior devs - maybe interns? In my first job I started an internship program that provided a lot of benefits over the years. If you work for a small company, it should be much easier than in a corporation!

If you are willing to help others in your free time, you can become a mentor or a coach - there are organizations out there who help people break into the industry. In the past I had a pleasure of working with a free, volunteer-based bootcamp. I helped someone to change their career, and while doing this I became a much better mentor than I used to be. It's a hard, but very rewarding work.

As a manager

If you're an engineering manager, you have an impact on hiring - use it! If your team is doing well, ask your manager for additional headcount and make sure it's an entry-level position. Talk to your peer and discuss with them how you can benefit from having more junior devs (I'll write about the benefits another time, stay tuned!). It's not an easy thing to do, especially if your company has practiced the parasite "only seniors here" model until now, but you can always try.

As an executive

If you're a VP of Engineering or CTO you are probably responsible for (or at least can influence) the hiring plans and strategy. Take junior positions into account - find a ratio that will work in your teams (1 junior in a team of 4 or 5, for example) and ensure that your company provides an inclusive, welcoming environment for people who have just started their career in software development.

Back to where we started?

The current tech boom won't last forever. Eventually things will become more stable. The world will keep innovating, the demand for developers will remain, but it won't be that urgent. In a couple of months the bounce caused by the pandemic will weaken and we'll go back to where we were before - a system where juniors don't have it easy, but where it's possible for them to get interviews, and eventually start their career in software development.

Why you should always negotiate salary and how to do it

Gregory Witek — Mon, 30 Aug 2021 22:17:03 +0000

Salary negotiation is a widely covered topic - there are many videos, articles, and even books about it. As software developers we are usually in advantageous position - our industry is booming and our skills are in demand, therefore we should easily be able to negotiate salaries. Despite this, a lot of people decide not to negotiate the offers they get, because they're afraid. In this article I explain why you should always negotiate the job offer using some basic concepts from probability and game theory. And in the end of the article you'll find my video where I explain how to start negotiation when you're afraid to do it.

Expected payoff

Let's start with a concept of "expected payoff" (also known as "expected value") that I'll use throughout the whole article. Expected payoff is a single numeric value that represents what you should expect on average when participating in some activity where you have multiple options and you don't know which one is better. Using the probabilitis and values of possible outcomes, you can calculate the expected payoff of each option and choose the one that has a better potential.

Let's say our friend offers us to play a game: we'll roll a 6-side dice, and if we roll 1 or 2, we pay our friend $10. If we get 3-4 we pay our friend $5, and if we get 5 or 6 our friend pays us $20. We can use expected payoff to see whether playing this game is a good idea or not. In order to do it, we multiply the value of each possible outcome by it's probability and then we add all the values together:

there's 1/3 chance that we'll roll 1 or 2, and we'll pay $10, so we write it as 1/3*$-10 = $-3.33
there's 1/3 chance we'll roll 3 or 4 and we'll lose $5: 1/3*$-5 = $-1.67
there's 1/3 chance we'll roll 5 or 6 and we'll get $20: 1/3*20 = $6.67

Now we add all the values together: $-3.33 + ($-1.67) + $6.67 = $1.67.

The outcome tells us that if we play the game on average we will win $1.67 (and if we don't play, the value is 0), so we should agree to play it. Of course the question remains why our friend wants to play such game if they're expected to lose!

On the contrary, gambling or lottery tickes have negative expected payoffs. If your chance to win $1 million is 1 in 5 million, and a single lottery ticket costs $2, then the expected payout is $-1.8. Of course people still buy those tickets hoping they'll end up millionaires, but technically it's better to invest that money in something else.

This concept of expected payoff, enriched with more advanced ideas from game theory or decision theory (that help in more uncertain situations), can be applied in multiple areas of life. Should you buy a house or rent? Should you invest in a new company? Should you choose a startup job offer over a corporate one?

Now let's have a look how it can help us understand that negotiating the job offer is a good idea.

The fear of losing the offer

One of the most common, if not the most common reason why people don't negotiate job offers is the fear that company will withdraw the offer. Candidates believe that if they ask for more, the company will decide that they don't want to have such employee. In order to understand why this makes very little sense to the company, let's use the expected payoff.

It's very hard to put some specific value to the outcomes, hiring a candidate does not directly translate to a profit, so for now I'll use abstract units. Let's say the company made an offer of $100,000 and the candidate asks for $120,000 instead. The company can't increase the salary, and therefore they have 2 options:

rescind the offer
tell candidate that they won't offer more, but leave the offer on the table

In terms of payoff, we can assign value 1 if the candidate joins the company, and 0 if they don't. The question is what should the company do.

The 1st option means the candidate won't join for sure, so the expected payoff of that strategy is 0. The 2nd option has some uncertainty - the candidate will probably reject the offer, but there's some chance they'll accept it. If we assume that there's 10% chance that the candidate will still join the company, then the expected payoff is 10%*1 + 90%*0 = 0.1, if we believe it's 5%, the payoff is 5%*1 + 95%*0 = 0.05 . Even if the chance is just 1%, it's still better than withdrawing the offer!

Of course reality is more complex - maybe the company has just 1 seat and they have another, equally good candidate waiting for their answer, but even in such case it's better to keep the offer on the table and tell the first candidate that the company needs an answer in 1-2 days.

Does it mean that offer withdrawal is a myth? No, it still happens, but the companies that do it either act irrationally, or they're looking for programmers that won't stand up for themselves, that will always blindly accept whatever the company offers. In other words - they're not good companies, and you're better off avoiding them.

To give more or not - company's perspective

That was a trivial example (we'll use it later though!) so now let's move to a more complex topic - should the company offer candidates more money when candidates negotiate, or not?

Let's imagine that we offer candidate $130,000 and the candidate asks for $120,000, so we can limit our options to following 3:

we don't offer anything more - in that case we pay candidate $130,000 and our potential payoff is 1, but the chance the candidate accepts the offer is only 40%
we try to meet the candidate in the middle with an offer of $140,000 - that gives us 80% that the candidate will accept the offer, but our payoff is lower, let's say 0.8 (maybe because that will make our profit from this candidate's work smaller, or because it sets a precedence where a new joiner will make more than others, etc.)
we agree to $150,000 - here we can expect 90% chance that the offer will be accepted, but again our payoff is a bit lower, let's say 0.6

The percentage here is not given and might vary a lot, the same with the payoff value - it's very hard to predict how a candidate joining us will impact the company. What I'm trying to model here is just a situation where we by sacrificing some value (paying higher salary) we increase the certainty that our offer will be accepted.

Now let's calculate the expected payoff for each of these 3 strategies:

$130,000: 40% * 1 + 60% * 0 = 0.4
$140,000: 80% * 0.8 + 20% * 0 = 0.64
$150,000: 90% * 0.6 + 10% * 0 = 0.63

In this case, negotiation is the best strategy. Again, these numbers are completely made up, the company has no details about the candidate's situation - maybe the candidate will walk away unless they get $150k, or maybe they're bluffing when they say they have other offers. What the company knows is how much they value the specific candidate and how much they can afford to pay. With this partial information they need to make a choice - and usually being flexible and offering the candidate at least some more salary can make a big difference!

You can try to model different scenarios and you'll get very different results. If it appears that it's the best not to give candidate more money, look at what made it happen. Is the certainty that candidate will accept the offer anyway very high? Or does the company assign much lower payout if they pay more than the initial offer?

To ask for more or not - candidate's perspective

Now let's look at this from the other perspective. Imagine that in our current job we make $100,000, and the company we applied for offers us $130,000. That's quite a difference, 30% bump in salary is a decent number! The question is then whether the negotiation still makes sense.

We're limit the payoff here purely to the salary and we'll omit other things like how much we like the company, whether it's a good career move etc. Then we have 3 options:

we accept the offer - with expected payoff equal to $130,000
we reject the offer - expected payoff is $100,000 (salary at the current company)
we negotiate the offer and ask for $150,000 - let's try to calculate a potential payoff here.

Let's say we can expect one of 4 responses from the company:

they withdraw the offer, which is extremely rare, so we assume there's 1% chance; this will have a payoff of $100,000 (we stay at current job)
they keep the offer at $130,000, let's say there's 39% chance this will happen
they raise the offer to $140,000, 40% chance
they give us $150,000, 20% chance.

Quick calculation: $100k * 1% + $130k * 39% + $140k * 40% + $150k * 20% = $137,700, a 6% increase over original offer (and we asked for 15% more).

Again, you can try different numbers - maybe you're asking for 50% higher offer and there's a lower chance that you'll get it? But as long as you know that the chance of losing the offer is very low, you should always see that it's worth it to negotiate!

How to negotiate

As I wrote in the beginning, the topic of negotiation is covered widely in a number of videos, articles, and books. Heck, there are even companies that specialize in helping candidates to negotiate good offers from big tech companies.

The most important step though is to actually start the negotiation. In the video below I spend a few minutes talking about why you should do it, and then I explain how to start negotiating if you don't feel confident about it. Enjoy!

Resources for Engineering Managers

Gregory Witek — Tue, 10 Aug 2021 11:00:00 +0000

On this page I'm collecting a list of various resources for engineering managers. I personally tried/watched/read all of them, except when I explicitly mention that I didn't. Some of the links below might be affiliate links. I'll keep updating the page, I'm currently building a list of articles that I recommend for all EMs, so check it again in the future!

I'm always eager to try and learn new things, if you have some recommendation, ping me on 🐦Twitter or send me an ✉️email.

Books

Accelerate: The Science of Lean Software and DevOps - probably more useful for VPs of Engineering or CTOs, this book talks about introducing Lean and DevOps practices in order to improve the efficiency of tech teams and build more resilient organizations.
Become an Effective Software Engineering Manager (🎥 video) - great primer on engineering managers' responsibilities, it guides reader through various challenges and recommends how to approach them. Great read!
Behind Closed Doors: Secrets of Great Management - not specific to tech industry, this book still provides useful advice for managers who want to improve their skills. It covers multiple topics like delegation, coaching, goals&objectives and more
The Culture Map - a business book that talks about working with different cultures. The author is a consultant and shares her lessons about working with companies all over the world, but I found this content very relevant to my work as EM, since I lead international teams and I strive to understand how my team members work
An Elegant Puzzle - a collection of tools and approaches to various problems you'll encounter in tech leadership role. I recommend it more as a reference book rather than reading cover to cover.
Leading Snowflakes - a good intro to engineering management; Oren Ellenbogen shares 9 lessons for new EMs
Manager's Path - a book that describes various states and challenges related to management in tech industry, from tech leads to CTOs
Managing Humans - engineering management stories from Sillicon Valley. I gave it 4 stars on Goodreads, though I read it a long time ago and don't remember much
Peopleware: Productive Projects and Teams - a classic book on productivity of software teams. It certainly feels dated (originally released in late 1980s), but 3rd edition was released in 2013 and the book still has a lot of value
The Phoenix Project - a handbook in form of a novel, the book teaches about DevOps practices and looks at managing teams from perspective of inputs and outputs
Resilient Management - a book for new managers, covers topics like setting clear expectations, and effective communication. Currently on my to-read list
The Software Engineering Manager Interview Guide - interview preparation book by Vidal Graupera (whose blog you can also find on this page)
The Unicorn Project - a sequel (I guess?) to "The Phoenix Project", written in similar style of a novel, this book focuses on good software development practices. In my opinion it's not nearly as good as the first book, but still an entertaining read

Tools

EasyRetro (formerly FunRetro) - my tool of choice when it comes to running team retrospectives
Notion - a favourite planning tool of many people, can act as a calendar, todo list, project management tool, and many more; comes with a generous free plan
Obsidian - a knowledge base tool that allows you to connect multiple pages witn linking mechanisms. It has a growing community and an ecosystem of plug-ins
Peakon - a web-based tool that helps to measure employee engagement, and allows employees to anonymously share feedback with their managers.
progression.fyi - a collection of career growth frameworks and matrices, not only for developers, but also testers, project managers, and more. Very useful when you're building a propression framework for your department or company
SourceLevel - a tool that uses various metrics to allow you to better understand your team's performance (I haven't tried it yet, and I still haven't made up my mind about how useful are such tools)
Todoist - a powerful todo app with clients for all major operating systems; free plan available
Typora - a desktop Markdown editor (Windows, MacOS, Linux) with a minimalist style and a lot of very well-thought features. One of my favorites, I use it to write a tech book with a lot of code examples, and to write work-related notes. Currently (August 2021) available for free

Blogs

Camille Fournier - blog by author of "The Manager's Path". Camille doesn't write often, but when she does, it's high quality content
Charity Majors - tons of thoughts about tech careers and leadership, a must read!
Managers Club - interviews and articles on engineering management, by Vidal Graupera, author of "The Software Engineering Manager Interview Guide"
Pat Kua - Pat is a coach and consultant and ex-CTO, on his blog he shares thought on the intersection of tech and management
Pragmatic Engineer - Gergely Orosz, an experienced engineering manager shares his lessons from Uber and Microsoft, and writes about topics like career progressions and salary negotiations
Silicon Vallye Product Group - blog focused on product managenemt, with a lot of useful content for engineering managers who closely collaborate with product teams
Will Larson - author of "An Elegant Puzzle" and "Staff Engineer", Will shares a lot of interesting thoughts on tech careers

Newsletters

Level Up - weekly content for leaders in tech by Pat Kua (who also writes a blog I list on this page)
software lead weekly - newsletter by Oren Ellenbogen (author of "Leading Snowflakes" - check books section), with content about people, culture, and leadership in tech. Going strong for more than 400 editions!
Tech Manager Weekly - another weekly newsletter with interesting articles about managing tech teams. Made by CTO Craft (check also communities section below)

Others

CTO Craft Community - CTO Craft is a company offering coaching and workshops for technical leaders. They have a free Slack community and organize a number of events, like conferences
Engineering Manager Slack group - a Slack community moderated by a group of volunteers
https://github.com/ryanburgess/engineer-manager - a more comprehensive list of resources with 100+ items for engineering managers, though it often lacks any description of an item
LeadDev - LeadDev is a full portal and an organization dedicated for tech leaders. It includes a ton of good articles, they organize events and workshops. Truly a great place for engineering managers.
Plato - a place where you can find mentors (paid service) or volunteer your time to help others. I currently participate there as a mentor.
Mentoring Club - a non-profit alternative to Plato, where you can find mentors or become a mentor. I haven't tried it personally yet.

The power of reduce

Gregory Witek — Tue, 27 Jul 2021 15:45:23 +0000

reduce (aka fold aka inject aka lfold) is a very powerful, flexible, and at the same time an unintuitive and controversial function. In this post I'll talk about what makes it both so flexible and unintuitive, and I'll present how other iteration functions like map or filter can be implemented on top of reduce. I'll use JS definition of reduce as a reference and I'll show what other languages do better in implementing this function.

Basics of reduce

reduce is a function that works on collections. It usually accepts 2 arguments: a reducer function and an optional initial value. reduce iterates over the collection, calling the reducer function for every element and passing the output of reducer to the next iteration (with one exception mentioned later). A simple example is calculating a product of all elements of the array:

// returns 2 * 4 * 6 * 8 = 384
[2,4,6,8].reduce((accumulator, el) => accumulator * el, 1);

The reducer function can accept up to 4 arguments:

accumulator - the output of previous iteration (in the first iteration it takes the default value, or if not provided, the first element of the array)
element - the current element of the array
index - the index of the current element of the array
originalArray - the whole array on which reduce is being called.

In the following example, the execution will look like this:

1st iteration: acc = 1 * 2 (output: 2)
2nd iteration: acc = 2 * 4 (output: 8)
3rd iteration: acc = 8 * 6 (output: 48)
4rd iteration: acc = 48 * 8 (output: 384)

If you want to understand it better and see more advanced examples, check the tutorial I recorded:

Use cases

reduce has traditionally been a part of functional languages, where it acts as kind of equivalent of for loops. It became more common thanks to a MapReduce framework which allows to easily parallelize operations that aggregate some data. MapReduce splits the work to be done in 2 parts - map part performs some kind of operation on each piece of data (this part can be done in parallel) and reduce then gathers all the output from map and combines the filan result (this part is done sequentially).

Let's say we want to count number of occurences of each word in a piece of text. We can split the text into sentences, and fo each sentence we can calculate number of occurences of each word in parallel. Then we end up with multiple dictionaries, let's say:

{ "dog": 2, "is": 2, "animal": 1, "and": 1, "mammal": 1},
{ "fish": 1, "is": 1, "animal": 1, "too": 1}

Then reduce function can merge these 2 dictionaries and calculate final output:

{ "dog": 2, "is": 3, "animal": 2, "and": 1, "mammal": 1, "fish": 1, "too": 1 }

Interestingly, reduce does not need map to achieve the result above - it's only needed in order to have the first part run in parallel.

Another common use case is to calculate some number that's based on a list of numbers. A good example is sum of squares that has a number of uses in mathematics like in linear regression.

I personally often use reduce in order to transform one dictionary into another (e.g. I might need to normalize keys, or update values). This is not possible in JavaScript though - I explain it a bit later in the article.

The controversy

For a number of reasons, reduce is a controversial function among programmers. In JS it gets quite a bad rep, like in the widely retweeted example below:

Jake Archibald

@jaffathecake

All code using array.reduce should be rewritten without array.reduce so it's readable by humans *mutes thread*

12:40 PM - 03 Jan 2020

It's not the only example, though. In Python, reduce was removed from the standard library and moved to functools library. It's still shipped as part of the Python language distribution, but in order to use it, you need to explicitly import it.

There are a number of reasons why reduce gets a bad reputation, the main of them being: for every use of reduce there's at least one more intuitive and more readable alternative.

For loops and other options

First argument for not using reduce is that many languages (mainly imperative/OO) there are always more idiomatic and intuitive ways to write code than useing reduce. The main solution is to use for loop, forEach function, or some kind of equivalent. Let's take the example from the previous section:

[2,4,6,8].reduce((accumulator, el) => accumulator * el, 1);

Another way to write is

const product = 1;
for (const el in [2,4,6,8]) {
    product *= el;
}

For programmers coming from other imperative languages, the latter version certainly feels more familiar. Is it clearly better though? I'm not so sure.

Readability

The second argument is quite similar, but focuses on reduce function itself - a lot of people say the function is hard to read. I partially agree with this. Most of the time I have little problem understanding what is the goal of reduce just by having a quick look, but because it can return anything, it's not as meaningful and intuitive as map or filter. What's more, if you want to use reduce in multiple programming languages, you'll have to remember that each of them has a different number and order of arguments!

There's one more thing that adds to the problem - the initial value, which is an optional parameter in reduce and which changes a lot about how the function works. If you have a collection of 10 elements, you can expect that it'll trigger 10 iterations, however if you don't pass the initial value to the function, there'll be only 9 iterations. That's because the first element of the collection will become the initial value. In a lot of cases, like when calculating a sum or a product, it doesn't matter, but when you want to calculate sum of squares, that missing initial value will break the function!

function sumSquares(ary) {
    return ary.reduce((acc, el) => acc + el * el);
}

sumSquares([1,2,3,4]); // => 30, works!
sumSquares([4,3,2,1]); // => 18, broken!

Limitations

The last reason applies to some specific langauges, for example JavaScript - reduce was added to JS as a half-baked thing, working only on arrays. The same function in other languages can be used on other types of collections. In Ruby as long as a class includes the Enumerable module, it gets reduce function. In Python, where reduce is used very rarely, you still can use it with dictionaries. I believe reduce would be way more useful in JavaScript if only it was possible to call it on other types of collections.

Write everything in reduce!

While I agree with the arguments I presented above, I still believe that understanding reduce can be very helpful, especially if you ever consider learning functional languages. It's really a powerful function. Actually, reduce is so flexible, that a lot of collection functions can be rewritten using reduce. Let's try it out!

Warning: don't try to do it in your apps. The original implementations of the functions below are certainly better (and probably much, much faster).

forEach

First, something easy: forEach is a reduce that calls a passed callback and does not return any value.

function foreach(array, cb) {
    array.reduce((_acc, el) => cb(el));
}

map

map is reduce where we start with empty array and in every iteration we add result of the callback function to the accumulator.

function map(array, cb) {
    return array.reduce((acc, el) => [...acc, cb(el)], []);
}

A slightly more readable (and faster, I guess) version, with 2 statements, would look like this:

function map(array, cb) {
    return array.reduce((acc, el) => {
        acc.push(cb(el));
        return acc;
    }
}

flatMap

This one's quite complicated! flatMap behaves similarly to map except that it always returns a flat (1-dimensional) array. If the provided callback returns an array, map returns an array of arrays, while flatMap, as the name suggests, flattens the output. It could be implemented this way:

function flatMap(array, cb) {
    return array.reduce((acc, el) => [...acc, ...cb(el)], []);
}

However, if the cb does not return an array (we can't guarantee it does), we need to add something more. There are a few different ways to deal with it, the most trivial is to just flatten the outer array. It's not a pretty solution (and oh it is SO slow), but it will do.

function flatMap(array, cb) {
    return array.reduce((acc, el) => [...acc, ...cb(el)].flatten(), []);
}

filter

Next, filter returns elemets of orignal array, but only those that meet the provided expectation (read: where cb(el) returns truthy value). First, let me implement it using 2 statements to make it easier to read.

function filter(array, cb) {
    return array.reduce((acc, el) => {
        if (cb(el)) acc.push(el);
        return acc;
    }, []);
 }

Now the same can be rewritten with a single statement, though it's less intuitive.

function filter(array, cb) {
    return array.reduce((acc, el) => {
        return cb(el) ? [...acc, el] : acc;
    }, []);
 }

some

some returns true if callback function returns true (or any truthy value) for any of the elements in the array. It can be written in pseudocode as cb(array[0]) || cb(array[1]) || ... || cb(array[n-1]). In order to implement it with reduce I'll be carrying on the boolean value over each iteration.

function some(array, cb) {
    return array.reduce((acc, el) => acc || Boolean(cb(el)), false);
}

every

every is a sibling function to some and returns true if the callback function returns true for every element of the array. It can be written as fun(array[0]) && fun(array[1]) && ... && fun(array[n-1]). Similarly I'll carry a boolean value as acc.

function every(array, cb) {
    return array.reduce((acc, el) => acc && Boolean(cb(el)), true);
}

includes

includes could actually be implemented using some. For the sake of consistency I'll just keep using the reduce directly though. In this case we don't have a callback to use, instead we need to check if any element is equal to provided value.

function includes(array, value) {
    return array.reduce((acc, el) => acc && (el === value), false);
}

As a side note, the 3 functions above are examples where using reduce introduces a performance penalty (they'll iterate over the whole array even if they could stop earlier). One more reason not to use this code in any serious application.

find

find returns the first element that meets a criteria specified by the callback function. In terms of implementation, it's similar to some with a twist. Just like with some we're going to pass a certain falsy value and as soon as it becomes truthy, we're going to pass it till the end of the iteration process. The twist is that the value we need to pass is not the output of the callback function, but the element on which the function is called.

function find(array, cb) {
    return array.reduce((acc, el) => {
        if (acc) return acc;
        if (cb(el)) return el;
    }, null);
}

Earlier in this post I said I'd try to write the reduce with only a single expression. It's possible in this case as well, though just as before it's harder to understand:

function find(array, cb) {
    return array.reduce((acc, el) => acc || (cb(el) && el)), null);
}

The cb(el) && el part will return false if the element does not meet provided requirement, or it will return the value of el if it does. Then the first part, acc || ...will either return acc (output of previous iteration), unless it's a falsy value, in which case it'll return the 2nd part explained above.

findIndex

findIndex initially seemed more challenging to implement, because somehow I need to keep track of the index together with the element. Then I remembered that the reducer function takes 4 arguments, and not only 2! The 3rd argument is the current index, and 4th one is the array on which the reduce is called (I'm still thinking how to use it in practice). So findIndex will be almost identical to find.

function findIndex(array, cb) {
    array.reduce((acc, el, i) => {
        if (acc) return acc;
        if (cb(el)) return i;
    }, null);
}

lastIndexOf

lastIndexOf is almost the same, except that first we check whether the current element meets the expectation, and only if it doesn't, then we return the last on that did. In short: we swap the order.

function lastIndexOf(array, cb) {
    array.reduce((acc, el, i) => {
        if (cb(el)) return i;
        if (acc) return acc;
    }, null);
}

Similarly to find, the findIndex and lastIndexOf functions (why isn't it called findLastIndex by the way? and why there's no findLast function?) could be rewritten using a single expression, the only difference is the order and the logical operators used.

Can reduce do everything?

Looking at the list of array functions in JS and I was wondering if there's anything that can't be implemented with reduce. Initially I had 3 ideas:

Functions that modify the original array - reduce comes from languages with immutable data structures, so modifying original array (with functions like copyWithin) was a long shot, but because the reducer accepts original array as a parameter, it is possible (I am 99.99% sure it's always bad idea, though - don't do it at home!)
Sorting - ok, when that idea came to my mind I thought it was really stupid, but maybe it's possible to implement some kind of bubble sort with reduce? Well, it seems I was not the only person who wondered about it!
Finally, I found something - Array class has methods like keys and entries, and those functions return iterators. I tried to implement them with reduce, but I failed miserably, so I assume it can't be done (correct me if I'm wrong!).

What's the point?

This was a fun exercise, but my point here is that each function has its place. reduce gets a lot of bad rep in JS and for good reasons. It's limiting yet overcomplicated and I still don't remember the order of parameters in reducer, although I used it a number of times. Still, it's good to understand it, so that you can use it from time to time.

Oh, and of course - check out other languages where reduce work also for dictionaries, sets, or other collection types. Languages like Elixir, Haskell or Ruby make reduce more powerful and intuitive at the same time!

Become a Productive Programmer

Gregory Witek — Sat, 24 Jul 2021 13:47:59 +0000

In this video I'm talking about how to become a more productive programmer. Productivity is always a hot topic and it's something that a lot of developers struggle with. In order to become a productive developer you'll need to put in a lot of effort, but there are some ways to improve the way you work even in environments full of distractions!

🎥 Timeline
0:00 intro
0:30 deep work, shallow work
1:58 tip #1 - good preparation
3:57 tip #2 - own your calendar
8:27 tip #3 - split your tasks
9:56 why pomodoro technique doesn't work
10:47 working in a team
11:47 magic productivity techniques
12:44 Outro

Engineering manager interview - questions and preparation

Gregory Witek — Tue, 29 Jun 2021 15:00:00 +0000

Engineering manager role comes in a lot of flavours and the interview processes for this role at various companies reflect that differences. In this video I'm talking about what kind of interviews and questions you can expect, and below the video you can find a list of questions that you might hear during different interview rounds.

Video

🎥 timeline:

0:00 developer interview vs manager interview

0:59 programming interview

02:20 system design interview

03:36 system design - how to prepare

05:30 team management interview

07:25 stakeholder management interview

08:20 management interview - how to prepare

11:05 general interview tips

Questions

what is your leadership style?
how do you define a successful team?
have you ever had a very high performing team? what made the team work so well together?
how do you define an individual success?
what does it mean to be a successful engineering manager?
how do you onboard a new team member?
how do you measure individual performance in your team?
have you ever taken a struggling project and turned it around? how did you it?
have you ever had a very urgent situation when you had to make a quick decision? what was that and what did you do?
have you ever had an underperforming team member? what did you do about it?
have you ever had to put someone on PIP?
have you ever had a person that was difficult to work with? what did you do about it?
have you ever had to let go a member of your team?
have you ever had a conflict between your team members? how did you deal with it?
have you ever had a conflict between you and some stakeholder? how did you solve it?
how do you keep track of ongoing work in your team?
are you familiar with agile methodologies?
have you ever led a project that failed? what made it fail? what did you learn from it?
have you ever made a decision that your team didn't like?
have you ever managed people who are way more experienced than you? how did you help them succeed in their roles?
do you do 1-1 meetings with your team members? how do you do it?
have you ever managed a team budget? how did you keep track of it?
have you ever promoted a team member? how did you help them progress?
have you ever denied someone a promotion? how did you explain it to them?
have you ever had to manage multiple urgent tasks? how did you do that?
have you ever had to manage unclear product requirements? how did you do it?
have you ever worked with UX designers/Technical Writers/testers/product managers? How did you ensure that you worked well together?
have you ever built a team from scratch? how did you do it?
have you ever managed a fully distributed team? how did you ensure the team was successful?
have you ever had a toxic team member? how did you handle it?
have you ever dealt with legacy software? how did you balance between technical debt and feature work?
have you ever dealt with suddenly changing requirements? what did you do about it?
have you ever worked with Scrum/Kanban/SAFe etc? How do you understand your role in that methodology?
have you ever dealt with project that missed its deadline? what did you do about it?
have you ever made a bad decision that affected your team? how did you resolve the situation?

I'll keep updating this post with more questions in the future, and if you have some suggestions, leave them in the comments!

Python gotchas for JavaScript developers

Gregory Witek — Mon, 11 Jan 2021 18:53:12 +0000

If you're a JavaScript developer who's interested in topics like machine learning, data science, or even if you want to learn some new tool to broaden your experience, there's a high chance that you are trying out (or going to try out) Python. While both languages are quite similar, there are a bunch of surprising differences that can confuse you. In this article I list a couple of such gotchas together with examples and explanations which will help you understand why both languages behave differently.

And if you are looking for a new language to learn as a JavaScript developer, check out my video where I talk about how to choose your next language.

Anonymous functions are very limited

First on the list: anonymous functions aka closures aka lambdas. They're a very common tool in JavaScript. To be fair they'r nothing special, just ad-hoc created functions that do not have any specific name. Any time you write array.map((el) => doSomething(el)) you write an anonymous function. Heck, to be fair probably 99% of JS functions you write these days are technically anonymous. Look at this:

const myFun = () => alert("I have no name!");
const otherFun = function() { alert("Me neither!"); }

These 2 functions are anonymous. You can refer to them via variable to which they're assigned, but if that variable ever changes the value, you can't find the function again, it's lost. In order to have a "real" named function, you need to do this:

function myFun() { alert("I have a name"); }

class MyClass {
    otherFun() { alert("Me too!"); }
}

There are certain other differences between named and anonymous functions in JS, but in general they're very similar and you can easily use either of them most of the time. However, in Python the situation is different. While the language supports both named and anonymous functions, the latter are very limited: they can consist of only one expression (essentially they can do one operation). To show you an example:

fun1 = lambda : print("works!")
fun2 = lambda a, b : a + b

wrongFun = lambda: # this will throw invalid syntax error!
    a = 1
    b = 2
    return a + b

This means that the following piece of code is impossible to write using lambdas in Python:

makeRequest().then((result) => {
    logOutput(result.data);
    saveContent(result.data["content"]);
    return result;
});

Why is there such limitation? As Python's creator himself explains:

I find any solution unacceptable that embeds an indentation-based block in the middle of an expression. Since I find alternative syntax for statement grouping (e.g. braces or begin/end keywords) equally unacceptable, this pretty much makes a multi-line lambda an unsolvable puzzle.

Basically in order to allow multi-line anonymous functions, a single expression would need to respect the tab-based indendation rules (currently it doesn't) or use another block separators (like {} in JS). Guido van Rossum, creator of the language, rejected both these ideas.

What's the solution then? Well, simply give the function a name! To be fair it's not that much of a deal, rather an inconvenience, but also a gotcha, something that I didn't expect when I first learned Python.

Expressions vs statements

Related to the previous point are differences between statements and expressions in both languages. If you're not sure what are these two, a brief explanation is that expression is something that produces a value, while statement is just a piece of code that performs something, but it does not return any value. In other words, you can ask yourself: can I assign it to a variable? If yes, it's an expression, otherwise it's a statement. For example:

const a = 3; // 3 is an expression
const b = a + 12; // arithmetic operations are expressions
const c = (z = 10); // (z = 10) is also an expression
const d = (if (a > 2) { 7 } else { 2 }); // this won't work! if is a statement

function myFun() { alert("alert"); }
const e = myFun(); // calling a function is an expression

Ok, so what's the issue? Well, the issue is that an expression in JavaScript might not be an expression in Python! For example, creating a function:

const something = () => 8;
const sthElse = function namedFun() { return 7; }

This code is perfectly valid in JavaScript (even if it's not common to assign named functions to variables). What about Python?

something = lambda : 8; # this code is valid
sthElse = def namedFun(): return 7; # this code will crash!

In this case the 2nd example does not work, because defining a named function in Python is a statement, not an expression. Similarly with assignments let a = 10 in JS returns 10, while in Python a = 10 returns nothing, it does not produce any value.

I am not sure why Python function definition is a statement. A possible explanation is that on one hand indented lines inside an expression do not create a new scope (which is logical, why would they) and on the other hand function definition must create a new scope, therefore a function definition can't be an expression. That's just my theory though, maybe it was decided a priori that definition is a statement and that's it.

I can't think of any more diffecentec between expressions and statements in Python vs JavaScript, but if you're interested in how it looks in other languages you can check Ruby, where essentially everything is an expression (including if, for etc).

Tricky default parameters

Default values for function arguments are a feature so obvious that it is rarely ever mentioned besides basic tutorials. It's easy, if a value is not passed to your function explicitly, instead of throwing an error, you just give it a certain, hardcoded value.

const processJob = (name, args, delay = 0) {
    Job.fetchByName(name).startIn(delay).execute(args)
}

processJob("createUser", {name: "Ian"}, 60) // run in 60sec
processJob("createUses", {name: "Ion"}) // run now

In Python, default values have a catch though - instead of being evaluated every time a function is called, default values are evaluated only once. Why does it matter? Because if you decide to modify the argument inside your function, it will not be brought back to its previous state! Let me show it using an example. First, JavaScript:

const addOne = (ary = []) => {
    ary.append(1);
    return ary;
}

addOne([3,2]); // returns [3,2,1]
addOne([3,2]); // returns [3,2,1] again

addOne(); // returns [1]
addOne(); // returns [1] again, this is crucial here

Now lets compare it with Python:

def addOne(ary=[]):
    ary.append(1)
    return ary

addOne([3,2]) # returns [3,2,1]
addOne([3,2]) # returns [3,2,1]

again addOne() # returns [1]
addOne() # BOOM! returns [1,1]
addOne() # and now returns [1,1,1]

See the difference? The default argument is always the same array. Unlike most of the languages I know, Python does not recreate this object every time. The common solution to this problem is unfortunately a rather ugly idiom:

 def addOne(ary=None):
     if ary is None:
         ary = []

     ary.append(1)
     return ary

Note that this difference applies only to complex data types like arrays, dictionaries etc. If your argument is a string or a number, the default value will not change from one call to another, so you can safely use it. However if you want to have an array or dictionary by default, you need to pass None as a default value.

Nothing is private!

Alright, there are way more examples, but let's not turn this article into a compedium. Let me just mention one last gotcha in this post - privacy... or rather lack of it. As you probably know, JavaScript does not have an explicit concept of private methods or variables. I mean whatever you put in a class can technically be accessed outside of it. There is a proposal to turn add private methods and fields with kind of an unusual syntax, but for now it's not there yet.

Still, there are ways to make some stuff kind of private in JS. For example you can write a set of functions and variables and export only a few of them:

const x = 12;
const y = 10;

const pubFun = () => console.log('public');
const priFun = () => console.log('private');

export { x, pubFun };

And of course you can use Typescript, which has a full Java-ish (C++-ish?) set of function/field access control.

On the other hand, in Python essentially everything is accessible - there is no built-in protection mechanism. There is no export keyword - everything can be imported from any module, everything can be accessed in any class. Python promotes an "unwritten agreement" approach, where underscores used as prefixes indicate that the function or variable should not be used outside of its original class or module:

var1 = 0; # go ahead, use it whenever you need
_var2 = 0; # should not be used outside of its class/module
__var3 = 0; # DEFINITELY should not be touched

To be precise, Python does a little bit to discourage use of functions with double underscore (read more about it here), but you still can use "private" functions whenever you want, wherever you want.

More gotchas?

Programming languages are very complex tools and therefore have a lot of surprises. Sometimes they're obvious and we learn them very early and sometimes it takes months or even years to notice a behavior that surprises us. I'm sure Python has more getchas for JS developers. If you have some other examples, tell me!

And if you're curious about why Python became such a popular language, check out my other post where I compare it to other dynamic, scripting languages.

What human language do you write your code in?

Gregory Witek — Wed, 30 Dec 2020 21:52:26 +0000

Hi folks, a question just popped to my mind and I wanted to ask a broader audience: when writing code, do you name your variables/functions/classes etc using English or your native (or yet some other) language and why?

I'm asking cause I have seen at a couple examples in my career where people used language other than English and I'm curious how common it is.

The most obvious argument for using native language is that it's all easier to understand and especially for people who are not very fluent in English, coming up with proper names for functions in English might be challenging.

On the other side using another language causes a linguistic mix - we all probably use languages that have English keyword, so that means that all built-in functions and 3rd party functions are in English, while our own ones are not, which might make it more challenging to read.

What does an Engineering Manager do?

Gregory Witek — Tue, 29 Dec 2020 23:45:21 +0000

In this video I'm talking abouet engineering management - who is an engineering manager? What does an engineering manager do? Do engineering managers write code? After a short walk around Amsterdam I'm going to tell you about different hats that engineering managers need to wear depending on kind of a company they work for.

In the video I mention article by Pat Kua that I highly recommend: 📝 https://www.patkua.com/blog/5-engineering-manager-archetypes/

If one day you want to become an engineering mananger you might be interested in following books:

📚 Leading Snowflakes by Oren Ellenbogen - https://leadingsnowflakes.com/

📚 The Manager's Path by Camille Fournier - https://www.goodreads.com/book/show/3...

📚Management 3.0 bu Jurgen Appelo - https://www.goodreads.com/book/show/1...

🎥 Video timeline 🎥

0:00 Intro and walk around Amsterdam

2:00 4 hats engineering managers wear

5:09 What does it mean to manage people

9:25 Where is the engineering in engineering manager?

12:04 Outro

How I got my first jobs as a sofware developer

Gregory Witek — Tue, 22 Dec 2020 16:25:26 +0000

In this video I'm talking about how I got my first few programming jobs. Early in my career I switched jobs a couple of times and I landed all the jobs in a different way, usually by some kind of a reference or cold mail, never by direct application (though I did it later in my career).

🎥 Video timeline: 🎥

0:00 Intro

0:52 First job (Netguru, Poland)

3:30 Second job (Flywire, Spain)

6:16 Third job (Fyber, Germany)

7:16 Fourth job (freelancing)

8:05 Fifth job (Ascenda, Singapore)

If you enjoy this video, don't forget to subscribe to my Youtube channel and make sure to follow me on Twitter. Cheers!

Finding job as a junior developer - tips from tech recruiters

Gregory Witek — Tue, 15 Dec 2020 17:18:37 +0000

Alright junior devs, here's one especially for you! This is the last, bonus episode of the job hunting series and it's dedicated towards junior developers.

We know that right now finding job as a junior developer is tough - there are fewer opportunities and more candidates. So during the 4 interviews I did for this series I asked one more question: what advice do you have specifically for junior devlopers? This video is a compilation of the answers I got, you'll find here tips from tech recruiters and hiring managers specifically for junior devs.

Let me know what you think if you have any questions about getting job as a junior dev, reach out to me or drop a comment. Take care!

🎥 Video timeline:

0:00 Intro

0:57 Job application (Angus Mackintosh)

2:38 Tech interview (Bart van de Garde)

4:34 HR interview (Ross Inman)

6:18 Offer negotiation (Matthew Barr)

8:02 Outro