High level summary
Last month, I setup a brief survey on Typeform and submitted it to ProductHunt as a project called “Senior meets junior”. Senior meets junior was described as a project that would allow engineers to collaborate together over side projects. Junior engineers could collaborate on real projects to upskill, while senior engineers can improve their mentorship abilities and receive more help on their projects. I’d like to formally share the stats around the response and a few surprising results that I will be considering for the next steps.
Breakdown around statistics
After submitting the Senior meets Junior survey on ProductHunt, I received a 186 submissions from both senior and junior developers looking to collaborate on side projects. Of this group, approximately 75% were self-identified as junior developers, and 25% were self-identified as senior. I was able to meet with 19 individuals out of the hundred in 97 people who signed up. All of the 19 individuals only two people were actually from developed countries (US and France), but even one of them were actually traveling abroad, so I actually spoke to 18 people from emerging markets around the world. I’m not sure if the name ”Senior meets junior” is a term that is not appealing to Americans or if the idea of mentorship is more appealing to people of foreign backgrounds, but I was genuinely surprised by how many more people from developing countries signed up to the service. I definitely expected more junior engineers from developed markets, who were interested in upskilling.
One more note along the ratio of senior and junior engineers. When reviewing the applications, I searched the background of each user and noticed that many of the individuals who said they were junior developers were working as seasoned engineers. I couldn’t figure out if people were misidentifying as Junior developers because they wanted to work on other people’s side projects, or if they truly believed that their abilities were not at a senior level.
From a statistics perspective, the most languages people wanted to work on was JavaScript. I asked the question “What technologies is your project based on, or if you are junior, what technologies are you comfortable working with?”. Following that was Python, and then Java. As you will see in the chart, 58.6% people said JavaScript, followed by 50% in Python, and 21% in Java. Ruby, Rust, Scala, and a number of other languages all scored less than 10%.
Interestingly, when asking people where they needed the most help, most people said Backend development. The question was “What areas do you expect to need the most help or if you are junior, what would you feel comfortable contributing to”. Considering so many people wanted to learn or contribute JavaScript, the sheer amount of Backend development help needed was predictable. About half (57%) of the people who wanted help in a certain area also shared they wanted to improve their Frontend application development. This is consistent with the Javascript interest.
One of the questions I found most interesting was around how much time someone felt they needed to be productive. Similarly to the time is takes for a hired engineer to start contributing code on a new code base, I wondered how much mentorship a junior engineer would need to start working on a foreign project. The question I asked was: “How much mentorship and direction can you provide someone who works with you? If you are junior, how (much) mentorship and direction do you think you need to be productive?”. In response to the question, and surprising majority said they only need 1 to 2 hours a week of mentorship to start contributing to a codebase. This is a pretty small amount of time, relative to how much one person can do to contribute.
Areas that I was surprised about
The first area that I was surprised to learn with how dramatic the different the engineer pay rate is outside of the US, and how similar it is in across many developing countries. I learned that in Ukraine, India, Georgia, Spain, Russia, Turkey and Nigeria, the average pay for a Year’s engineering salary is between $30,000 to $15,000 US dollars a year. This means that in one month many Engineers are making less than $2,000, and many are making less than $1,000. This is compared to the regular salary of a US engineer who makes up words 300 or $400,000, or a recent college graduate who can very quickly, man north of $100,000 USD.
To imagine that there are so many more engineers across the world than there are in the US, and that many of these are English-speaking, and that many more are receiving the same educational resources as those engineers in the US, I cannot help but imagine that these foreign workers will soon be replacing domestic engineers in the US. When I think about how much remote work has been discussed in the last few months, I can also see that the infrastructure for hiring remote workers is maturing and will soon allow for more and more remote workers from developing countries to contribute to domestic projects in the US. I also recognize that many foreign workers may not need anywhere near a US engineer salary, and would potentially be very satisfied to work at the higher-end of their local salary range. When comparing this to an engineer in the US who works at the lower-bound of the salary range for their domestic peers, I imagine the foreign worker to be significantly happier and willing to contribute more.
The second area that was quite surprising was around the U.S. engineers that I spoke to who were unhappy about their work and didn’t like work that was primarily based on taking a design to translating it to code, or processing bugs in a bug tracker system that did not require any critical thinking. I imagine that this kind of work which is not desired by skilled laborers in a domestic Workforce, would be very easily translated into Outsource or remote work. I believe that the growing need for constant maintenance and simple types of engineering tasks will reveal the value of having an accessible remote Workforce that does not need to be highly engaged with decision making.
Third, there is a large number of people who are quite adept at the current Frameworks (read: React) and programming languages (JavaScript, Python, Java). These people would like to grow in our less around programming skills or computer science foundation’s, and their interest is more around establishing best practices and means of collaborate. These remote Engineers are people who know how to write code and solve problems for clients, but still need to learn how to deploy production applications or optimized server configurations for scale. These kinds of engineers are ideal for collaborating with other developers, because they are interested in learning things that are not explicitly taught will online but would be able to contribute to a code base if given explicit instructions.
Lastly, I was surprised that there are a large number of Junior developers were able to learn quickly and could become employed across the world. In many cases around the U.S., coding bootcamps can take someone who has no experience, and help get them to a point where they are able to get a job at a tech company within three to four months of accelerated learning. I noticed many junior engineers across the cohort of users who also could become employable with self-study within a six-month period. I was very naive to think about how on technical I imagined some of the participants who signed up would be from developing countries. I was surprised around the fact that most college graduates are all learning the same things that the US level college graduate would be learning. This means that a computer science student will be focused on machine learning, or an electrical engineering student will be working with Arduino and raspberry pies. Given that this is the same technology that a domestic student would learn from and that the skills are identical, there is no reason why these individuals could not come highly employable in a short period of time as well.
Conclusion
Overall, I strongly believe that remote work and contributors from around the world will meet a crossroads soon. While remote work in the US is becoming more common, I foresee many more engineers from countries around the world contributing to code bases in the US. This would mean that the tooling that helps coordination will likely become more important, and the areas of work that are centered on decision making and executing will likely be separated or clearly organized.
I also believe that the sheer amount of income that current software engineers command is disproportionately high when compared to the education or skills needed to complete certain roles. While I am not sure if the high-salary is necessarily justified, I do think a number of market forces (VC investment, high return of certain software businesses, demand for engineers who are skilled at new technologies that haven’t existed long enough) are likely the reason for driving up engineering value. Not all engineers are necessarily returning the value on their investment, so I could imagine different tiers of engineering work to be more explicitly defined outside of the terminology of senior or junior. The larger tech companies near are already different tiers of engineers from being a principal engineer, a lead engineer, or different tiers of software engineer.
I’ll be moving forward with trying to interview more of the Senior meets junior sign ups, and expect to continue expanding the cohort from engineers to other fields such as design or product management. If you or someone you know may be interested in this project, please sign up at www.smj.dev, or contact me directly at [email protected]
Please excuse the grammatical errors. This was written using dictation, and followed with slight edits.