5 ms·

No. I disagree with most of this article, and I have ~25 years experience. No, I didn't program mainframes, but I'm tired, as are younger programmers, of even

No. I disagree with most of this article, and I have ~25 years experience. No, I didn't program mainframes, but I'm tired, as are younger programmers, of even older programmers trying to say that the way they did programming is still "better". The writer isn't entirely wrong, but the simple fact is that software isn't written the same way anymore. Stop trying to force antiquated methods down younger people's throats. The way I wrote programs 20 years ago is inherently different from the way that I wrote programs 10 years ago is inherently different from the way I write programs today. 15-20 years ago, we didn't write tests. We had QA that wrote our tests for us. We tested the code as well as we could (I became pretty damn good at testing my own code) and then we threw it over a wall to QA. Today, we have zero QA and I write tests for my own code. 10-15 years ago, you aimed for 0 defects, especially for enterprise code, because your enterprise customers couldn't afford downtime. Today, in a SAAS environment, you care about defects but your have a global set of customers, and you roll your code out slowly and watch metrics. I have a friend in growth at Facebook and his manager got mad at him because he was focusing too much time on testing his own code. Apparently he's supposed to leave that to external QA, and you can always fix the code later. On some growth teams, code quality and maintainability don't matter, all that matters is getting customer growth with new features as quickly as possible. Is that inherently wrong? No, it's a different way of doing business. 10 years ago there was no such thing as a growth team. The way software is used is different, and the way software is developed is different. Mainframe methodologies, while interesting to read, is not relevant. Things like Optimize Upfront is nonsense to me, especially in a global context. You iterate on your features quickly, including optimization. You couldn't do that in mainframe computing, but these days I deploy to production 10 times a day, and depending on how I deploy, I can see problems fairly quickly and iterate without affecting most of my users. That's definitely not a paradigm that you would see back then, when you would have to schedule time, etc.

