4 ms·
You can choose a language that optimizes your hardware, or you can choose a language that optimizes your programmers. 99% of the time optimizing the programmers
by jacobsenscott 7y ago
You can choose a language that optimizes your hardware, or you can choose a language that optimizes your programmers. 99% of the time optimizing the programmers is the right call.
- buzzkillington 7y agoIf you're using anything Hadoop related you're not optimizing programmers.
- PeCaN 7y agothis is the philosophy that brought us software like atom and slack
- jacobsenscott 7y agoCorrect. Two very successful products.
- otabdeveloper4 7y agoYes, if by "optimizing programmers" you mean "optimizing the manager's corporate structure footprint and bonus incentives". If the choice is between hiring one good C++ programmer or 15 really dumb Python "backend engineers" (and a team of QA's and sysadmins to support them), what do you think your pointy-hared corporate boss would chose?
- jacobsenscott 7y agoYou never choose to hire dumb programmers. The choice is between 15 good cpp programmers and 4 good python programmers.
- buzzkillington 7y agoYou have not had to interview the python devs I've had to interview. Last round, for the second best candidate who we hired at 130% the salary we initially offered, after the best candidate was snatched under our nose for what we were told was twice the salary we were offering: >"Last question, I saw that you wrote a 100 line function here, is this because you ran out of time?" >>"No. I don't like to break up my functions. Having many small functions is confusing and bad practice." >What am I doing with my life?
- angrais 7y agoThat sounds more like someone unfamiliar with good practices generally than python-specific issues. Also ... Why'd you hire this person? Is there such a lack of "good" developers in your area?
- OGWhales 7y agomaybe a lack of good developers for the salary they are offering...
- georgeisgeorge 7y agoDid you interview John Carmack by chance? http://number-none.com/blow/john_carmack_on_inlined_code.html http://number-none.com/blow/john_carmack_on_inlined_code.htm...
- cthalupa 7y agoThis is a false dichotomy. You don't have to choose between 1 C++ developer and 15+ package of Python developers. Personal productivity is generally going to be slower in C++ than it is in Python. In most situations you would gain more productivity out of a similarly skilled Python dev as you are a C++ dev, so you'd probably need to hire more C++ developers. Unless your argument is "C++ devs are smart and Python devs are dumb", in which case, let's not start calling people names over the language they use.
- otabdeveloper4 7y ago> Personal productivity is generally going to be slower in C++ than it is in Python. No, it entirely depends on the skill and experience level of the programmer. > In most situations you would gain more productivity out of a similarly skilled Python dev as you are a C++ dev No, a good programmer with equally good knowledge of both languages will code equally fast in both. > This is a false dichotomy. You don't have to choose between 1 C++ developer and 15+ package of Python developers. You failed to see the point. Large teams of clueless programmers doing things slowly and badly is a feature of the system, not a bug. KPI's for managers don't include lowering headcount and cost cutting as an incentive. (And trust me, you really wouldn't like it if they did.) > Unless your argument is "C++ devs are smart and Python devs are dumb", in which case, let's not start calling people names over the language they use. Yet that's effectively what you just did in your specious 'productivity' argument.
- cthalupa 7y ago>No, it entirely depends on the skill and experience level of the programmer. We're comparing programming languages. You control for the other variables - otherwise the comparison is meaningless. My argument is equally skilled programmers will generally be more productive in Python than C++. >No, a good programmer with equally good knowledge of both languages will code equally fast in both. Care to explain how? Huge amounts of the features in these higher level languages are explicitly to increase productivity, and it's generally pretty well accepted they're successful. In this very comment section there's multiple sets of people talking about having to implement their own reference counting systems, and all sorts of other things. Implementing those systems takes up productivity. If any one language was the best at everything, we would only have one language. There's trade offs made, and that's why there frequently is a right language (or set of languages) for one job vs. another. >You failed to see the point. Large teams of clueless programmers doing things slowly and badly is a feature of the system, not a bug. KPI's for managers don't include lowering headcount and cost cutting as an incentive. (And trust me, you really wouldn't like it if they did.) This simply hasn't been the case anywhere I've worked at for a meaningful amount of time. Empire building was plenty discouraged at all of the places I have been employed long term and there were KPIs for reducing headcount, or maintaining it while taking on additional responsibility, and accounting was always happy to step in if costs were increasing without solid justification. Reducing headcount doesn't even have to mean firing people or managing them out - it can be not backfilling spots, helping people find teams with open headcount and transferring, etc. It's never bothered me any - if we have too many people for the amount of work, I'm more likely to get bored. >Yet that's effectively what you just did in your specious 'productivity' argument. You started this whole tangential discussion by taking shots at Python developers for no apparent reason. I'm not calling anyone names, or anything even remotely similar - different languages are frequently differently suited. There's obviously places where C++ makes a lot of sense. I don't really have a horse in this race - right this moment, I'd do basically any serious project in rust, and cargo-script has me even doing small scripts in rust as well. Maybe Erlang or Elixir if OTP makes a lot of sense for the project.