4 ms·

Agreed. I would add a second question to your first: What are the risks of implementing this into production? Get them thinking as a matter of habit about bo

Agreed. I would add a second question to your first: What are the risks of implementing this into production? Get them thinking as a matter of habit about both of those in tandem - what's the customer benefit, and what are the risks of doing it, and does the former justify the latter? Also, all programmers have a burning desire to build stuff from scratch, which is part of what's driving yours to incorporate cool new stuff like this at a risk to your revenue. No can do. But it may be worth exploring side or 20% projects specifically dedicated to building stuff from scratch. Get their itch scratched on non-revenue projects that serve as potential useful on-the-job training and tech evaluation, while possibly getting something of value out of it.

watwut 9y ago
The burning desire to build from scratch is simply because it is easier and because it tend to be more verbally valued by management then working on older product which tend to be snarked at as merely maintennance. The moment management praise also people working on less new and gives them appropriate salaries and autonomy, burning desire changes - except in few people who are truly naturally like that. It is win win, because the remaining people tend to be trully better in cutting edge tech problems.
- hinkley 9y ago
  I'm starting to have doubts about this line of reasoning. It just doesn't explain enough of the risky behavior I see. I'm starting to think it might be the same thing that gets young developers to put up with 10+ hour days. That feeling you get when you lose yourself in a problem for hours and hours. Being in a Flow state is seductive. Nobody gets that feeling when looking through the bug database or knowledge base, or hunting through the source of an OSS module trying to figure out how to ask it the right questions. But they do get that feeling when trying to rewrite it themselves. All that open space to run as fast as you can... in the wrong direction. It's thrill seeking. BASE jumping for programmers.
  - harryf 9y ago
    Programming is based on hero worship. Anyone who makes even half an effort to better themselves as a software developer will encounter famous names from the past - those that "made a difference" by creating languages, operating systems and algorithms. Keyword here is "create". This is not an industry that celebrates maintence programmers. There's no glory for the guy that spent 20 years keeping the system that your banking transactions depend upon. So naturally young programmers will see to be the next Richie, Torvalds or Knuth and to do that you gotta create something new. Gotta change the world
    - snaky 9y ago
      There are some wannabe-heroes, but they aren't so widespread. The vast majority is just being pragmatic. Trendy toys and 'designed and implemented new X' in resume looks so much better for career than 'maintained something old so customers were happy'. Of course, there are some technologies that helps to make pretty good money even being ancient, like COBOL, APL, AS/400 and IMS. But for how long? So it seems rational to move forward instead.
      - dsfyu404ed 9y ago
        That said, if you've got COBOL, Fortran, etc on your resume you're pretty much guaranteed to get asked about it in an interview.
        snaky 9y ago
        Maybe discussion on mainframes transaction processing and COBOL features helping to implement it the way we know it thesedays as 'Cloud Functions' or 'AWS Lambda' might be a little bit more fruitful than reversing linked list pointers on a blackboard.
    - cyphar 9y ago
      As a fairly young programmer, I think it's not necessarily hero worship (though that does play a part). I think it's because a lot of young programmers define their identities in terms of what they do. This is especially prevalent in the free software community. If you're going to define yourself by what you work on, it doesn't seem very fulfilling to just keep an existing project running without having the freedom to make drastic changes that would improve the project. It should noted though that the above points about Red Hat and "boring" (as much I hate calling people's work boring) don't sit right with me. I know quite a few people who work at Red Hat on very interesting technologies. At SUSE, I work on fairly interesting technologies as well. The key aspect that makes SUSE (or Red Hat) "boring" is that we have effectively solved the problem of release engineering and maintenance (though in recent years SUSE has been improving on it further through openSUSE Leap and the recent plans for SLE15). The funny thing is that if upstreams could do their own release engineering correctly, SUSE and Red Hat would have a weaker value proposition.
uiri 9y ago
Also, all programmers have a burning desire to build stuff from scratch, I don't think this is true at all. 80%+ of software work is maintenance related. People who have a burning desire for green field development won't last long so they are few and far between. In fact, this is one of the biggest differences between real projects in industry and fake projects in CS undergrad education.

watwut 9y ago

The burning desire to build from scratch is simply because it is easier and because it tend to be more verbally valued by management then working on older product which tend to be snarked at as merely maintennance. The moment management praise also people working on less new and gives them appropriate salaries and autonomy, burning desire changes - except in few people who are truly naturally like that. It is win win, because the remaining people tend to be trully better in cutting edge tech problems.

hinkley 9y ago
I'm starting to have doubts about this line of reasoning. It just doesn't explain enough of the risky behavior I see. I'm starting to think it might be the same thing that gets young developers to put up with 10+ hour days. That feeling you get when you lose yourself in a problem for hours and hours. Being in a Flow state is seductive. Nobody gets that feeling when looking through the bug database or knowledge base, or hunting through the source of an OSS module trying to figure out how to ask it the right questions. But they do get that feeling when trying to rewrite it themselves. All that open space to run as fast as you can... in the wrong direction. It's thrill seeking. BASE jumping for programmers.
- harryf 9y ago
  Programming is based on hero worship. Anyone who makes even half an effort to better themselves as a software developer will encounter famous names from the past - those that "made a difference" by creating languages, operating systems and algorithms. Keyword here is "create". This is not an industry that celebrates maintence programmers. There's no glory for the guy that spent 20 years keeping the system that your banking transactions depend upon. So naturally young programmers will see to be the next Richie, Torvalds or Knuth and to do that you gotta create something new. Gotta change the world
  - snaky 9y ago
    There are some wannabe-heroes, but they aren't so widespread. The vast majority is just being pragmatic. Trendy toys and 'designed and implemented new X' in resume looks so much better for career than 'maintained something old so customers were happy'. Of course, there are some technologies that helps to make pretty good money even being ancient, like COBOL, APL, AS/400 and IMS. But for how long? So it seems rational to move forward instead.
    - dsfyu404ed 9y ago
      That said, if you've got COBOL, Fortran, etc on your resume you're pretty much guaranteed to get asked about it in an interview.
      - snaky 9y ago
        Maybe discussion on mainframes transaction processing and COBOL features helping to implement it the way we know it thesedays as 'Cloud Functions' or 'AWS Lambda' might be a little bit more fruitful than reversing linked list pointers on a blackboard.
  - cyphar 9y ago
    As a fairly young programmer, I think it's not necessarily hero worship (though that does play a part). I think it's because a lot of young programmers define their identities in terms of what they do. This is especially prevalent in the free software community. If you're going to define yourself by what you work on, it doesn't seem very fulfilling to just keep an existing project running without having the freedom to make drastic changes that would improve the project. It should noted though that the above points about Red Hat and "boring" (as much I hate calling people's work boring) don't sit right with me. I know quite a few people who work at Red Hat on very interesting technologies. At SUSE, I work on fairly interesting technologies as well. The key aspect that makes SUSE (or Red Hat) "boring" is that we have effectively solved the problem of release engineering and maintenance (though in recent years SUSE has been improving on it further through openSUSE Leap and the recent plans for SLE15). The funny thing is that if upstreams could do their own release engineering correctly, SUSE and Red Hat would have a weaker value proposition.

uiri 9y ago

Also, all programmers have a burning desire to build stuff from scratch, I don't think this is true at all. 80%+ of software work is maintenance related. People who have a burning desire for green field development won't last long so they are few and far between. In fact, this is one of the biggest differences between real projects in industry and fake projects in CS undergrad education.