281–290 of 321 posts
This is far too extreme and turns you into a counterproductive team member. Like everything in life, a balance demands to be struck.
Earlier quoted context omitted.
Finding a better solution by changing the problem is great, especially as the problem stated is often not the problem faced. Not doing something, or doing something dramatically simpler, ends up with less code being written. The cost of writing the code is usually a small fraction of the cost of supporting it during over the life span of the system. One problem I faced was a client that as part of an e-commerce re-im…
This is the difference between a real programmer and a coding monkey. Coding monkeys consider the spec the problem and try to write code that solves it. Programmers consider the spec a part of the solution and evolve it as necessary.
Earlier quoted context omitted.
"great design is the key to increased productivity" Given how many times the 90/10 principle will brutally murder your time estimates ("we're 90% done, so there's only 90% left to go!"), learning to also harness it in your favor as antirez talks about is a great programmer differentiator. If 90% of the effort is coming from 10% of the design, and you can find some way to cut that part of the design in half, you just…
I'm proud to say that I've accomplished that, at least once. My company was developing a new feature, hundreds of medical textbooks that would be searchable and readable online. The source content for each textbook consisted of a huge xml file and a bunch of images. The problem we faced was that many of our customers were government-funded libraries, and they required a physical product for anything they purchased. (…
Earlier quoted context omitted.
Another great thing here: "Design sacrifice: killing 5% to get 90%." I remember a very specific example of this from Perl 6 development circa 2009. perlgeek (I think) and I had been struggling with coding up the sequence operator for a couple of months. Every time we thought we had it, someone would come up with a case that broke the system again. pmichaud (not sure if it's the same pmichaud here on HN) comes up to u…
Perfect is the enemy of good enough. If you never ship a "perfect" product, it has 0 value. In the end, you provide value or you don't. The hardest thing about any product development is to stop taking things out or worse yet, keep adding things in. The top performers are usually the ones who can weigh these pros and cons almost immediately and force the product in a better direction.
You forgot one... sacrificing the efficiency of others to gain multipliers. By undermining team communication, future maintainability, etc, the 10x can appear much faster. This speed is gained not by truly being more efficient, but rather by the coding equivalent of maxing out your credit cards and mooching off your friends. It looks good at the present, but the team pays for it in the long run - long after Mr 10x (i…
Interestingly, sometimes that cleanup was an intentional part of the process and looked more like maintenance and extension of rapid prototypes. It still felt like I was compensating for all those bad habits of Mr 10x.
20% - Not productive. They can't get their tasks done, and after awhile, no one even expects them to. They get routed around. 65% - Neutral. The quality problems and technical debt they incur matches their productive work. 12% - Net negative. They introduce hard to fix bugs and technical debt beyond their productivity. 3% - Gods. They do almost all the productive work. Without these types of people, no large project would ever get done.
I've seen cases where one ostensibly 10x developer comes in and solves 90% (the easy parts) of a problem. Management love him. Then he moves on to other projects and leaves a team of "1x developers" to deal with the 10% (which management still insist on having). This team now have to re-write everything this superstar did from the ground up without taking shortcuts this time. The time it takes makes them all look like 0.1x developers.
While I completely agree that some programmers can be 10x more productive than other ones, I think it's far more common to see programmers who LOOK 10x more productive than others. It's very hard to compare people who have different problems to solve. Solving 90% of the problem is not the same as solving 100% of the problem, and sometimes that 10% really is worth the effort. I've seen cases where one ostensibly 10x d…
Whether it's an engineer, or a manager, or C-level executive, this is very easy to achieve by borrowing from the future. Very difficult to solve I think.
It's about the unintended side effects of trying to be a 'Natural Selector'. One example is selecting individual hens on egg output to create a breed of high-egg producers. The result was mean chickens which had gains b/c they were very aggressive. The breed needed to have their beaks clipped otherwise they would kill each other. When productive groups rather than productive individuals were selected though, they got the desired effect. (Though in another example I can imagine selecting for mean group behavior)
Another example was trying to selectively evolve animals that would self-limit reproduction. (to avoid overpopulation and resource over-consumption) The end result was selecting for cannibalism.
In organizations, the equivalent of propagating a feature are the hiring stage and the promotion stage. Whatever you hire for, or promote for, will be the trait that's optimized. Whatever the side effects may be... (e.g. Enron)
In this thread: mostly people responding to the headline, not the actual content of the article. There's some fantastic stuff in here about how great design is the key to increased productivity. For example: "It is very important for a designer to recognize all the parts of a design that are not easy wins, that is, there is no proportionality between the effort and the advantages. A project that is executed in order…
"great design is the key to increased productivity" Given how many times the 90/10 principle will brutally murder your time estimates ("we're 90% done, so there's only 90% left to go!"), learning to also harness it in your favor as antirez talks about is a great programmer differentiator. If 90% of the effort is coming from 10% of the design, and you can find some way to cut that part of the design in half, you just…
I pored through the specs, talked to everyone who would use this, and realized all the queries could be calculated from a much smaller, summarized version of the data.
I wrote a script that would create an Excel PivotTable every month and send it to everyone who asked, solving the problem in a few weeks with a Good times.