Hacker News Reader

That's a really good point. It's worth remembering that the person picking the low hanging fruit will often fill up the baskets faster than the person who climbs up to the tall branches, But since anyone can pick the low hanging fruit, you may need to send your most talented people into lower-yield environments, since they're the only ones who can do it.

Productivity really is difficult to measure, especially in software development.

It's not low/high hanging apples. It's apples and oranges. 1X programmer does job that is immeadiately visible and has value. 10X programmer writes code that has potential value, which is to be seen in the future, probably when some other 1X programmer implements his code. I now remembered a quote Anthony Hopkins said on 'Inside the actor studio' which he learnt while having a role as a butler: When you're in the room it has to be more empty. Same goes to great programmer and software system as is mentioned in the article.

Oh yes, completely agree. I was making a minor point about productivity, but this isn't the biggest issue at all in software development.

The biggest productivity difference between two programmers isn't that one of them produces more of the same thing as the other. Or that one of them produces more of a better thing that the other. Or even that one of them produces a more of a better, different thing than the other. It's that one of them actually grasps the thing that should to be done and does it. And it can take a long time to even realize or understand what it is the programmer is doing (often, the programmer doesn't fully understand it at first either).

My biggest problem with the 10x productivity claims is that it ignores the most relevant difference. The best programmers don't do the same things faster, they do completely different things.

> My biggest problem with the 10x productivity claims is that it ignores the most relevant difference. The best programmers don't do the same things faster, they do completely different things.

I thought the 10x productivity claim was originally from a study of comp sci students working on some algorithm (maybe compression algorithm) homework. In which case the "I think I've seen this before" example from the article probably factors in most.

A good manager in a software company should have a decent grasp of project complexity and output quality of his subordinates.

The examples listed seem to appear at companies that have in-house developers, but don't really think of IT as an area they should focus on. Similarly, I often found my ex ad-agency co-workers have trouble understanding why I have to browse blogs/manuals, take time to think things through, sketch graphs and sometimes just start over instead of refactoring.

Really, software managers should have no trouble noticing a 10:1 skill difference between devs.

There are very few good managers, and when you think about it very few programmers work in software companies. Instead they work for trading firms, utilities, banks, government agencies, etc.

When the business of the company isn't software, there is a good chance that the manager won't be a software developer. The criteria the developer is judged by will have nothing to do with the complexity of the software or the time it takes to create. Instead, their work will be judged and compensated by the value it delivers to the organization. Even if it's crappy software.

> The criteria the developer is judged by will have nothing to do with the complexity of the software or the time it takes to create. Instead, their work will be judged and compensated by the value it delivers to the organization.

You say that like it's different, or should be, at a software company.

I disagree. I think that all work for an organization should be judged and compensated by the value said work delivers to said organization, regardless of the organization type, regardless of the work type.

> Even if it's crappy software.

Surely you're not suggesting that crappy software is always wrong/bad.

Good software is often more expensive than crappy software. That added expense doesn't necessarily produce more value.

Good programmers know that they're trying to maximize benefits-costs, not maximize the former, not minimize the latter.

Worse can be better.

Really, software managers should have no trouble noticing a 10:1 skill difference between devs.

I absolutly agree with you, and on HN many of us are in a filter bubble in which the companies we are surounded my have a good deal of people that know software and creativity. The reality out in the real word though is much different. Many companies have managers that have never worked on software in their life, there is a school of thought that management is management, and for some disciplines it is true management is transferable, those of us in technology know this to be idiotic but if you came from a traditional enterprise and have seen multiple manager move from inventory to shipping and be successful you would believe the converse to be true. Years of observation reinforce this to those individuals and create cultures in which management is management.

How many people are "software managers" in a company, vs "managers" who happen to have people doing software in their dept? I worked someplace where they proudly stated "we're not a software shop!". They had 100+ software engineers working on stuff that managed billions of dollars in money for the company. But "they're not a software shop". OK.

They really weren't as bad as that statement makes them seem, and I think it was more a misguided "rah rah" statement than a core mentality, but there were days when I couldn't quite tell.

Love this example for two reasons, the first being the one you mentioned, and the other being the fact that the troublesome/interesting call probably isn't generating more revenue for your employer than the simple/boring call.

So writing a JavaScript drag-and-drop widget framework counts as complicated?

Have you tried it? (Don't forget to make sure it works in all the browsers at decent speeds!) It's not the most difficult thing, but it's reasonably complex, it doesn't seem like a bad example. How many teams have one person working on satellite code in Common Lisp and another doing a basic e-commerce site for a client?

Writing a CRUD app with business logic sounds more complicated.

The tough part is extracting the business logic and correctly mapping this to code. If done well, this will create more value to the business than a drag-and-drop framework.

That's the specific type of programming that's mentioned in the article "I am a programmer":

"We're middle-men (and women), glorified translators, and we're in the unbelievably fortunate position that programming computers is still much too hard for the average user of those computers, so we translate wishes and domain knowledge into a mental representation of machinery that performs some useful task."

The business logic is "the hard part" only in terms of client communication and project management, and then only barely.

Learning that "an Account Rep has Clients", and then modelling and implementing that, is ... not challenging? Three lines of ActiveRecord ('Duplo')?

They both vary tremendously depending on the problem, but on the whole, 'javascript widgets' trumps 'business logic' hands down. The fact that most business logic is simple is why you can glue things together so fast in Rails.

Olark's whole business is making a single javascript widget, and last I checked, they're still hiring.

Making things behave as expected in as heterogenous environment as the browser can be enormously complex as the sophistication and scope of the UI you present the user grows.

Boy, I really have a different opinion of enterprise software. The number and complexity of all of the various cases is astounding! To make it worse, they frequently come with no underlying framework, so you have to extrapolate and hope that you don't bake in something that's going to change next week.

IMO, making that software to handle the business processes IS way more valuable to the business than a drag and drop widget framework. Especially if you execute it well, it can make the business hum.

Enterprise software is not complex because it needs to be it's complex because the east way to deal with complexity is to create a complex system. Take the database design for my current project when I joined the project the database design had over 500 tables for a brand new system. But, by making a few minor design changes I cut several hundred tables from the design without sacrificing anything. At one point I removed 30 tables by adding a single field to a single table.

PS: Yes, copy and paste is easy, and yes it looks like work, but it's rarely the correct solution.

See my other reply below to toyg, if your company is writing a lot of similar software your going to have to start making flexible standard stuff rather than rewriting it every time.

But I agree with you if you're going in with a blank slate.

The business logic is "the hard part" only in terms of client communication and project management, and then only barely.

Yeah, but it's the part that most customers actually want. They pay for that, not for javascript widgets. A lot of customers are incredibly happy with basic, predictable interfaces, as long as they perform all the necessary "magic" calculations in the background, quickly and reliably.

So many developers waste their time chasing "the shiny", but most of the money is actually elsewhere.

This was an extensible product, it had to be able to handle extra functionality and the widgets were a way of achieving this, so it had real business value.

And to answer the original question, yes it was complex, but that was 5 years ago. People didn't really know how to build complex solutions in javascript and there were no working examples you could just copy, paste and modify.

You were also very restricted by the speed that IE6 ran javascript on old computers.

As far as usability is concerned, basic predictable interfaces are what you should be building unless the data & interaction you're modeling is unique enough to require non-standard UI.

Have a read of this http://c2.com/cgi/wiki?WhyIsPayrollHard and see why it is not as simple as "Three lines of ActiveRecord".

"They both vary tremendously depending on the problem, but on the whole, 'javascript widgets' trumps 'business logic' hands down."

If you believe this then perhaps you have never developed anything complicated at all.

"The fact that most business logic is simple is why you can glue things together so fast in Rails."

If it is this simple one must question why the work is done by a developer at all. Why are users not using some sort of web-based MS Access?

Yes. And it simply _must_ be done. The widget drag-and-drop javascript framework is merely powdered sugar on the cake (not even frosting).

interesting/boring* doesn't always correspond to complicated/easy.

Actually, it might be even more complicated to _complete_ the extremely boring task.

* - in this particular example, js drag&drop being an interesting task is a subjective assumption, but I guess "yet another CRUD app" being boring is an objective reality :)