4 ms·

I worked somewhere with a similar brilliant framework. It was so much easier, etc., etc. Similar sort of genius auto-loading thing. XML/XSLT. Could slap stuff t

I worked somewhere with a similar brilliant framework. It was so much easier, etc., etc. Similar sort of genius auto-loading thing. XML/XSLT. Could slap stuff together fast. I could make those XSLTs sing man. I made a pivot table out of XSLT, no shit. It was amazingly fast compared to the IE7 javascript engine. Orders of magnitude on masses of data, it actually was amazing. Know how many times Ive used my crazy mad XSLT skills since? Never. In reality, your framework sucked. Just like ours did. The lack of just being able to google stuff slowed everyone down massively. The lack of extensive code examples slowed everything down. Doing the easy stuff was amazingly fast. Want to do something creative or complicated? NO!! That custom framework held back the talented programmers in so many ways. And because every problem was novel and usually caused by some restriction in the framework you learnt solutions and patterns that you never, ever used again. And when they left your company, those talented developers suddenly found themselves 3-5 years behind people who would previously have been their equal. They had effectively learnt a completely useless programming language.

jamesbritt 13y ago
In reality, your framework sucked. Just like ours did. The lack of just being able to google stuff slowed everyone down massively. The lack of extensive code examples slowed everything down. Doing the easy stuff was amazingly fast. Want to do something creative or complicated? NO!! That custom framework held back the talented programmers in so many ways. Well, at the time it was alta-vista not google we turned to. :) The code was pretty straight-forward Java (about the most clever thing was use of forName and assorted reflection), so finding stuff was not a problem. We had many examples; examples as part of the rather good documentation was important for us. We tried to avoid doing anything complicated. That was part of the point. Negative lines of code was a win. It was easier to work with and figure out and extend than the alternatives at the time, and arguably still cleaner and more light-weight then what came after. When the time came to move to some standard Java thing is was no easier (and often harder) to find decent examples or docs. And because every problem was novel and usually caused by some restriction in the framework you learnt solutions and patterns that you never, ever used again. No, not at all. I really don't get this broad dismissal of all in-house frameworks. Is it so far-fetched to think that a small group of smart developers with business domain knowledge can build fast, lean, code? Maybe I was just lucky to have experienced this, but I don't think it's so rare. The code was good, clean, Java. We ran into some issues because of garbage collection (we were really pushing things for speed and memory) for some related code but roadblocks due to our basic tools were rare. Somehow we avoided over-engineering stuff. It actually worked, and worked well. And when they left your company, those talented developers suddenly found themselves 3-5 years behind people who would previously have been their equal. They had effectively learnt a completely useless programming language. Again, no, not at all. They had little trouble picking up EJBs or whatever was the Java-du-jour, if they needed, but unlike devs who only knew how to piece together beans and JSPs (basically plug-and-play coders) they knew how to handle things when stuff didn't work as expected or as the docs insisted. They could actually program because they actually knew the language. Contrast this to people who learn, say, only Rails, and Rails conventions, and write very little custom Ruby code. They're at the mercy of the framework because they're married to a particular tool rather then being immersed in the underlying language. Ideally if one picks a framework one should also really learn the underlying language, but given a choice in hiring I'll go with the one who knows the language over one who knows a framework. Perhaps not every case of using your own custom tools, well-designed for the task at hand, is the same, or does not work out well for every type of programmer. I have worked places where they used poorly-conceived in-house tools, and it was not good. But that's not the case everyplace, and a business can get a competitive advantage using tools streamlined for their domain.
- i_s 13y ago
  To back you up: Backbone and Rails are two examples of popular frameworks that grew out of in-house frameworks. So no, it is not far fetched at all to to think "that a small group of smart developers with business domain knowledge can build fast, lean, code".
  - spikels 13y ago
    Exactly right! Same with PHP (originally "Personal Home Page" scripts for an talented individual) and Djanjo (two talented hackers at small newspaper). Most of today's popular web framework had humble beginnings while many of those promoted by big tech companies have fallen by the wayside. http://www.php.net/manual/en/history.php.php http://www.php.net/manual/en/history.php.php http://en.wikipedia.org/wiki/Django_(web_framework)#History http://en.wikipedia.org/wiki/Django_(web_framework)#History
  - jamesbritt 13y ago
    Makes me wonder how many other good frameworks there are out there they just never get released for one reason or another. I've had people tell me about in-house tools they use, and some sound quite good. One reason some companies do not release their source is because part of their business is in the licensing of the code. If a client could just take it and have others work on it because it was fundamentally OSS they'd lose that.
