医生和程序员 哪个更好_成为更好的程序员

医生和程序员 哪个更好

I’ve had a lot of years in this industry, I like to think that experience is worth something. And I believe that it is worth something if it can be applied to modern-day problems. Thirty years ago, if Medium existed, I could have written a popular how-to on creating a linked list in C. If I wrote something like that today, I’d have empty eye sockets for viewers. The world has changed, and I’ve had to change along with it. So I need to boil down the essence of what remains constant — the things that never change.

我在这个行业已经有很多年了，我想认为经验是值得的。 而且我认为，如果可以将其应用于现代问题， 则值得。 30年前，如果存在Medium，我本可以编写一个流行的方法来编写用C语言创建的链表。如果今天写这样的内容，那么观众的视线就会空洞。 世界已经改变，我也必须随之改变。 因此，我需要总结保持不变的本质-永不改变的事物。

I usually like to write how-to articles, things that solve a concrete problem with functioning code to back it up. I also see a lot of opinion pieces here, often with little to justify it other than the author’s opinion. I really don’t care which programming language or editor/IDE is better. If I’m going to write an opinion piece, it’s not to rank preferences. It’s about those tiny kernels of truth that can be expanded upon in any circumstance. It’s about a universal philosophy of programming that’ll always get you from start to finish with minimal effort.

我通常喜欢写how-to文章，这些文章通过使用功能强大的代码来解决具体问题来进行备份。 我在这里还看到了很多意见书，除了作者的意见书之外，几乎没有其他理由。 我真的不在乎哪种编程语言或编辑器/ IDE更好。 如果我要写一篇观点文章，那不是要对首选项进行排名。 它是关于那些在任何情况下都可以扩展的微小真理核心。 这是关于通用编程哲学的，它将始终以最小的努力使您从头到尾。

几个问题无法解决 (Few Problems Can’t Be Solved)

There haven’t been many roadblocks I’ve faced that I wasn’t eventually able to overcome. I’m not talking about solving NP-complete problems in polynomial time. I’m talking about the times that a bug creeps into your code, and it seems almost impossible to track down.

我没有遇到很多阻碍我最终无法克服的障碍。 我并不是说要在多项式时间内解决NP完全问题。 我说的是bug潜入您的代码的时间，似乎很难追踪。

These can be very daunting and discouraging. But every time I face such a problem, I remember all the times in the past that I was able to overcome the issues. It has given me optimism that keeps me going. Sometimes it’s as simple as putting in enough print statements (a great approach for multithreaded race conditions that can’t be captured in a debugger). Sometimes it’s turning on the profiler and noticing a certain function doesn’t get executed as many times as I’d think it would. Sometimes it’s backing out to a known good state and adding, piece by piece, the new, breaking code back in.

这些可能非常令人生畏和令人沮丧。 但是每次遇到这样的问题时，我都会记得过去的所有时候都能克服这些问题。 它使我保持前进的乐观态度。 有时，它就像放入足够的打印语句一样简单(这是一种无法在调试器中捕获的多线程竞争条件的好方法)。 有时，它打开了探查器，并注意到某个功能没有像我想的那样执行多次。 有时，它会退回到已知的良好状态，并逐步添加新的，破损的代码。

You can ask my wife how many times I’ve confided to her that I think I’ve finally met my match and I’ll never get something working, only to have to take it back a few days later when an aha moment occurs.

您可以问我的妻子，我已经跟她说过几次，我想我终于满足了我的比赛，而且我永远也做不了什么，只需要在几天后的aha时刻把它拿回来。

When I write articles here on how to do something, there’s usually one thing that doesn’t work quite right at first. I refuse to publish unless I can run what I’m making in a repeatable fashion. So sometimes articles go on hold for a week while I clear my head. If I’m going to establish myself as a respected writer, both my prose and my code must work in as many situations as I can imagine (of course, code is easier to test, so sometimes my prose has a few syntax errors).

当我在此处写有关如何做某事的文章时，通常一开始通常没有一件事是正确的。 我拒绝出版，除非我能以可重复的方式运行自己的作品。 因此，有时在我清醒头脑时，文章会暂停一周。 如果我要成为一个受人尊敬的作家，我的散文和代码都必须在我能想象的尽可能多的情况下工作(当然，代码更容易测试，因此有时候我的散文有一些语法错误)。

不只是学习方法-学习原因 (Don’t Just Learn the Hows — Learn the Whys)

Anyone can learn a new methodology, but without understanding its purpose it’ll often be misused.

任何人都可以学习一种新方法，但是在不了解其目的的情况下，它经常会被滥用。

When I learn a new methodology I always want to know what problem does this solve that my old way of doing things doesn’t? This often involves digging under the surface and seeing how one methodology evolves from another.

当我学习一种新的方法论时，我总是想知道什么问题可以解决我以前的做事方法不能解决的问题？ 这通常涉及在地下进行挖掘，并观察一种方法论如何从另一种方法演变而来。

Programs still work the same way, steps execute sequentially one after the other. But the methodologies allow us to describe and organize that sequence and allow more and more code to be written for us. Object-oriented programming allows us to think about behavior and state and promotes state encapsulation (I don’t buy into polymorphism much anymore — it promotes more complexity than it reduces). Functional programming allows us to define chains of functions that pass along the state that evolves in a precise fashion. In both of these cases, the state is the demon we’re trying to wrangle into behaving well.

