Writing a piece of software is compared to building a skyscraper, constructing the Panama canal, designing a real bridge that alive people use, designing a house, a vacuum cleaner, the actual biological process of evolution, and painting a picture. Hackernews seems to think that civil engineers still design infrastructure with drafting tables and pencils. – N-gate
Programming is far from being a craft. Reinvention is fundamentally anathema to craftsmanship, for quality has to build up in layers of skill over time. In programming though, it’s not just the code we write that is constantly being throw away, it’s the entire toolkit. Programming languages ebb and flow in popularity, models and frameworks appear and disappear. Three whole new programming paradigms will be in vogue in the time it takes an organ maker to construct one instrument. Nothing in this field is timeless.
It’s still a craft. It’s just not as old. Organ makers have a tradition going back centuries, as he says. Those centuries are not static. The present is an outcome of centuries of experimentation. Why deny the same experimentation to programming?
I’d actually argue that the problem is too little experimentation. Today we stigmatize forking (using words like “fragmentation”) and so cut out a lot of the experimentation that has happened in houses, bridges and organs. It’s going to make convergence less efficient.
Is the pace of software development really that break-neck? My day job is front end web dev, which seems to be what people complain about the most, and in the last 5 years the only real piece of learning I had to do was setting aside a few days to pick up react. Sure testing frameworks, build tools, loading/bundling/compression strategies have come and gone but it’s not like the changes have really brought anything new at the API level that I needed to worry about as a working programmer.
And despite popular opinion, web development isn’t the world. I can think of at least two programming languages I use that my parents would have used at the start of their careers. The average book on computer science or software development book on my bookshelf is older than me, as is much of the software I use on a daily basis (counting from initial release).
I think a lot of people work themselves into a frenzy over the continuous stream of new software tools/practices/whatever they see on HN or lobsters or wherever when the reality is the amount of “keeping up to date” you really have to do is pretty minimal.
Comparing programming to, say, woodworking (another interest of mine, although I do very little woodworking). Comparing the “state of the art” wood working tools from 50 years ago to today, there’s not much that is new. About the only thing I can think of that a woodworker from the late 60s wouldn’t believe are the CNC machines readily available. Even a woodworker from the 1700s would find the motorized tools familiar (if not outright wonderous, but there are hand versions of nearly everything one can find in a modernized wood working shop).
Meanwhile, the “state of the art” computers from the late 60s and today are incomparable. We went from single digit MHz clock rates to single digit GHz clock rates (a thousand fold increase), from memory counted in single digit kilobytes to double digit gigabytes (nearly a hundred thousand increase) and disk storage from possibly triple digit kilobytes to single digit terabytes (about a million-fold I think). The approach you take to a program when you have a 4MHz CPU, 64K RAM and 160K disk is vastly different from a 4GHz CPU, 64G of RAM and a terabyte of diskspace (and in come cases, there are programs you can do that would have been impossible back in the day).
I’m looking over the books that are nearby, and let’s see … I see a few CP/M books (good for historical context but little else these days), The Programmer’s Sourcebook for the PC which was maybe even relevant 15 years ago (and today about as useful as the CP/M books). Oh, there are a few books on the Amiga (brings back fond memories of 25 years ago), OS/2 1.0 (again, historically interesting for a potential rival to Unix back in the day) and a book on the VAX architecture (nice but no longer mainstream as it once was).
To some degree, yes, there is very little that is actually new in the computer industry. Over the past 34 years I’ve seen fads come and go and in one way, it’s the same thing all over again but in another way, it is (annoyingly) different. There are things we can do now that we couldn’t do then and in some ways, things have finally slowed down over the past decade (at least hardware wise—computers haven’t gotten significantly faster or even more capable really) but not everything. The only language I learned in college that I still use is C and even that is becoming more and more unpopular as time goes on (the other languages I learned in college were Fortran, Pascal, Lisp, Prolog and Ada; I can count on one finger the number of times I used those languages and still have a finger left over, but I’m not upset at learning them).
I completely disagree. Not only is it a craft, it is one of the earlier areas of programming that allowed for mass-distribution of digital craftsmanship (for example, the entire net-art movement).
I think if you give it time the community will turn front-end programming into a craft. The community around front-end programming definitely doesn’t emphasize craftsmanship like the communities around other subdomains do. It’s way more concerned with trendy tooling and new frameworks. But it’s also relatively young compared to some of those other subdomains. Embedded programming and scientific computing have been a thing since the 60s. Modern front-end programming has really only been a thing since the early 2000s. jQuery came out in 2005. The popular frameworks for server side rendering (CakePHP, Django, Ruby on Rails) all came out in 2005. SPAs didn’t even become a thing until around 2010. The community is still trying to figure out best practices but as far as I can tell it’s done a pretty good job of moving towards a craft based approach. Front-end programming is just relatively easy to get into so there are a lot of newcomers and the ratio of signal to noise on sites like lobsters and hackernews is super low. But you can see a desire to improve quality and consistency in the communities adoption of tooling for static analysis and testing. You can see it in the architectural changes, like the move to component based architectures. And you can see it in the push to be secure by using things like CORS, CSPs, and templating languages that automatically escape programmatic input.
It’s still a craft. It’s just not as old. Organ makers have a tradition going back centuries, as he says. Those centuries are not static. The present is an outcome of centuries of experimentation. Why deny the same experimentation to programming?
I’d actually argue that the problem is too little experimentation. Today we stigmatize forking (using words like “fragmentation”) and so cut out a lot of the experimentation that has happened in houses, bridges and organs. It’s going to make convergence less efficient.
Is the pace of software development really that break-neck? My day job is front end web dev, which seems to be what people complain about the most, and in the last 5 years the only real piece of learning I had to do was setting aside a few days to pick up react. Sure testing frameworks, build tools, loading/bundling/compression strategies have come and gone but it’s not like the changes have really brought anything new at the API level that I needed to worry about as a working programmer.
And despite popular opinion, web development isn’t the world. I can think of at least two programming languages I use that my parents would have used at the start of their careers. The average book on computer science or software development book on my bookshelf is older than me, as is much of the software I use on a daily basis (counting from initial release).
I think a lot of people work themselves into a frenzy over the continuous stream of new software tools/practices/whatever they see on HN or lobsters or wherever when the reality is the amount of “keeping up to date” you really have to do is pretty minimal.
Comparing programming to, say, woodworking (another interest of mine, although I do very little woodworking). Comparing the “state of the art” wood working tools from 50 years ago to today, there’s not much that is new. About the only thing I can think of that a woodworker from the late 60s wouldn’t believe are the CNC machines readily available. Even a woodworker from the 1700s would find the motorized tools familiar (if not outright wonderous, but there are hand versions of nearly everything one can find in a modernized wood working shop).
Meanwhile, the “state of the art” computers from the late 60s and today are incomparable. We went from single digit MHz clock rates to single digit GHz clock rates (a thousand fold increase), from memory counted in single digit kilobytes to double digit gigabytes (nearly a hundred thousand increase) and disk storage from possibly triple digit kilobytes to single digit terabytes (about a million-fold I think). The approach you take to a program when you have a 4MHz CPU, 64K RAM and 160K disk is vastly different from a 4GHz CPU, 64G of RAM and a terabyte of diskspace (and in come cases, there are programs you can do that would have been impossible back in the day).
I’m looking over the books that are nearby, and let’s see … I see a few CP/M books (good for historical context but little else these days), The Programmer’s Sourcebook for the PC which was maybe even relevant 15 years ago (and today about as useful as the CP/M books). Oh, there are a few books on the Amiga (brings back fond memories of 25 years ago), OS/2 1.0 (again, historically interesting for a potential rival to Unix back in the day) and a book on the VAX architecture (nice but no longer mainstream as it once was).
To some degree, yes, there is very little that is actually new in the computer industry. Over the past 34 years I’ve seen fads come and go and in one way, it’s the same thing all over again but in another way, it is (annoyingly) different. There are things we can do now that we couldn’t do then and in some ways, things have finally slowed down over the past decade (at least hardware wise—computers haven’t gotten significantly faster or even more capable really) but not everything. The only language I learned in college that I still use is C and even that is becoming more and more unpopular as time goes on (the other languages I learned in college were Fortran, Pascal, Lisp, Prolog and Ada; I can count on one finger the number of times I used those languages and still have a finger left over, but I’m not upset at learning them).
I think that web front-end programming is not a craft but there are other subdomains that may be.
I completely disagree. Not only is it a craft, it is one of the earlier areas of programming that allowed for mass-distribution of digital craftsmanship (for example, the entire net-art movement).
Dev ops made a dent in it, but system administration is still a cruft. I mean craft.
I think if you give it time the community will turn front-end programming into a craft. The community around front-end programming definitely doesn’t emphasize craftsmanship like the communities around other subdomains do. It’s way more concerned with trendy tooling and new frameworks. But it’s also relatively young compared to some of those other subdomains. Embedded programming and scientific computing have been a thing since the 60s. Modern front-end programming has really only been a thing since the early 2000s. jQuery came out in 2005. The popular frameworks for server side rendering (CakePHP, Django, Ruby on Rails) all came out in 2005. SPAs didn’t even become a thing until around 2010. The community is still trying to figure out best practices but as far as I can tell it’s done a pretty good job of moving towards a craft based approach. Front-end programming is just relatively easy to get into so there are a lot of newcomers and the ratio of signal to noise on sites like lobsters and hackernews is super low. But you can see a desire to improve quality and consistency in the communities adoption of tooling for static analysis and testing. You can see it in the architectural changes, like the move to component based architectures. And you can see it in the push to be secure by using things like CORS, CSPs, and templating languages that automatically escape programmatic input.