| Talent at any company can be divided in to following categories:
a. People who make code* frameworks
b. People who extend code frameworks
c. People who maintain code frameworks * you can replace code with almost any other employable skill "Talent shortage" usually refers to people who fall in a). Every company claims to want to hire only a) but most companies need b) or c). Very early stage startups ideally need a), but they don't always manage to hire people in that category. They can temporarily bypass this requirement by hiring people in b) and using frameworks like (Rails, Django, etc) built by other people who fall in a) until they get to a point where a) types will be willing to join. When people talk about shortage of talent, they usually mean shortage of a) people. This is mostly because two of the three things that people in b) and c) need to become a) are hard to acquire and come with 'experience'(for those who try). 3 things you need to become a): 1. Acquiring a good base
- data structures, algorithms, design patterns etc
- learning languages/specific skills
- interview skills 2. Acquiring good mental models
- working with smart programmers
- reading code by smart programmers
- learning to make tradeoffs
- actually building stuff 3. Acquiring reputation
- Building stuff
- Talking about stuff you build
- Having other people talk about you
- Collecting badges that other people recognize i.e. working at well known startups/companies, winning programming competitions, going to Berkeley, etc. Most people manage to succeed in 1) eventually. 1) is also where most college/other training programs focus. But, 2) and 3) are much harder to acquire. If a company is big enough they will assign an a) to mentor someone who is a b) or c), but this is often not viable for startups (and, imho, slightly unreasonable to expect from a lot of startups). If we figure out a way for b) and c) people to learn 2), we can solve a lot of the talent shortage. But, this requires either a b) or c) person to spend time on their own looking at work by a) people (not always possible and extremely time consuming), or an a) person mentoring the b)/c) person outside companies (100x faster, imho). Until we build social systems that enable b) and c) to transition to a) easily, the alarms for 'talent shortage' will continue to ring. Caveats:
1. A lot of jobs only need b) or c). Employers could adjust expectations.
2. Luck is a huge factor. You don't actually have to be a) to be hired or considered a) because perception(3) plays a big role. |
What you need is someone for a) is someone who is both a software engineer (i.e. thinks hard about design) and is a coder/developer. The amount of experience doesn't really matter though experience is an important guide. What really matters is attitude. How does the programmer approach design questions? Is the individual someone who just wants to code? Or is the individual one who is always addressing his or her code for maintainability and pursuing perfect in that regard?
I have seen projects built by people who coded for a dozen years and never got to the point of actually thinking hard about design and maintainability. I have even been stuck in the nightmarish position of maintaining such code (and of course deciding to refactor with a chain saw!).
Again a lot of it is a question of priorities and, I hate to say it, ego. One has to both have an ego enough to question prevailing wisdom but have a small enough one to understand that one's coding style is never perfect. Such individuals are rare, in my experience.