On January 22, 2020, I participated in a panel discussion at the launch of the Angat.io mentorship community in Manila, with Francis Plaza and Luis Sia of PayMongo and Daniel Georges of Angat.io.

Angat.io launched a web application that supports a community of developers and mentors with the goal of building the talent pool in the Philippines.

Here are excerpts from my remarks. The moderator asked:

What challenges do tech companies face in hiring talent?

A big challenge is the level of experience of the developers. In the US, boot camps intend to turn out developers who will be productive as soon as they start a new job. But there’s a problem, referred to as the “junior gap.” How do you take a bright, curious person and get them productive as soon as they join your team? How does the organization begin to develop raw talent to the point where they are productive developers? That depends a lot on aspects like mentorship, pair programming, building a learning culture, having a format where developers have time to explore new technologies and present what they’ve learned to other developers. All those factors make the difference between a company that not just hires but retains engineers and makes sure they are productive.

How do Filipino developers rank versus the rest of the world?

The question is not fair, in a way. I’m reluctant to make generalizations. But I can speak from my personal experience. There are bright, hardworking, smart, curious people everywhere around the world, whether it’s Ukraine, Poland, California, Philippines, or Indonesia. There’s always people who want to take on tech challenges and are curious and interested and motivated and want to build stuff. There’s no comparison that can be made on that basis. But there’s a few observations that I can make, after being here in Manila for four years, for the last six months at a company with a very strong team, some of the smartest developers I’ve met, with years of experience. One thing I’ve noticed, is that the problems that are faced by companies in Manila are not as challenging as Silicon Valley or some other major markets around the world. People are building a lot of CRUD apps, simple interfaces to a database, but when it comes to things that are more complex, that have to scale with millions of users, or are built across a distributed architecture, developers may not have experience. I’ve noticed that here in Manila a developer is likely to work at one company for two or three years. Here in the Philippines people tend to find a good job and stay with it, where their friends are, where there are people they enjoy working with. People here can put up with a lot of challenges, tolerate a lot of bullshit, and stay with a job. In the U.S. it can be very different because of the tremendous demand for tech talent. In Silicon Valley or San Francisco, if you meet someone who has been on the job for nine months, he’s already getting calls from recruiters asking, “Are you ready to move on to your next challenge?” It’s a difficult problem for management because it’s really hard to retain people. But there’s a silver lining because when you hire someone, even if they are only 30 years old, they may have worked for five companies over an eight year career. That’s a contrast I’d make between the developers I’ve encountered in Manila and in San Francisco. The opportunity here, with a mentorship community like Angat.io, the community can begin leveling itself up, the people with experience can be mentors. Within the span of a few years, the Philippines will have the talent pool that you find in all the major markets. At that point, the startup community will be booming, with more companies started, and more money coming in for developers.

What are the best skills for a developer to learn for the next five years?

Technologies change all the time and they change fast. It’s hard to anticipate what will be the hot technology you’ll need to know two years from now. People say, when you have a technology career, over the course of 21 years you may actually have three different careers because at least every seven years you have to relearn everything. Rather than guessing at what technologies you should learn now, let’s ask how do you distinguish yourself, how do you become visible, how do you differentiate yourself from other candidates vying for the same job? And that’s by having a broad range of skills, exposure to a lot of different technologies. I advise people looking for a first job to join a consulting company. You will be exposed to not just a lot of different technologies but a lot of different problems. Be the person who can solve different problems no matter what the technology. Come to a job and they say, we’re going to use Elixir, and you’ve only got experience with Rails, you should be able to say, no problem, give me a book, show me the codebase, I’ll pick it up in a few weeks. My colleague Michael Hartl refers to it as “technical sophistication.” Don’t just learn technologies, develop your technical sophistication, develop your ability to solve problems, develop your ability to communicate with clients. That’s the advantage of consulting jobs. Develop your understanding of what your client needs, getting clarity on specifications and being able to handle rapid changes and you’ll be someone who is flexible enough that you can step into a variety of roles.

What are an employer’s biggest mistakes that result in high turnover?