nostrademons 13y ago
The same applies to people who learned EJBs and J2EE in 2002 too, right? I remember doing Java web development circa 2006 and the new hotness in the Java world was JSF and Spring. And anyways, Java web development was dying then and all the cool kids were moving to RoR and Django. I remember arguing vociferously against the choice of JSF in my company and advocating for Rails; I finally quit in 2007, and the CEO called me up in 2009 and saying "Yeah, we made a mistake. Where should we go now?" They finally went out of business around 2011. I think the lesson is that tech is a harsh industry to be in regardless of which tech you choose, and you should count on your skillset being obsolete in 3-5 years regardless. And your goal should be to learn the latest and greatest as quickly as possible, grab all the riches and other goodies around you while you can, and bank them for the lean years when the industry completely shifts around you and you have to learn something else.
- jamesbritt 13y ago
  I think the lesson is that tech is a harsh industry to be in regardless of which tech you choose, and you should count on your skillset being obsolete in 3-5 years regardless. Also key is to not let what you're told to do at work decide what you're going to learn. Even if your current company is using whatever is the latest and hottest framework you need to be learning other languages, other ways of doing things. Here's an anecdote: I did some consulting work for an Indian-owned company in the US. I was helping out with some Rails stuff. It was a curious case of out-sourcing reversal. They had a hard time finding devs in India to do Rails because those developers felt that Java and EJB would be better for their resumes so that was the work they went for.
coldtea 13y ago
>In reality, your framework sucked. Just like ours did. The lack of just being able to google stuff slowed everyone down massively. The lack of extensive code examples slowed everything down. Doing the easy stuff was amazingly fast. Want to do something creative or complicated? NO!! That custom framework held back the talented programmers in so many ways. No, that's like your experience man. Mine has been different, and I've worked with stuff from Portlets, Struts and Webwork (remember those?) to Django and Express.js
jheriko 13y ago
> And when they left your company, those talented developers suddenly found themselves 3-5 years behind people who would previously have been their equal. Domain specific knowledge doesn't cause this. If you are limited by how much of it you have or don't have then you have a long way to come as a programmer... having used a language or framework before is only really useful so that you don't get snagged by gotchas or weird and wonderful eccentricities of the framework or language. In reality getting employed is more difficult without experience on a CV, but if you are intelligent and can get an interview its not usually a problem - smart people know, or can be taught quickly, the lack of value specific experience has in most contexts (i.e. anything where you aren't just urgently crunching something out of the door). :)

jamesbritt 13y ago

In reality, your framework sucked. Just like ours did. The lack of just being able to google stuff slowed everyone down massively. The lack of extensive code examples slowed everything down. Doing the easy stuff was amazingly fast. Want to do something creative or complicated? NO!! That custom framework held back the talented programmers in so many ways. Well, at the time it was alta-vista not google we turned to. :) The code was pretty straight-forward Java (about the most clever thing was use of forName and assorted reflection), so finding stuff was not a problem. We had many examples; examples as part of the rather good documentation was important for us. We tried to avoid doing anything complicated. That was part of the point. Negative lines of code was a win. It was easier to work with and figure out and extend than the alternatives at the time, and arguably still cleaner and more light-weight then what came after. When the time came to move to some standard Java thing is was no easier (and often harder) to find decent examples or docs. And because every problem was novel and usually caused by some restriction in the framework you learnt solutions and patterns that you never, ever used again. No, not at all. I really don't get this broad dismissal of all in-house frameworks. Is it so far-fetched to think that a small group of smart developers with business domain knowledge can build fast, lean, code? Maybe I was just lucky to have experienced this, but I don't think it's so rare. The code was good, clean, Java. We ran into some issues because of garbage collection (we were really pushing things for speed and memory) for some related code but roadblocks due to our basic tools were rare. Somehow we avoided over-engineering stuff. It actually worked, and worked well. And when they left your company, those talented developers suddenly found themselves 3-5 years behind people who would previously have been their equal. They had effectively learnt a completely useless programming language. Again, no, not at all. They had little trouble picking up EJBs or whatever was the Java-du-jour, if they needed, but unlike devs who only knew how to piece together beans and JSPs (basically plug-and-play coders) they knew how to handle things when stuff didn't work as expected or as the docs insisted. They could actually program because they actually knew the language. Contrast this to people who learn, say, only Rails, and Rails conventions, and write very little custom Ruby code. They're at the mercy of the framework because they're married to a particular tool rather then being immersed in the underlying language. Ideally if one picks a framework one should also really learn the underlying language, but given a choice in hiring I'll go with the one who knows the language over one who knows a framework. Perhaps not every case of using your own custom tools, well-designed for the task at hand, is the same, or does not work out well for every type of programmer. I have worked places where they used poorly-conceived in-house tools, and it was not good. But that's not the case everyplace, and a business can get a competitive advantage using tools streamlined for their domain.

