Hacker News Reader

Comment by miahi | Hacker News Reader

Can you give your definition for both these roles? I thought they are different jobs.

Software developers are concerned with making things "the right way" - eg. in the article the writer speaks about choosing the right data structure, algorithms etc.

Users couldn't care less about a perfect domain model, dependency injection or asynchronous yada yada.

They care if it works and Product Developers know this.

Obligatory counterpoint:

"Drivers don't care about different ways of reinforcing concrete or finite element modelling or yada yada, they just care if the bridge works."

If the users don't care, it's because they don't really understand why the software they pay for and put up with over the years becomes an unmaintainable nightmare...

I'm not understanding your point. Do you mean that users need to understand how software works in order to appreciate it?

No, but just because the users don't care (right now) doesn't mean it's not important. As a driver, I don't particularly care about bridge engineering, but I certainly want the people who build my bridges to care about it.

Imagine you have a web startup and as soon as people visiting your website start coming with reasonably large data sets, your website becomes noticeably sluggish.

And then a competitor pops up and they are dealing with the same sized data blazingly fast, instantly from the user's perspective.

And you look into it and they are using the same technology stack you are using.

It's at that point that you might start to care about the difference between a linked list and a hash table.

And at exactly that point (but rarely before), a good "product developer" puts on his "software developer" hat, and executes his finely-tuned JIT learning subroutine. He Googles "[framework] profiling", spends a week collecting information, tracks down the bottleneck, makes a fix, tests it, evaluates the new output, then calls it a day or repeats from step 1 until the issue is resolved.

Or a if you already know the difference you take a minute to look at the APIs you are using and switch to the one which is implemented with a hash table instead of a linked list. One minute vs. a week. A week here and a week there adds up.

You're missing the point.

Of course users care about page load time - scalability should be built in to an application from day one (I never said otherwise). Modern Paas services allow for this more or less out of the box so there's no excuse not to have scalability built in.

I've built apps that scale well (over 100 concurrent users) but have still never had to worry about whether to use a linked list or a hash table.

So in your vision a software developer is someone who creates "very correct" applications, while a product developer is someone who hacks an application that somehow works, with no clear model, no standards and patterns.

I would call your product developer a cowboy programmer. Been there, done that, after the cowboy leaves the result is a maintenance nightmare.

I didn't say that (good) product developers should employ bad practice in order to get something out the door.

I meant that product developers know when something is good enough (or "will do for now") whilst IMO software developers want to iterate and iterate to a perfect, elegant solution.

Don't get me wrong, the latter may be the correct choice to take but only when its for a feature that people are actually using.

From a business perspective, a software developer who is sitting on functionality thats "not quite right yet" is the cowboy programmer. But I guess thats just perspectives for ya :-)

I think he means people who can ship code.

Reply on news.ycombinator.com