程序仍然以相同的方式工作，步骤依次执行。 但是这些方法允许我们描述和组织该序列，并允许为我们编写越来越多的代码。 面向对象的编程使我们能够考虑行为和状态，并促进状态封装(我不再相信多态了-它带来的复杂性超过降低的复杂性)。 函数式编程使我们能够定义函数链，这些函数链以精确的方式经过不断发展的状态。 在这两种情况下，状态都是我们要努力表现良好的恶魔。

This doesn’t just go for methodologies — but patterns as well. I’ve known many programmers who don’t bother to learn more than a few patterns and then apply them universally. Often with disastrous results. Know your patterns and how to apply them. Identify the patterns you see that aren’t in the canon and think about how you can reuse them in the future. And, of course, know the dreaded antipatterns and code smells.

这不仅适用于方法论，还适用于模式。 我知道许多程序员不愿意学习更多的模式，而是将其普遍应用。 通常会带来灾难性的结果。 了解您的模式以及如何应用它们。 确定您所看到的不在典范中的模式，并考虑将来如何重用它们。 并且，当然，知道可怕的反模式和代码气味。

学习新语言 (Learn New Languages)

I don’t care how much experience you have in Java. If you don’t know at least three or four other languages, I suspect your curiosity.

我不在乎您有多少Java经验。 如果您至少不懂其他三种或四种语言，我怀疑您的好奇心。

Knowledge of different languages gives you not just another syntax but often a new way of looking at things. At my day job, I work in several different languages, often on the same day. Being fluent in multiple languages allows me to make that context switch much smoother.

对不同语言的了解不仅为您提供了另一种语法，而且还常常为您提供一种全新的视角。 在我的日常工作中，我常常在同一天使用几种不同的语言工作。 流利的多种语言使我可以更轻松地进行上下文切换。

To me, all languages are just English dialects, and the syntactical differences amount to minor aspects that the IDE often adjusts for. But each presents the programming problem in different ways that broaden your way of thinking about programming in general.

在我看来，所有语言都只是英语方言，而语法上的差异则是IDE经常调整的次要方面。 但是每个人都以不同的方式提出了编程问题，从而拓宽了您对编程的一般思考方式。

And I don’t just mean languages but also programming styles. Of course, there are as many programming styles as there are programmers. But quite often our jobs as programmers are as crypt keepers, maintaining ancient code whose originators are long gone. And good that they’re gone because judging from the quality of their code, they must have been dubious individuals indeed.

我不仅指语言，还指编程风格。 当然，编程风格与程序员一样多。 但是，我们作为程序员的工作常常是作为密码库的维护者，维护着源远流长的古老代码。 而且很高兴他们离开了，因为从代码的质量来看，他们确实确实是个可疑的人。

But don’t make the fatal mistake of thinking you’ll rewrite everything — honestly, it’s not worth it. Those old programs have dozens, if not hundreds, of undocumented behaviors, and if you miss the wrong one and it crashes production, you’ll have some ‘splaining to do.

但是不要以为您会重写所有内容而犯致命的错误-老实说，这不值得。 那些旧程序有数十种(甚至不是数百种)未记录的行为，并且如果您错过了错误的行为并导致生产崩溃，您将需要做一些“简单的事情”。

知道你周围发生了什么 (Know What’s Going on Around You)

Don’t be one of those programmers that merges the change request and moves on. Learn how to tune the database. Learn how to package for distribution. Learn how to create and run performance tests. Learn, learn, learn.

不要成为合并变更请求并继续前进的程序员之一。 了解如何调整数据库。 了解如何打包分发。 了解如何创建和运行性能测试。 学习，学习，学习。

One of my favorite expressions is “writing programs isn’t hard; creating products is hard.” Learn the hard part, and you’ll be indispensable. When the application slows down in production and you notice the production database has the bitwise cache aligned incorrectly, you’ll be the hero of the day.

我最喜欢的表达方式之一是“编写程序并不难； 创造产品很难。” 学习困难的部分，您将是必不可少的。 当应用程序的生产速度降低时，您会注意到生产数据库的按位缓存对齐方式不正确，您将成为当今的英雄。

And don’t just learn in-depth — learn the breadth of things. If your company uses MySQL, learn it well but also learn about MariaDB and Cassandra. Learn the different message queues and reverse proxies. If you’re working on the back end, learn about the front end — and vice versa. Learn about containers and container orchestration.

而且，不仅要深入学习，还要学习事物的广度。 如果您的公司使用MySQL，则要学得很好，而且还要了解MariaDB和Cassandra。 了解不同的消息队列和反向代理。 如果您在后端工作，请了解前端，反之亦然。 了解有关容器和容器编排的信息。

Being a programmer isn’t just about programming. If you want to be in the top 10%, you have to know how all the parts work and how they all play together.

成为程序员不仅仅与编程有关。 如果要进入前10％，您必须知道所有部分的运作方式以及它们如何共同发挥作用。

Most importantly, it’s not about writing the most code, it’s about writing the least amount of code and still have a working program. For me, the greatest achievement in this line of work is when the crypt keeper working on your old code would like to invite you out for a drink.

最重要的是，这与编写最多的代码无关，而是与编写最少的代码并且仍具有有效的程序有关。 对我来说，这方面的最大成就是从事旧代码的隐秘管理员想邀请您出去喝酒。

翻译自: https://medium.com/better-programming/becoming-a-better-programmer-b3cffc45c315

医生和程序员 哪个更好