I almost responded without reading the article, assuming he was talking about moonlighters. Meaning hiring developers who have already put in 40 hours somewhere else. Many responding here seem to be making the same assumption. That's always been a disaster (as the employer).
But he is actually talking about offering his first 20 hours to a client, which is what I do as a consulting CTO. It works out exceptionally well for my clients. And I have had few issues when I hire contractors who juggle a couple part time clients. If you do that full time, you quickly learn time management.
He's also right there is no market for this for programmers beyond Upwork or Toptal. Companies rather pay a premium to get 4 productive hours, 2 hours of email and meetings, and 2 hours of coffee and socializing.
One exception might be DevOps, which is more project based.
The Amplify team seems to be allergic to docs. They should double the size of their evangelist/tech writing team.
I don't know when this was, but I'm just starting learning it now and the "Getting Started" tutorial seems to be 2+ revisions behind the current CLI, which is their main product.
And UI components moved to v2 with a new doc site, but all the main docs/tutorials still refer to v1. There are breaking changes.
I'd also expect to pull up docs on any class or function in my IDE (IntelliJ), but there is nothing for Amplify. Just type definitions, no explanations.
"Influence: The Psychology of Persuasion" by Robert Cialdini
This explains so much of human behavior, but I hesitate to recommend it to people because it is so easily weaponized. To borrow from Harry Potter, it's the closest thing I've seen to a book of charm spells, but was written as a defense against the dark arts. Better everyone read it rather than just the marketers.
What I really love about this book is how much of politics it has explained for me, including the downfall of the USSR and the American civil rights movements, but also newer events like Schwarzenegger's poltiical career.
If you like this, I'd also recommend:
"Thinking, Fast and Slow" by Daniel Kahneman
"Predictably Irrational" by Dan Ariely
"The Power of Habit" by Charles Duhigg
All are in a similar vein. For more focused book on human behavior, I recommend first time team leads/managers read:
"Switch" by Dan and Chip Heath
A solid guide to changing organizational behavior.
It seems to me that like last year, several countries with very large developer bases are underrepresented. I'm thinking of India and the Philippines in particular, where English is not an issue. I'm an American, but I'd like to get a good global picture.
In addition, it would be good to see other indicators such as downloads, jobs (admittedly hard to measure accurately), BuiltWith trends, etc. Considering the millions of front end developers, this seems a very small sample size.
I thought this was already posted, but I had read this longer article with more context, including the original text from the book that is short and written in a fun, old-timey style:
Hi Charles, what you are describing is what I specialize in (outsourced/offshore software project rescue). I run a 4-part audit/assessment:
1. Client education, AKA managing expectations. Educating the client on the principles and challenges of software development. Most know very little about this and it makes their job very frustrating. Every failure of consulting is really a failure to manage expectations.
2. Communication. How are they communicating, what are the problems? This is the most important thing in software development (and business in general).
3. Methodology review. How are they managing the project? What methods and tools are they using? Are the tools configured, integrated, and automated correctly?
4. Developer practices. Mostly based on my programmer productivity talk.
You are focused on #4 (and some of #3), which is important, but I find the first 3 way more important for "success." #2 sounds like your biggest problem. When I hire developers (always 100% remote) I prioritize two things: communication skills and discipline.
I'll give you one tip: static code analysis tools. This way the tool is criticizing the code instead of you (of course, I agree with code reviews). When I realized how useful this is I started giving talks on it.
I would love public transportation like I've experienced it in Europe, but train tracks have exceptionally tight tolerances and high costs to build/maintain vs. roads. I hope Musk will fix this, but probably not before "good enough" self-driving cars arrive. Also, trains get into accidents pretty regularly. First Google hit:
According to the US Department of Transportation, there are about 5,800 train-car crashes each year in the United States, most of which occur at railroad crossings. These accidents cause 600 deaths and injure about 2,300.
I think it's good to remove "friend potential" from the hiring process. Most people are not jerks, and that's really all you need. I find I'll become friends with anyone reasonably pleasant to be around.
But listing criteria without saying anything about how you test for it - like empathy - is a pretty big gap. Hopefully you have a talented HR member with a psych background who can guide you through behavioral questioning.
I hire 100% remote developers, so my #1 soft criteria is discipline. And I find I can test for that, along with communication skills (#2) by asking them to write about best practices. Disciplined developers love to talk about best practices.
It's hard to say what to improve without more details, but contract work should be high paying because of the uncertainty. Could be issues with your resume and/or interviewing skills. For the latter, you could try interviewing.io. Almost everyone underestimates the amount of practice required to get good, and they procrastinate until it's too late (just like with networking). Also sounds like you're a generalist, which will work against you.
I have a career course that should give you a ton of ideas to help, see my profile for details. If it's taking you that long to find a job, there are some fundamental issues with your strategy and tactics.
But he is actually talking about offering his first 20 hours to a client, which is what I do as a consulting CTO. It works out exceptionally well for my clients. And I have had few issues when I hire contractors who juggle a couple part time clients. If you do that full time, you quickly learn time management.
He's also right there is no market for this for programmers beyond Upwork or Toptal. Companies rather pay a premium to get 4 productive hours, 2 hours of email and meetings, and 2 hours of coffee and socializing.
One exception might be DevOps, which is more project based.