5 ms·

Meh, that group of developers didn't really die out. People tend to forget that there's tons of people still worrying about performance. I personally do comput

Meh, that group of developers didn't really die out. People tend to forget that there's tons of people still worrying about performance. I personally do computer graphics in video games. We still worry about every byte, cycle, cache miss, and instruction that we write. We still spend days trying to eek out another 100 microseconds from that tricky piece of code. Not every software developer is a web/business developer. Hacker News tends to forget that.

sdoering 11y ago
Seems to me we oftentimes also forget the "not so outspoken" devs, that just tinker away, doing their thing, without announcing every fart to the world. People doing great work, without putting themselves into the spotlight.
- rodgerd 11y ago
  HN culture doesn't merely forget about them - in fact, it aggressively excludes them. Brilliant assembler programmer who likes to finish up at the end of the day and play with your kids? Fuck you, where's your GitHub profile. Developing novel algorithms and prefer playing guitar at home to drinking at the pub? Fuck you, where's your conference talks. etc, etc, etc. The broader culture of which HN is a microcosm spends a lot of time and effort devising filters to make people invisible if they don't fit a relentlessly self-promoting profile which has a questionable relationship with the quality of their work. I don't see Knuth and Cutler spending a lot of time on Twitter.
  - stdbrouw 11y ago
    We cannot read what does not get written. We cannot discuss the merits and demerits code that is not public. I'm in full agreement that HN is an informational bubble. I'm not so clear on exactly what HN is doing to aggressively exclude people. And where you see exclusion, I see an attempt to encourage people to join the discussion: "hey, why don't you put this up on GitHub so we can take a look", "this would make such a good topic for a conference talk."
  - pjc50 11y ago
    We programmers are in a strange place that almost all of our work is covered by copyright such that it can't be shown to other programmers. People can assess our output, but not look at our code. We can't build a portfolio and take it with us.
collyw 11y ago
I agree. The fact is that I can now build a database and front end as a team of one. Ten years ago that would have needed a team of maybe 5 developers. Abstractions slow things down at the computer level, but bring a great deal of developer productivity. As always its a tradeoff.
_pmf_ 11y ago
> Hacker News tends to forget that. I'm not sure it knew it in the first place. It's particularly entertaining when the web dev crowd chimes in on embedded system topics.
smoyer 11y ago
I spent the first twenty years of my career as an embedded systems engineer and there are two specific advantages I gained from that experience: 1) When your writing code for an underpowered microcontroller, you have a plan before you start. This plan includes execution speed and memory usage targets. 2) When you're sending thousands (hundreds of thousands or millions) of non-reprogramable devices into the field, you have a test plan (and comprehensive test suite) that guarantees correctness and performance. Do you know your "machine"? For instance, if you're working with a language that runs on the JVM have you read the JVM specification? (It's the equivalent of your micorcontroller's data-sheet). The part of this manifesto I agree with is that you should thoroughly understand everything "beneath" your application.
- logicallee 11y ago
  >The part of this manifesto I agree with is that you should thoroughly understand everything "beneath" your application. Say someone (a full-stack developer if you want, or jack-of-all-trades-master-of-none) uses Photoshop and Illustrator but also is coding against Firefox, Chrome, and Safari, and their stack includes node.js, Express, Angular, and PostgreSQL. At some point, you can't thoroughly understand every cycle of every rendering engine. (Which is what what you've stated implies.) It is quite literally impossible - as in, a physical impossibilitiy, of "thoroughly understanding everything 'beneath' your application." You just can't - there are not that many hours in the day. You would have no application left. If you froze technology today you could thoroughly understand all of the mentioned technologies in 10 years. But by then there would be new technologies. Instead, you just have to abstract it away, code against some framework that compiles down to javascript, and only understand that. You can't thoroughly understand every single thing your databse engine is doing either. Otherwise you can just never get anything done. The modern world is made up of applications whose combined reference materials total without exaggeration millions of pages of text. You just can't read a million pages of text. This is completely different from a single microcontroller's architecture. Which is basically a single layer. On the web, even your target is a collection of competing browsers. Why should someone building a front-end site but also using the basics of a database somehow, take months out of his or her life to gain a deep understanding of every cycle of that database engine or what exactly it's doing? What does it get them? Cycles - even billions of cycles - are cheap. It's like asking a farrier[1] (someone who cares for horse's hooves and then puts shoes on them) to learn all the intricacies of metallurgy, really go back to where metal is mined in ores. Oh, and since, "A farrier combines some blacksmith's skills (fabricating, adapting, and adjusting metal shoes) with some veterinarian's skills (knowledge of the anatomy and physiology of the lower limb)" I suppose this farrier suddenly needs to be a complete veterinarian and really fully understand all layers of the horse? It just doesn't work that way. At some point the farrier has to work with an abstraction, and not know what is going on at lower layers, and at some point the full stack developer has to just use an interface that compiles down to javascript that will access a database he or she doesn't know. While you may lament this, beautiful and functional sites have been built this way. It's not fair to ask someone to fully understand everything. Even as a microcontroller coder, you didn't understand the circuitry in the microcontroller at an electrical level - you didn't even get the diagrams. You, too, worked with an abstraction. [1] https://en.wikipedia.org/wiki/Farrier https://en.wikipedia.org/wiki/Farrier
Loic 11y ago
I develop thermodynamic code for the oil & gas industry. I count the number of divisions in my code. Because a division is a really expensive operation if you need to do it billions of time. So yes, there are still a lot of people worrying about performance, but a lot of them are coding in Fortran and this is definitely not sexy. Ok, now we also use CUDA, so this can go through the HN filter ;)