When I step into a consulting situation with a CTO or CEO, the first question I ask is, “Do you know what makes a software engineer happy?” And it’s surprising how few CEOs – or even CTOs who are themselves engineers – can answer the question. What drives a software engineering team? What matters the most to software engineers? Some things are obvious. “I want to be paid well.” “I want to be recognized for the work I do.” “I want clear specifications from the product side so I know what I’m supposed to deliver.” “I want reasonable time frames and not a lot of changes in a healthy and productive Agile environment.” “I don’t want to distracted when I’m in the flow.” All those things contribute to a happy workplace. But recognize that one thing that motivates a software developer is curiosity and a desire to learn. I recently ran a facilitated workshop to answer the question. We spent a morning offsite and I asked every engineer to make a list. And we got all nerdy and complex and made some grids and rated what made the engineers happy. The one thing that came up was that people wanted a chance to be learning and to be sharing what they are learning. So we built a learning culture around that motivation. It’s of critical importance to recognize that developers are motivated by a desire to learn, to be stimulated, solving problems and improving themselves, taking on complex challenges and optimizing oneself. I think that’s unique to engineers. The industry would be wise to ask that question, run that workshop, and come out of it knowing what makes a software engineer happy.

How much experience do you need to call yourself a senior developer?

That depends a lot on the market you’re in. A senior developer in Manila could be mid-level in San Francisco. “Senior developer” in San Francisco means a wide range of experience. So it depends on the market relative to your peers. It’s just a label a recruiter or hiring manager will put on you. So I advise to gain experience, do side projects as much as possible, get stuff into your GitHub repo. Some companies may never look at a GitHub repo. The HR people may not even know what GitHub is. You probably don’t want to work there if you want to grow fast in your career as a software engineer. Try to work with companies that are full of experienced engineers. No matter how much experience you’ve got, it’s better to come in and feel you are junior or mid-level with seniors around you. Be the one who knows less than everyone else. Don’t be the smartest person in the room.

Should people be identifying themselves as fullstack developers? Or do you think specialization as a frontend or backend developer is better?

In 2020 you can’t be a good fullstack developer. There’s just too much in the stack. If you come to me and say you’re a fullstack developer, I’d say, great, you’re telling me you’re familiar with the entire request/response cycle of a web application. I want to know that anyone is not so specialized that they’ve only done frontend and they don’t know what happens on the backend. Come to me as a fullstack developer and I’ll ask you what do you prefer? What do you like a and what motivates you? Maybe you say, I like the design stuff and working on an interface. So then you’re comfortable diving into JavaScript or React, that’s where you should be working. Or come to me and say you’re not good with design and don’t want anything to do with UI because you want to concentrate on making things that scale and are reliable and robust, or maybe you’re interested in architecture and building the best way to solve a particular problem as it grows over time. Be enough of a fullstack developer to know what the stack is. But in 2020 we can’t expect to find someone who is good at everything in the stack.

What advice can you give a graphic designer who just knows Photoshop and Canva who wants to transition into coding?

I suggest to start playing around building web apps. There’s a good book called, Learn Ruby on Rails (laughter). Yes, I wrote that book. There’s two really good books for learning Ruby on Rails. One of them is far more popular than mine, by Michael Hartl, for people who already have experience programming. Some time ago I started volunteering to teach people who weren’t coders who wanted to get into coding to start careers as programmers or who wanted to launch a business and needed to code because they couldn’t find technical cofounders. Michael Hartl’s book for programmers was recommended to them and I got to the point where I had to say, don’t recommend that book for non-programmers. Yes, it’s a great book and every programmer who wants to learn Rails should use that book. But at that time I said there needs to be a book for anyone who has no experience coding. For example, a graphic designer working with Photoshop who wants to start building stuff that requires coding. That’s why I wrote the book, “Learn Ruby on Rails.” Right now Ruby on Rails might not be the best place to start. I’d start with JavaScript, especially on the frontend. But look for a book that gives you a sense of the culture of coding, the lore, the development process. If you just learn JavaScript, that’s not enough to go to work building JavaScript apps. You’ll need a sense of the history of JavaScript and how it has evolved over time, what is ES6 and why are promises significant now. You should carefully pick and choose what you use for learning otherwise you’ll be very frustrated and you’ll give up on what may be a really rewarding and satisfying or fulfilling career and passion as a programmer.

I've been part of building the web since its early days in 1991. Have something to say? Send email to daniel@danielkehoe.com. I'm currently working on the yax.com project for do-it-yourself websites.