[转]The proof is in the code. That is all.

本文探讨了在招聘程序员时,技术能力与团队文化的平衡问题。技术能力强但缺乏沟通的程序员可能更适合某些职位,而技术一般但具有良好团队合作精神的程序员则可能在构建稳定软件方面更有优势。文章指出,在现实世界中,找到同时具备卓越技术和良好团队文化的程序员并非易事,企业往往需要在两者间做出权衡。

 

When hiring a programmer, the only thing that really matters is their ability to write good code. Finding people who can do this are so rare that it’s generally preferable to excuse any personality quirk or deficiency they have.

As soon as I say that, a huge number of people will comment that it’s wrong, wrong, WRONG. Good programmers need to have communication skills and be able to work with others.  There is no I in TEAM! In fact, they would argue that it’s better to compromise your skill requirements in order to find the right culture fit.

 

It would be nice if we could say: don’t hire until you find someone with both great technical skill AND great culture fit.  Except very few of us have that luxury, except maybe Google, and even they are in a constant state of desperate-to-hire-programmers.  If you decide to wait, expect to wait for a very long for each hire, even while your businesses crashes and burns in need of a programmer.

So, which is it?

Let’s consider the mediocre to poor programmer who is amiable and works hard. His code isn’t good – it doesn’t really do what it’s supposed to do and even when it does, it’s sloppy and hard to maintain.  He struggles with basic functionality and is not able to tackle complex problems at all.  But he does get along with the team and the project tracking tool is always up to date and he gives plenty of butt in seat time.  You’ll be alright for a while because your managers will be happy to see such a smooth-running team.

When releases are slipping and the product is too buggy to use, people will lament that software is just so hard and throw more mild-mannered mediocre programmers at the problem. And we all know how this story ends.

For programmers, there is no amount of nice that makes up for getting things done.  A friendly mediocre programmer can become a business analyst or a technical salesperson or some other thing where he can leverage his friendliness and his bit of technical knowledge.  Working with them may be pleasant but it is a tea party, not a smart way to build good software.

The other option is a programmer who delivers great code and maybe doesn’t get along so well with others or comes in late or whatever. He builds an application that does what it is supposed to do and abstracts complex problems into simpler ones.  The software works and is maintainable enough to change it when needed.

This is the real world and there are plenty of ways that things may still get all screwed up, but at least you have a chance.  Good presentation skills are nice.  Team building is nice.  Employees working long hours for you is nice.  Plenty of businesses don’t do these things and still succeed, but no one succeeds at building great software with crappy programmers.

The proof is in the code. That is all.

转载于:https://www.cnblogs.com/weisteve/archive/2010/08/25/1808043.html

翻译并用 latex 渲染: First, let's see how many zebra-Like numbers less than or equal to 1018 exist. It turns out there are only 30 of them, and based on some zebra-like number zi , the next one can be calculated using the formula zi+1=4⋅zi+1 . Then, we have to be able to quickly calculate the zebra value for an arbitrary number x . Since each subsequent zebra-like number is approximately 4 times larger than the previous one, intuitively, it seems like a greedy algorithm should be optimal: for any number x , we can determine its zebra value by subtracting the largest zebra-like number that does not exceed x , until x becomes 0 . Let's prove the correctness of the greedy algorithm: Assume that y is the smallest number for which the greedy algorithm does not work, meaning that in the optimal decomposition of y into zebra-like numbers, the largest zebra-like number zi that does not exceed y does not appear at all. If the greedy algorithm works for all numbers less than y , then in the decomposition of the number y , there must be at least one number zi&minus;1 . And since y&minus;zi&minus;1 can be decomposed greedily and will contain at least 3 numbers zi&minus;1 , we will end up with at least 4 numbers zi&minus;1 in the decomposition. Moreover, there will be at least 5 numbers in the decomposition because 4⋅zi&minus;1<zi , which means it is also less than y . Therefore, if the fifth number is 1 , we simply combine 4⋅zi&minus;1 with 1 to obtain zi ; otherwise, we decompose the fifth number into 4 smaller numbers plus 1 , and we also combine this 1 with 4⋅zi&minus;1 to get zi . Thus, the new decomposition of the number y into zebra-like numbers will have no more numbers than the old one, but it will include the number zi — the maximum zebra-like number that does not exceed y . This means that y can be decomposed greedily. We have reached a contradiction; therefore, the greedy algorithm works for any positive number. Now, let's express the greedy decomposition of the number x in a more convenient form. We will represent the decomposition as a string s of length 30 consisting of digits, where the i -th character will denote how many zebra numbers zi are present in this decomposition. Let's take a closer look at what such a string might look like: si&isin;{0,1,2,3,4} ; if si=4 , then for any j<i , the character sj=0 (this follows from the proof of the greedy algorithm). Moreover, any number generates a unique string of this form. This is very similar to representing a number in a new numeric system, which we will call zebroid. In summary, the problem has been reduced to counting the number of numbers in the interval [l,r] such that the sum of the digits in the zebroid numeral system equals x . This is a standard problem that can be solved using dynamic programming on digits. Instead of counting the suitable numbers in the interval [l,r] , we will count the suitable numbers in the intervals [1,l] and [1,r] and subtract the first from the second to get the answer. Let dp[ind][sum][num_less_m][was_4] be the number of numbers in the interval [1,m] such that: they have ind+1 digits; the sum of the digits equals sum ; num_less_m=0 if the prefix of ind+1 digits of the number m is lexicographically greater than these numbers, otherwise num_less_m=1 ; was_4=0 if there has not been a 4 in the ind+1 digits of these numbers yet, otherwise was_4=1 . Transitions in this dynamic programming are not very difficult — they are basically appending a new digit at the end. The complexity of the solution is O(log2A) , if we estimate the number of zebra-like numbers up to A=1018 as logA .
08-26
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值