sdoering 11y ago

Seems to me we oftentimes also forget the "not so outspoken" devs, that just tinker away, doing their thing, without announcing every fart to the world. People doing great work, without putting themselves into the spotlight.

rodgerd 11y ago
HN culture doesn't merely forget about them - in fact, it aggressively excludes them. Brilliant assembler programmer who likes to finish up at the end of the day and play with your kids? Fuck you, where's your GitHub profile. Developing novel algorithms and prefer playing guitar at home to drinking at the pub? Fuck you, where's your conference talks. etc, etc, etc. The broader culture of which HN is a microcosm spends a lot of time and effort devising filters to make people invisible if they don't fit a relentlessly self-promoting profile which has a questionable relationship with the quality of their work. I don't see Knuth and Cutler spending a lot of time on Twitter.
- stdbrouw 11y ago
  We cannot read what does not get written. We cannot discuss the merits and demerits code that is not public. I'm in full agreement that HN is an informational bubble. I'm not so clear on exactly what HN is doing to aggressively exclude people. And where you see exclusion, I see an attempt to encourage people to join the discussion: "hey, why don't you put this up on GitHub so we can take a look", "this would make such a good topic for a conference talk."
- pjc50 11y ago
  We programmers are in a strange place that almost all of our work is covered by copyright such that it can't be shown to other programmers. People can assess our output, but not look at our code. We can't build a portfolio and take it with us.

collyw 11y ago

I agree. The fact is that I can now build a database and front end as a team of one. Ten years ago that would have needed a team of maybe 5 developers. Abstractions slow things down at the computer level, but bring a great deal of developer productivity. As always its a tradeoff.

_pmf_ 11y ago

> Hacker News tends to forget that. I'm not sure it knew it in the first place. It's particularly entertaining when the web dev crowd chimes in on embedded system topics.

smoyer 11y ago

I spent the first twenty years of my career as an embedded systems engineer and there are two specific advantages I gained from that experience: 1) When your writing code for an underpowered microcontroller, you have a plan before you start. This plan includes execution speed and memory usage targets. 2) When you're sending thousands (hundreds of thousands or millions) of non-reprogramable devices into the field, you have a test plan (and comprehensive test suite) that guarantees correctness and performance. Do you know your "machine"? For instance, if you're working with a language that runs on the JVM have you read the JVM specification? (It's the equivalent of your micorcontroller's data-sheet). The part of this manifesto I agree with is that you should thoroughly understand everything "beneath" your application.

logicallee 11y ago
>The part of this manifesto I agree with is that you should thoroughly understand everything "beneath" your application. Say someone (a full-stack developer if you want, or jack-of-all-trades-master-of-none) uses Photoshop and Illustrator but also is coding against Firefox, Chrome, and Safari, and their stack includes node.js, Express, Angular, and PostgreSQL. At some point, you can't thoroughly understand every cycle of every rendering engine. (Which is what what you've stated implies.) It is quite literally impossible - as in, a physical impossibilitiy, of "thoroughly understanding everything 'beneath' your application." You just can't - there are not that many hours in the day. You would have no application left. If you froze technology today you could thoroughly understand all of the mentioned technologies in 10 years. But by then there would be new technologies. Instead, you just have to abstract it away, code against some framework that compiles down to javascript, and only understand that. You can't thoroughly understand every single thing your databse engine is doing either. Otherwise you can just never get anything done. The modern world is made up of applications whose combined reference materials total without exaggeration millions of pages of text. You just can't read a million pages of text. This is completely different from a single microcontroller's architecture. Which is basically a single layer. On the web, even your target is a collection of competing browsers. Why should someone building a front-end site but also using the basics of a database somehow, take months out of his or her life to gain a deep understanding of every cycle of that database engine or what exactly it's doing? What does it get them? Cycles - even billions of cycles - are cheap. It's like asking a farrier[1] (someone who cares for horse's hooves and then puts shoes on them) to learn all the intricacies of metallurgy, really go back to where metal is mined in ores. Oh, and since, "A farrier combines some blacksmith's skills (fabricating, adapting, and adjusting metal shoes) with some veterinarian's skills (knowledge of the anatomy and physiology of the lower limb)" I suppose this farrier suddenly needs to be a complete veterinarian and really fully understand all layers of the horse? It just doesn't work that way. At some point the farrier has to work with an abstraction, and not know what is going on at lower layers, and at some point the full stack developer has to just use an interface that compiles down to javascript that will access a database he or she doesn't know. While you may lament this, beautiful and functional sites have been built this way. It's not fair to ask someone to fully understand everything. Even as a microcontroller coder, you didn't understand the circuitry in the microcontroller at an electrical level - you didn't even get the diagrams. You, too, worked with an abstraction. [1] https://en.wikipedia.org/wiki/Farrier https://en.wikipedia.org/wiki/Farrier

Loic 11y ago

I develop thermodynamic code for the oil & gas industry. I count the number of divisions in my code. Because a division is a really expensive operation if you need to do it billions of time. So yes, there are still a lot of people worrying about performance, but a lot of them are coding in Fortran and this is definitely not sexy. Ok, now we also use CUDA, so this can go through the HN filter ;)