3 ms·

What matters in software: creating value, shipping product to the end user. What matters to software engineers: just about everything else, for some reason.

What matters in software: creating value, shipping product to the end user. What matters to software engineers: just about everything else, for some reason. Oddly, when I talk to software engineers, most of them just want to create value, ship product, and (hopefully) come out with a readable codebase. Yet when I read blogs or HN, everyone seems to be obsessing over the "value" of exotic languages, 'new' paradigms (usually rediscovered), obscure algorithms, and sample code so simplistic or contrived as to be meaningless. The one constant is that whatever was done ten years ago was pure folly, but luckily we know better now.

tikhonj 15y ago
Maintenance and robustness matter as well. You not only need to deliver a product, but you need to ensure that it does what it's supposed to as much as possible, and fix it if it breaks. Most products--particularly successful ones--take a lot more effort to maintain (both in fixing bugs and adding features long after the initial release) than to publish. You want to minimize the amount of effort needed to add features or fix bugs; a good way to do this is to have shorter, more elegant code. Additionally, plenty of fields require very robust code. If all you do is share pictures of cats a server held together by Perl and prayer is more than good enough. If you're investing large sums of money based on computer models, you better not have any errors. There is a reason why banks are some of the main users of Haskell. So: releasing is only part of the game. In certain cases valuing a faster turn-around is more important than code quality; in others, the cost of maintaining a poor code base far outlives the advantage of releasing early. However, there is another problem with this article: elegant code and "focusing on the application" are not mutually exclusive. If anything, writing elegant code will probably save you time, let you reuse more code and spend less time debugging.
- georgieporgie 15y ago
  Maintenance and robustness matter as well. Hence, readable codebase. Everything else you mention is part of creating value. Code that crashes or breaks regularly does not provide significant value.
_delirium 15y ago
On the topic of what people find interesting on HN, I think that's a bit different discussion than whether elegant code is practical. Not every article on HN is even intended to focus on shipping software or "creating value". Lots of people are interested in computation as a scientific and hackerly topic, and not everything within that sphere has purely utilitarian ends; lots of "here's a clever algorithm" type pieces are just intended to highlight some point of how computation works, not suggest that you implement this algorithm in your shipping product. You might as well demand that every physics article have a section justifying how it increases business value.
TeMPOraL 15y ago
> What matters in software: creating value, shipping product to the end user. What matters to software engineers: just about everything else, for some reason. Because, apart from creating Business Value, some of us actually like the process. It's often the act of building, not the final product, that gets people to become software engineers. So please, cut us some slack here. More fun = motivated (happy) developer = better developer = more business value.
wladimir 15y ago
As a software engineer, I like to work on interesting problems (this includes 'new' paradigms and 'obscure' algorithms), make users happy to feel I'm doing something useful, make sure the code is elegant so I (and fellow programmers) can appreciate it, and will understand it in a few months. The way I see it, creating value is a nice by-product. It may be what pays the bills but it's not the "fun" part, and certainly not the reason I went into programming / software engineering.
pnathan 15y ago
Most software engineers aren't into coding for its own sake. The subset of software engineers who code for the sake of coding frequently obsess over understanding their discipline and stretching their mind.

tikhonj 15y ago

Maintenance and robustness matter as well. You not only need to deliver a product, but you need to ensure that it does what it's supposed to as much as possible, and fix it if it breaks. Most products--particularly successful ones--take a lot more effort to maintain (both in fixing bugs and adding features long after the initial release) than to publish. You want to minimize the amount of effort needed to add features or fix bugs; a good way to do this is to have shorter, more elegant code. Additionally, plenty of fields require very robust code. If all you do is share pictures of cats a server held together by Perl and prayer is more than good enough. If you're investing large sums of money based on computer models, you better not have any errors. There is a reason why banks are some of the main users of Haskell. So: releasing is only part of the game. In certain cases valuing a faster turn-around is more important than code quality; in others, the cost of maintaining a poor code base far outlives the advantage of releasing early. However, there is another problem with this article: elegant code and "focusing on the application" are not mutually exclusive. If anything, writing elegant code will probably save you time, let you reuse more code and spend less time debugging.

georgieporgie 15y ago
Maintenance and robustness matter as well. Hence, readable codebase. Everything else you mention is part of creating value. Code that crashes or breaks regularly does not provide significant value.

_delirium 15y ago

On the topic of what people find interesting on HN, I think that's a bit different discussion than whether elegant code is practical. Not every article on HN is even intended to focus on shipping software or "creating value". Lots of people are interested in computation as a scientific and hackerly topic, and not everything within that sphere has purely utilitarian ends; lots of "here's a clever algorithm" type pieces are just intended to highlight some point of how computation works, not suggest that you implement this algorithm in your shipping product. You might as well demand that every physics article have a section justifying how it increases business value.

TeMPOraL 15y ago

> What matters in software: creating value, shipping product to the end user. What matters to software engineers: just about everything else, for some reason. Because, apart from creating Business Value, some of us actually like the process. It's often the act of building, not the final product, that gets people to become software engineers. So please, cut us some slack here. More fun = motivated (happy) developer = better developer = more business value.

wladimir 15y ago

As a software engineer, I like to work on interesting problems (this includes 'new' paradigms and 'obscure' algorithms), make users happy to feel I'm doing something useful, make sure the code is elegant so I (and fellow programmers) can appreciate it, and will understand it in a few months. The way I see it, creating value is a nice by-product. It may be what pays the bills but it's not the "fun" part, and certainly not the reason I went into programming / software engineering.

pnathan 15y ago

Most software engineers aren't into coding for its own sake. The subset of software engineers who code for the sake of coding frequently obsess over understanding their discipline and stretching their mind.