i_s 13y ago
To back you up: Backbone and Rails are two examples of popular frameworks that grew out of in-house frameworks. So no, it is not far fetched at all to to think "that a small group of smart developers with business domain knowledge can build fast, lean, code".
- spikels 13y ago
  Exactly right! Same with PHP (originally "Personal Home Page" scripts for an talented individual) and Djanjo (two talented hackers at small newspaper). Most of today's popular web framework had humble beginnings while many of those promoted by big tech companies have fallen by the wayside. http://www.php.net/manual/en/history.php.php http://www.php.net/manual/en/history.php.php http://en.wikipedia.org/wiki/Django_(web_framework)#History http://en.wikipedia.org/wiki/Django_(web_framework)#History
- jamesbritt 13y ago
  Makes me wonder how many other good frameworks there are out there they just never get released for one reason or another. I've had people tell me about in-house tools they use, and some sound quite good. One reason some companies do not release their source is because part of their business is in the licensing of the code. If a client could just take it and have others work on it because it was fundamentally OSS they'd lose that.

nostrademons 13y ago

The same applies to people who learned EJBs and J2EE in 2002 too, right? I remember doing Java web development circa 2006 and the new hotness in the Java world was JSF and Spring. And anyways, Java web development was dying then and all the cool kids were moving to RoR and Django. I remember arguing vociferously against the choice of JSF in my company and advocating for Rails; I finally quit in 2007, and the CEO called me up in 2009 and saying "Yeah, we made a mistake. Where should we go now?" They finally went out of business around 2011. I think the lesson is that tech is a harsh industry to be in regardless of which tech you choose, and you should count on your skillset being obsolete in 3-5 years regardless. And your goal should be to learn the latest and greatest as quickly as possible, grab all the riches and other goodies around you while you can, and bank them for the lean years when the industry completely shifts around you and you have to learn something else.

jamesbritt 13y ago
I think the lesson is that tech is a harsh industry to be in regardless of which tech you choose, and you should count on your skillset being obsolete in 3-5 years regardless. Also key is to not let what you're told to do at work decide what you're going to learn. Even if your current company is using whatever is the latest and hottest framework you need to be learning other languages, other ways of doing things. Here's an anecdote: I did some consulting work for an Indian-owned company in the US. I was helping out with some Rails stuff. It was a curious case of out-sourcing reversal. They had a hard time finding devs in India to do Rails because those developers felt that Java and EJB would be better for their resumes so that was the work they went for.

coldtea 13y ago

>In reality, your framework sucked. Just like ours did. The lack of just being able to google stuff slowed everyone down massively. The lack of extensive code examples slowed everything down. Doing the easy stuff was amazingly fast. Want to do something creative or complicated? NO!! That custom framework held back the talented programmers in so many ways. No, that's like your experience man. Mine has been different, and I've worked with stuff from Portlets, Struts and Webwork (remember those?) to Django and Express.js

jheriko 13y ago

> And when they left your company, those talented developers suddenly found themselves 3-5 years behind people who would previously have been their equal. Domain specific knowledge doesn't cause this. If you are limited by how much of it you have or don't have then you have a long way to come as a programmer... having used a language or framework before is only really useful so that you don't get snagged by gotchas or weird and wonderful eccentricities of the framework or language. In reality getting employed is more difficult without experience on a CV, but if you are intelligent and can get an interview its not usually a problem - smart people know, or can be taught quickly, the lack of value specific experience has in most contexts (i.e. anything where you aren't just urgently crunching something out of the door). :)