I'm not sure how to feel about this. In 1995 I was hacking scripting languages and MySQL... and that's what I'm doing in 2010. Hardly anything of substance has changed.
The one thing that's different is my attitude.
Sometimes I feel that I know too much about programming to be employable as a programmer any more. So much of our industry is about foolish waste. Half of all projects fail. Most of the other ones are rotten ideas that make life worse for everyone. Few managers (or markets) really have the patience to build good software, or the maturity to listen to advice about what might be better.
When I was in my 20s, I was dumb enough to commit crazy overtime hours to making projects work, even if they were ultimately doomed and stupid. And this served me well in the job market.
In this environment, experience may not be an asset. It seems to me that the ideal programmer, in an economic sense, is someone who obediently writes unmaintainable code quickly and is unaware of the future pain they are creating for themselves and their customers, or is unaware that all their work is likely to be forgotten in a few months.
> In 1995 I was hacking scripting languages and MySQL... and that's what I'm doing in 2010
I think that's the problem (I'm also not a technology bigot: you can do s/scripting languages/J2EE/ and s/MySQL/Oracle/). Doing simple things may pay well at some point, but there's no technical career growth path.
There's also no security: there's no experience/education/intelligence based barrier to entry. In the end, there's nothing to differentiate a 40 year old CRUD-screen developer from an 18 year old one. You can't say the same thing about a (for the education/domain knowledge angle) search relevance expert or kernel hacker.
For what it's worth, personally, I'm doing a lot more than simple CRUD. I'm lucky enough to have worked at larger and larger scale with every job. And the latest contract is actually kind of nifty. I picked it specifically because it has a sort of lasting impact, and the code will be open source and of use to other projects.
That said, 90% of the jobs out there do seem as futile as I described.
And is anybody making their living doing CRUD from scratch any more? I mean, not counting corporate Java programmers? (rimshot)
> For what it's worth, personally, I'm doing a lot more than simple CRUD. I'm lucky enough to have worked at larger and larger scale with every job.
Then wouldn't this invalidate your comment about doing nothing different between 1995 and 2010?
> And is anybody making their living doing CRUD from scratch any more? I mean, not counting corporate Java programmers? (rimshot)
Plenty do, I know lots taking high pay contracts doing nothing but CRUD. Many start-ups exist that do nothing beyond CRUD in PHP.
I have nothing against scripting languages (I tried to make it clear by including J2EE/Oracle in the same category as LAMP). For when you have to do CRUD, at least for webapps, scripting languages are many times less painful than Java and C++. The "Hello World" Chapter in the Hibernate book is sixty pages, compare it with Perldoc for DBIx::Class (http://search.cpan.org/dist/DBIx-Class/lib/DBIx/Class.pm). Not to mention Hibernate is actually considered "light weight" compared to EJB and other enterprisey technologies (which luckily I've never been exposed to).
"... I think that's the problem (I'm also not a technology bigot: you can do s/scripting languages/J2EE/ and s/MySQL/Oracle/). Doing simple things may pay well at some point, but there's no technical career growth path. ..."
Intelligent comment. Does it break down when you do startups? In all the products I've worked on you start off doing simple CRUD but pretty quickly move into doing other deeper things.
I think what he means is if you just stay withing doing simple CRUD. I think the vast majority of programmers do CRUD or slap GUIs on other people's code as a way to start (I know there are exceptions, but they are exceptions).
What differentiates those that grow from those that don't is whether they go deeper or just keep doing more CRUD and more GUIs on other people's deeper code.
CRUD is actually just what were called 'expert systems' in the 80s. Once you realize that, you can see that it is actually the most interesting type code.
The real problem with programmers is that they don't specialize in a specific type of application and become domain experts in it. Choose a field, such accounting, or hr, or finance, and become an expert in it throughout your career, so that you develop the most featureful CRUD application of that type in the fastest time (or base a startup around it).
Knowing java, php, sql, etc. is like an accountant claiming he just knows bookkeeping. A really valuable accountant is someone who might be a specialist in taxes for medium sized manufacturing firms in california for example.
"CRUD is actually just what were called 'expert systems' in the 80s."
No. CRUD was a programming style that arose from relational database technology. CRUD = (Create, Read, Update, Delete) corresponds to the SQL CREATE, SELECT, UPDATE, DELETE statements. CRUD was popularized by Oracle. For example, Oracle's program generators IIRC used the acronym CRUD as part of their program generator's specification.
"Expert systems" in contrast, were a specific outgrowth of AI technology in the 70's and '80's and were defined loosely as systems that mimicked human expertise.
There is no necessary conceptual overlap in the two terms.
That's a simplistic unerstanding that ignores the actual technology. Expert systems were nothing more than logic programming dressed up to seem all "ai". Prolog is backward chaining, while Clips expert system shell is forward chaining. Today they are referred to as business rules engines, which can again be forward and backward chaining.
Sql databases are also in fact logic programming, basically prolog without recursion and iteration, but instead have pl-sql and t-sql to make them turing complete. Also, with triggers they are also forward chaining too.
The main difference between crud and expert system is essentially that crud is multiuser and everchanging, and so is actually a better version of classical expert systems.
I'd disagree; the modern day equivalent to expert systems would be ersatz "Semantic Web" (the idea of intelligent Internet applications; including, but not limited to RDF/OWL/Reasoners and/or "business logic" engines such as JBoss Drools).
My comment above explains why sql is pretty much the same as logic programming and business rule engines. The semantic web is just a way of saying that everyone should be using a "universal database schema", and once you think of it in those terms is a pretty silly idea - there isn't a remote chance that will happen.
There is a time and a place for one-off throwaway code, and also for extremely fault-tolerant provably correct code. Most stuff falls somewhere in between.
If you are experienced you can determine what is necessary and make good recommendations accordingly. If you are good at what you do, you should be able to get a job working with other people who are good enough at what they do to listen to you.
Maybe you'll be involved with a few projects that fail for various reasons, but I think it's possible to navigate the morass of failure and come out with a good track record at the end. Your production code may not last a long time, but if it served its purpose at the time then you should be proud.
The one thing that's different is my attitude.
Sometimes I feel that I know too much about programming to be employable as a programmer any more. So much of our industry is about foolish waste. Half of all projects fail. Most of the other ones are rotten ideas that make life worse for everyone. Few managers (or markets) really have the patience to build good software, or the maturity to listen to advice about what might be better.
When I was in my 20s, I was dumb enough to commit crazy overtime hours to making projects work, even if they were ultimately doomed and stupid. And this served me well in the job market.
In this environment, experience may not be an asset. It seems to me that the ideal programmer, in an economic sense, is someone who obediently writes unmaintainable code quickly and is unaware of the future pain they are creating for themselves and their customers, or is unaware that all their work is likely to be forgotten in a few months.