kristopolous 9y ago
I did do mainframe programming and I do webapps and phone apps these days, so I've kept up. It's gotta be both approaches (yours and the articles) but the real problem is the demand for programmers is so high and the barrier to entry is so low that the quality has suffered; the quality of the libraries, build systems, documentation, designs, interfaces, all of it. You can't magically drag all modern programmers through the mud using line editors and 16 bit processors for 2 years to learn everything the painful way. I honestly don't see a way out. We're in the eternal September of software development and it's all down hill from here unless we make some commitment to raising the barrier to entry and decreasing the incentives, making it hard again.
- z3t4 9y ago
  You can't teach new people one by one, but you can write articles and blog posts, then post them here on HN just like this guy did.
  - kristopolous 9y ago
    it's a skill, not a fact. skills are learned tacitly through experience; such as riding a bicycle. You have to ride to learn. The problem is that everything has changed so much. When I started, compiling took serious time (hours sometimes). So you were much more careful about making mistakes. Compilers also had bugs, as did linkers, debuggers, you had to know how to spot these things and when to question your code and when to question your tools. Operating system containment and protection was more an intention than a reality and it was relatively easy to lock up or crash a machine through faulty code. Workstation uptimes of weeks was seen as impressive. These days, things are so stable that "uptime" just tells me when my last power outage was. When we released software it was on physical media, which was either mailed to people in physical boxes or running on physical machines that were shipped out. Not making mistakes was much more important in that situation since you couldn't just deploy an update without a lot of cost and ceremony. It's all changed so fundamentally; I'd be open to having an instruction course where people have to target some vintage machine (which we'd likely have to virtualize) and have them just deal with it for 6 months. I don't know how many signups you'd get though.
    - user5994461 9y ago
      Software development is still in its infancy. It will slow down eventually and stabilize. The last two decades were a madness of inventions, with computing doubling almost every 3 year, new languages and paradigm invented, new tools, the internet, the web, phones, giant displays, small displays with touch. We surely won't get that much change in the next two decades.
      - pfarnsworth 9y ago
        I believe in the next 2 decades human programmers will be replaced by artificial intelligence.
username223 9y ago
> On some growth teams, code quality and maintainability don't matter, all that matters is getting customer growth with new features as quickly as possible. Is that inherently wrong? Yes. That "growth team" just added a bunch of inscrutable garbage to your code base, perhaps hoping that someone would clean it up later. Of course no one ever will, since they're too busy "getting customer growth with new features as quickly as possible."
- pfarnsworth 9y ago
  My current job is converting a growth project into a sustainable and maintainable service. The code is the worst production code I’ve ever seen in 25 years. I’m shocked it works. Everyone that worked on it was fresh grads and it’s shit code for the most part. But is it inherently wrong? No. It introduced a new feature quickly, a lot more quickly than I ever could. The code i produce is maintainable and relatively bug free but I couldn’t have gotten it up and running as quickly as these kids did. Also the business decided this is what they wanted to do. Invest a low amount of money to see if the feature works and then if it does pass it onto more senior programmers that turn it into a real service. If it doesn’t stick then throw it away. It’s not the best, and I would never employ it but it’s one strategy and works if your care more about growth than efficiency.
lalalandland 9y ago
"On some growth teams, code quality and maintainability don't matter, all that matters is getting customer growth with new features as quickly as possible. " Do you work for Intel ? /s
user5994461 9y ago
Facebook doesn't make money by writing working software. They don't lose money when the software doesn't work as intended. It's a terrible example for reliability.

kristopolous 9y ago

I did do mainframe programming and I do webapps and phone apps these days, so I've kept up. It's gotta be both approaches (yours and the articles) but the real problem is the demand for programmers is so high and the barrier to entry is so low that the quality has suffered; the quality of the libraries, build systems, documentation, designs, interfaces, all of it. You can't magically drag all modern programmers through the mud using line editors and 16 bit processors for 2 years to learn everything the painful way. I honestly don't see a way out. We're in the eternal September of software development and it's all down hill from here unless we make some commitment to raising the barrier to entry and decreasing the incentives, making it hard again.

z3t4 9y ago
You can't teach new people one by one, but you can write articles and blog posts, then post them here on HN just like this guy did.
- kristopolous 9y ago
  it's a skill, not a fact. skills are learned tacitly through experience; such as riding a bicycle. You have to ride to learn. The problem is that everything has changed so much. When I started, compiling took serious time (hours sometimes). So you were much more careful about making mistakes. Compilers also had bugs, as did linkers, debuggers, you had to know how to spot these things and when to question your code and when to question your tools. Operating system containment and protection was more an intention than a reality and it was relatively easy to lock up or crash a machine through faulty code. Workstation uptimes of weeks was seen as impressive. These days, things are so stable that "uptime" just tells me when my last power outage was. When we released software it was on physical media, which was either mailed to people in physical boxes or running on physical machines that were shipped out. Not making mistakes was much more important in that situation since you couldn't just deploy an update without a lot of cost and ceremony. It's all changed so fundamentally; I'd be open to having an instruction course where people have to target some vintage machine (which we'd likely have to virtualize) and have them just deal with it for 6 months. I don't know how many signups you'd get though.
  - user5994461 9y ago
    Software development is still in its infancy. It will slow down eventually and stabilize. The last two decades were a madness of inventions, with computing doubling almost every 3 year, new languages and paradigm invented, new tools, the internet, the web, phones, giant displays, small displays with touch. We surely won't get that much change in the next two decades.
    - pfarnsworth 9y ago
      I believe in the next 2 decades human programmers will be replaced by artificial intelligence.

username223 9y ago

> On some growth teams, code quality and maintainability don't matter, all that matters is getting customer growth with new features as quickly as possible. Is that inherently wrong? Yes. That "growth team" just added a bunch of inscrutable garbage to your code base, perhaps hoping that someone would clean it up later. Of course no one ever will, since they're too busy "getting customer growth with new features as quickly as possible."

pfarnsworth 9y ago
My current job is converting a growth project into a sustainable and maintainable service. The code is the worst production code I’ve ever seen in 25 years. I’m shocked it works. Everyone that worked on it was fresh grads and it’s shit code for the most part. But is it inherently wrong? No. It introduced a new feature quickly, a lot more quickly than I ever could. The code i produce is maintainable and relatively bug free but I couldn’t have gotten it up and running as quickly as these kids did. Also the business decided this is what they wanted to do. Invest a low amount of money to see if the feature works and then if it does pass it onto more senior programmers that turn it into a real service. If it doesn’t stick then throw it away. It’s not the best, and I would never employ it but it’s one strategy and works if your care more about growth than efficiency.

lalalandland 9y ago

"On some growth teams, code quality and maintainability don't matter, all that matters is getting customer growth with new features as quickly as possible. " Do you work for Intel ? /s

user5994461 9y ago

Facebook doesn't make money by writing working software. They don't lose money when the software doesn't work as intended. It's a terrible example for reliability.