Developers Who Can Build Things from Scratch
http://www.aaronstannard.com/engineers-from-scratch/
A developer who can take a blank sheet of paper and turn it into a functioning product, under their own direction, is a rare - # 将纸上的设计变为可用产品
- they are in possession of hard technical skills, # 技术能力
- excellent at explaining technical concepts to non-technical team members, # 和非技术成员合作能力
- can work with abstract requirements, # 理解抽象需求
- able to anticipate future changes and revisions on their own, # 清楚后续发展和改进
- and are able to adapt on-the-fly. # 快速学习
What follows is the advice I give to entrepreneurs with non-technical backgrounds on how to recognize these types of developers - I'm going to call them "from scratch" developers. # 如何识别这一类开发者. 这种可以"从无到有"的开发者.
Not attached to a particular way of doing things 不过分依赖某一种特定方法来解决问题
An engineer who can build products from scratch is one who's not attached to a specific set of technologies or a specific way of building things. They'll objectively choose the right tools for the job depending on what it is. # 总是选择合适的工具
In other words, you're not going to want any pet technologists or futurists from my "Taxonomy of Terrible Programmers."
Those are red flags right off of the bat - any engineer who's more focused to how they're building the product than what they're actually building lacks the maturity to do this job. They'd need to be managed by another engineer in order to provide the best ROI, so pass over these types for now.
Corollary: actively suggests using off-the-shelf software 总是使用现有可用的软件. 更加关注自己要做的是什么, 而不是自己来如何做.
A corollary to this property is if a developer actively suggests using pieces of off-the-shelf software, even if they have licensing costs associated with them, that's often a good indicator of actual go-to-market experience and being able to focus on what's important: delivering the product.
Not derailed by new requirements or new things to learn
Building something from scratch is always going to involve new ways of doing things, because every product is different at some level. It also inherently involves learning and changing things on the fly - because you will always discover new requirements after you actually start getting into the meat of trying to implement a product. Anyone who tells you otherwise should read up on the Nirvana fallacy. # 现实需求总是变化太快, 还有一些和原先设想不相同的地方.
So any developer who can do the job must be able to learn new things on the fly. For instance, if you're able to do some level of customer and product development in parallel (which you always should) and discover a new thing about your customers that needs to be factored into the product, what happens if your developer isn't willing to learn whatever they need to learn to fulfill that requirement? # 快速学习能力
Happens more often than you'd think! The first sign that you're dealing with a developer who's intellectually rigid like this is when they start telling you that things are "impossible." Nothing is ever really "impossible" - expensive, different, and challenging maybe. But rarely are things actually "impossible." # 一些事情看上去非常复杂难以实现, 但是实际情况是很少有东西是难以实现的
A developer who can build something for scratch will figure it out - they might need some help picking from a number of different possible options that they discover, but ultimately they're not going to get stopped by not knowing what to do initially.
Structured way of thinking, communicating, and asking # 结构化行为方式
The "from scratch" developer begins in an environment where they are the only engineer - the other stakeholders they're working with typically don't know what "technical debt" is; which technology stack is better for X; or even which parts of their software product are "expensive" to build. So it's the responsibility of the "from scratch" developer to be able to communicate these issues clearly and concisely to those team members.
Here's a list of things this developer needs to be able to both do and explain:
- Visualize and describe a product build cycle end to end;
- Identify the core features in that product and estimate the relative cost of each;
- Break up the development of the product into discrete milestones;
- Sequence those milestones into a schedule;
- Identify areas where features could be cut or altered to help ship faster; and
- Be able to provide a business justification for every technical decision.