A lot of companies boast being tech agnostic in their hiring process. It makes sense, why limit your candidate pool? “Good developers should be able to pick up the small differences across languages quickly, their algorithm knowledge and experience is what we are looking for” they might say. I recently went from being a language agnostic hiring manager, to language agnostic candidate, to language agnostic hiree, to novice Python developer. It was a very interesting process and I have some insights I’d like to share from each part of the journey.
许多公司在招聘过程中都吹嘘技术不可知。 这是有道理的，为什么要限制候选人池？ 他们可能会说：“优秀的开发人员应该能够Swift发现各种语言之间的微小差异，他们所需要的算法知识和经验是我们所追求的。” 我最近从语言不可知的招聘经理，语言不可知的候选人，语言不可知的招聘人员到Python新手开发人员。 这是一个非常有趣的过程，我希望从旅程的每个部分中分享一些见解。
迎接改变 (Embrace Change)
In my last role I was heavily involved in the hiring process. I was at a Clojure shop, a small but growing Lisp dialect that compiles to the JVM. Since developers that had ever heard of Clojure, let alone written production code, were difficult to find, we looked for strong developers with any language background. We were also writing ClojureScript on the frontend, so even JavaScript developers were starting from scratch.
在上一个职位中，我积极参与了招聘过程。 我当时在Clojure商店里，这是一个很小但正在增长的Lisp方言，可以编译为JVM。 由于很难找到曾经听说过Clojure的开发人员，更不用说编写生产代码了，因此我们寻找具有任何语言背景的强大开发人员。 我们还在前端编写ClojureScript，因此，即使JavaScript开发人员也从头开始。
During an interview, after we worked through whatever modeling or algorithm problem I had given them, I made sure to note ways the problem could have been done if we were using Clojure. There were three different types of reactions to my notes. Some candidates would nod or say that’s interesting. Others would challenge the approach or defend why their native language does it the way it does. The final group would ask more about the features and decisions of Clojure, or even extrapolate ways some features could be used in other problems. I liked these candidates the most, of course.
在一次采访中，在解决了我给他们的任何建模或算法问题后，我确保指出了如果使用Clojure可以解决问题的方法。 对我的笔记有三种不同类型的React。 一些候选人会点头或说这很有趣。 其他人会挑战这种方法或捍卫他们的母语为何以这种方式做到这一点。 最终小组将询问有关Clojure的功能和决策的更多信息，甚至是推断某些功能可用于其他问题的方式。 当然，我最喜欢这些候选人。
What is probably clear is that the knowledge the candidates had previously was probably one of the worst indicators of how successful they would be writing Clojure code. The most successful developers would embrace the Clojure mindset and dig into its features and idiosyncrasies. Developers that had a harder time migrating, would constantly be thinking about a problem in their native language, then attempt to translate that solution into Clojure.
可能清楚的是，候选人以前所掌握的知识可能是他们编写Clojure代码的成功程度的最差指标之一。 最成功的开发人员会接受Clojure的心态，并深入研究其功能和特质。 难以迁移的开发人员会一直以他们的母语考虑问题，然后尝试将该解决方案转换为Clojure。
This is a fault that got me as well. When I was first learning Django, the ORM was a mystery to me. I would want to do seemingly simple queries that I could write easily in SQL but could not figure out for the life of me, how to do it with the ORM. I thought, easy, I’ll write the SQL query first, then convert it to an ORM query. I found a guide on SQL to ORM translations, but it didn’t help. I needed to embrace the ORM mindset. I had to start thinking in the way of the ORM, not translating SQL queries. Once I embraced the ORM, it was a powerful tool that could help me quickly explore data and write more optimized queries.
这也是我的错。 当我第一次学习Django时，ORM对我来说还是个谜。 我想做一些看似简单的查询，这些查询我可以很容易地用SQL编写，但却无法弄清楚我的一生，以及如何使用ORM进行查询。 我以为，很容易，我将首先编写SQL查询，然后将其转换为ORM查询。 我找到了有关从SQL到ORM的翻译的指南，但没有帮助。 我需要接受ORM的心态。 我不得不开始以ORM的方式思考，而不是翻译SQL查询。 一旦接受了ORM，它就是一个功能强大的工具，可以帮助我快速浏览数据并编写更优化的查询。
保持身份 (Maintain Your Identity)
Tooling is another decision to make when embracing a new stack. Do you stick with what you know or take on the tools that are more common for a given language. I was most familiar with IntelliJ as my main IDE. Luckily, Jetbrains also makes PyCharm, a popular Python IDE. I decided to stick with IntelliJ, and a lot of features are identical across the two environments. I was also learning a lot of other tooling, so being at home in my IDE was important. Other tooling and environment changes included: AWS -> GCP, OS X -> Ubuntu, and Sequel Pro -> pgAdmin III. Each of these had their own struggles.
拥抱新堆栈时，要做出另一个决定。 您是否坚持使用已知的知识或使用给定语言更常见的工具。 我最熟悉IntelliJ作为我的主要IDE。 幸运的是，Jetbrains还使PyCharm(一种流行的Python IDE)成为可能。 我决定坚持使用IntelliJ，并且在两种环境中许多功能都是相同的。 我还学习了许多其他工具，因此在家中使用IDE非常重要。 其他工具和环境更改包括：AWS-> GCP，OS X-> Ubuntu和Sequel Pro-> pgAdmin III。 每个人都有自己的斗争。
Some of these choices will be made for you. Sequel Pro is OS X only and doesn’t support PostgreSQL. I was forced to move to a new client. A lot of the other developers would use CLI clients, something I’ve never been a fan of. I was happy to embrace new tools, but losing some of my identity as a developer that uses GUIs seemed too far. Luckily I was able to find pgAdmin which allowed for very similar functionality to Sequel Pro. I even started using a few features that don’t exist in Sequel Pro, like scratch pad, since I was open to discovering everything the new tool had to offer.
其中一些选择将为您做出。 Sequel Pro仅限于OS X，不支持PostgreSQL。 我被迫转到新客户。 许多其他开发人员会使用CLI客户端，我从来都不喜欢它。 我很高兴使用新工具，但是失去了使用GUI的开发人员的身份，似乎太过分了。 幸运的是，我能够找到允许与Sequel Pro非常相似的功能的pgAdmin。 我什至开始使用Sequel Pro中不存在的一些功能，例如便笺本，因为我乐于发现新工具必须提供的所有功能。
决定的决定 (Decided Decisions)
When learning a new code base, it’s important to understand the decisions that were made when designing it. What was top of mind when different models were created. What mistakes had already been made and what refactors had the code already gone through. Another important aspect to know is what are the future plans for the code base. What areas of the application still need to be refactored? What technologies need to be implemented before we can build a certain feature? Most of these questions can’t be answered by the code itself, it can’t be found on StackOverflow questions or even in library documentation. This information lives in the minds of the developers that built and maintained the code base, and if you are really lucky, the documentation they’ve written about their choices.
学习新的代码库时，重要的是要了解设计代码时所做出的决策。 创建不同模型时最要注意的是什么。 代码已经犯了什么错误，重构了什么。 要知道的另一个重要方面是代码库的未来计划。 仍需要重构应用程序的哪些区域？ 在构建特定功能之前，需要实施哪些技术？ 这些问题大多数都无法通过代码本身来回答，也无法在StackOverflow问题甚至库文档中找到。 这些信息存在于构建和维护代码库的开发人员的头脑中，如果您真的很幸运，请参阅他们编写的有关其选择的文档。
During my first few months at Remesh I would be really excited to put up a PR for a medium-sized feature I’d been working on. I’d ask for reviews then see comments and change requests come pouring in. I’m not going to lie, a lot of those early code reviews were rough. Not because I was doing things wrong, sometimes I was, but because I wasn’t aware of a lot of the decisions that had already been made. I didn’t know about conventions that other developers were rightfully trying to follow, to make the codebase more cohesive and easier to comprehend.
在Remesh的头几个月里，我真的很高兴能为我一直在努力的中型功能提供PR。 我会要求进行评论，然后看到评论和更改请求涌入。我不会撒谎，许多早期的代码评论都很粗糙。 不是因为我做错了事，有时是因为我做错了，而是因为我没有意识到很多已经做出的决定。 我不知道其他开发人员应正确遵循的约定，以使代码库更具凝聚力且更易于理解。
Some of these changes were small, but others required large rewrites. Had I run my proposed implementation past a few engineers before starting to code, they probably would have brought up ways it wouldn’t fit with the companies coding styles. Doing a quick review beforehand would have saved me a ton of time after the fact. That’s why I pushed hard to implement a formal review process at Remesh, to save other developers from the problems I faced.
其中一些更改很小，但其他一些则需要大量重写。 如果我在开始编写代码之前先让我的提议的实现超过了几个工程师，他们可能会提出不适合公司编码风格的方法。 事前进行快速回顾可以为我节省大量时间。 这就是为什么我努力在Remesh实施正式的审查流程，以使其他开发人员免于遇到的问题。
Design reviews are a great way to document all of these choices and make sure they coincide with decisions other developers are making. Our design review structure is pretty simple. A quick summary of the problem you are trying to solve, followed by a list of any solutions you considered and the solution you hope to implement.
设计评审是记录所有这些选择并确保它们与其他开发人员正在做出的决策一致的好方法。 我们的设计审查结构非常简单。 快速总结您要解决的问题，然后列出您考虑的所有解决方案以及希望实施的解决方案。
This format has a few benefits:
这种格式有一些好处：
Comparing trade-offs better frames the problem. Reviewers are able to quickly see the proposed solution and comment on why they prefer one solution over another. Seeing solutions the designer didn’t choose can give better insight on what problem the designer is trying to solve. Often the real problem is discovered by the solution that is chosen, or why a seemingly simple problem has such a complex solution.
比较权衡可以更好地解决问题。 审阅者能够快速查看提议的解决方案，并评论为什么他们偏爱一种解决方案而不是另一种解决方案。 查看设计人员未选择的解决方案可以更好地了解设计人员要解决的问题。 通常，真正的问题是由所选择的解决方案发现的，或者为什么看似简单的问题具有如此复杂的解决方案。
Design reviews are overhead. Though they can drastically increase performance by preventing poor designs that need to be drastically refactored, it is a lot of work writing documentation that may only be reviewed quickly by peers. Listing the nitty details of how the implementation will work can be an unnecessary step. A lot of times these kinds of decisions are better communicated as code. What was considered? Why don’t certain solutions work well? How is this problem different from the other problems that seem similar to this problem? These are the types of questions a design review should be answering.
设计评审是开销。 尽管它们可以通过防止需要彻底重构的不良设计来极大地提高性能，但很多工作都是编写文档，这些文档只能被同行快速审查。 列出实现的工作原理的详细信息可能是不必要的步骤。 很多时候，这些决策可以更好地作为代码进行传达。 考虑了什么？ 为什么某些解决方案不能很好地工作？ 这个问题与看起来与此问题类似的其他问题有何不同？ 这些是设计审查应回答的问题类型。
It creates clear patterns for the future. There are many ways to skin a cat, good engineering organizations solve problems in similar ways so they can easily be understood by and communicated to, the rest of the organization. This allows multiple developers to work on many parts of the codebase, knowing it will be familiar and follow certain patterns. Design reviews help limit the number of patterns. Unless a problem truly requires a unique solution, we prefer to use a pattern we have used before. Design reviews document these patterns and provide a good list of patterns to choose from.
它为未来创造了清晰的模式。 有很多方法可以解决问题，好的工程组织可以用类似的方式解决问题，以便组织的其他成员可以轻松理解并与他们交流。 这使多个开发人员可以在代码库的许多部分上工作，知道它会很熟悉并遵循某些模式。 设计审查有助于限制样式的数量。 除非问题确实需要独特的解决方案，否则我们更喜欢使用以前使用的模式。 设计评审记录了这些模式，并提供了可供选择的良好模式列表。
Learning a new code base is tough, learning a new language on top of that is even harder. By following the rules above:
学习新的代码库很困难，在此之上学习新的语言就更加困难。 通过遵循以上规则：
- Embrace the conventions and patterns of the new language 拥抱新语言的约定和模式
- Select tooling that is familiar but works well with your new stack 选择熟悉的工具，但可以很好地与新堆栈一起使用
- Use design reviews to get clarity on problems early and prevent large rewrites after a code review. 使用设计审阅可以尽早弄清问题，并防止在代码审阅后进行大量重写。
You will have no trouble learning a new language and code base.
学习新的语言和代码库将毫无困难。
翻译自: https://remesh.blog/the-tao-of-agnosticism-a16ad408dd1e
扫一扫
2009
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
