What I mean is more like when I've made a change to some OSS code I'm using for my own projects, I frequently offer changes to the author to use. I don't expect to get anything from it, like they are going to offer me a job working on it, it's just what I feel is the honourable thing to do.
The problem is that most pop stars don't have the ability to do that. It's largely a result of how much more sophisticated the industry is about marketing. It's sad really.
Where once, artists rose because of live performance on the basis of talent (and I include the talent to sell records - it's always been an industry), the marketing is about things like image and the artists being known commodities who can generate column inches at the point they are signed. Image is not the same thing as presence, though.
Technology has also played a part. Vocal performances can be tuned and stars can be airbrushed.
The pop star's musical talent or charisma is almost irrelevant. The most important parts to selling a pop song now are the songwriting, image, production and marketing campaign. The pop songs that are good are mostly because of good songwriting and production (like Toxic).
The problem is that once the star puts on a few pounds, and after the media are bored with their various scandals that sell magazines, there's nothing left. They rarely have singing voices of either beauty or distinction. They can't write songs. They can't play. It's time to then bring on another new pop star.
A lot of pop stars in the past "grew up". Madonna has changed and experimented. George Michael is respected as a songwriter. I don't see Britney or Justin Timberlake doing likewise.
I was a COBOL programmer for years doing business apps. The company I was in was using C++ for PC apps.
I spoke to the C++ guys one day about learning it, and they lent me a book. I got to the part about pointers and put the book down.
When building business applications, you want to be as close to expressing logic as possible, with nothing else getting in the way. You want the minimum amount of code you can do to express this logic, as anything that you write needs to be tested, raising costs.
.net apps don't have memory leaks, because it's taken care of for you. You don't have to pass pointers, it's done for you. All of this improves costs where it matters - in the cost of people.
I write business applications for clients, and I want to build things as cheaply, quickly and reliably as I can (and be cheaply maintainable). If someone gives me this, then I'll take it.
A lot of people bad mouth MS Access as a "toy", but for small data-centric system development, there's not much better. Is it a great performer? Can it make coffee and dance the jitterbug? Does it scale? The answer to all of these is no, but then the requirements didn't need any of these. We needed something that could be built fast, on a small budget and would be disposed of within 18 months. I could express all the business logic I needed to with it.
Programming is getting easier as machines get faster, and not only that, it means that the tools will get closer to the business.
A friend of mine said to me some years ago that he was thinking of learning C++ and I advised him not to bother, because C++ would be the preserve of driver and OS developers. I know that someone's going to say "We build our core apps in C++" but there really isn't much out there. People want higher level stuff like.net, java and PHP.
The thing is, this abstraction will continue to rise. Ruby on Rails give some insight into where this will go. I think that web tools will become more data-centric and less hand-coded. Understanding the business needs, and managing the soft stuff well is getting more important.
You know the first time I heard the expression "warm body syndrome"? In the early 1990s, over a beer with a co-worker discussing how difficult switching jobs was now that we'd gone past that stage.
As budgets got cut, less projects got done and managers focussed on the best people. Then, as the economy improved, managers got bigger budgets, more dumb projects were being done, which meant more warm bodies arriving.
I have a problem with GUI designers, in that they give the perception of creating large productivity improvements. When, in my experience, the GUI part of an application is one of the most static parts of the application. Most code changes in a complex application are the back end. In addition, GUI designers aren't good if you are trying to build an interface that is OO, and by definition, the controls are created at the time you run (and the IDE can discourage developers from thinking in those terms).
You're running an ASP application, and you like the look of ASP.NET. So, what you think would be good would be to write some new forms in ASP.NET as part of an eventual transition.
Only problem is, sessions in ASP and ASP.NET are incompatible. The company that wrote both couldn't be bothered to make them interwork. So, you either have to rewrite your ASP, or use an ugly kludge that stores your session details in a database (meaning changing your existing ASP to allow this to happen).
The other thing is to do lots of small work for lots of clients.
The freelance market in the UK is not as good as 7 or 8 years ago because no-one builds large projects here. But small projects still have a market, because the communication and management overhead with other countries are larger.
It's also fair to say that doing small jobs means you can't just be a coder. You have to get into the project management, analysis, design and all that too.
I work freelance, so I get to talk to them frequently.
A few have some idea of client needs, and actually spend time talking to them about it. Most just get an email of requirements, put it out and keyword match.
I've had agencies tell me that I couldn't be put forward for a contract because I had a skill with currentversion-1, where the differences between currentversion and currentversion-1 were almost indistinguishable AND that you know the company are unlikely to be using any features that were added since currentversion-3.
I'm probably going to do some IronPython because it's the best looking option for doing Windows forms, from what I can see (at least until Firefox XUL starts supporting Python). However, I'm going to make sure that any interaction with.net has an additional layer to ensure that I can easily port it.
The other thing is, that following the money in anything is generally a really bad idea. Surveys like this will have thousands of guys looking at.net, simply for the money. I've seen it with a few skills - something pays phenomenally well, so loads of people try and switch to it, resulting in a market adjustment, and it pays little better than where they were before. Of course, if your skills are completely dying out, you might want to consider switching.
Personally, I believe in "do what you like doing, do what you think has a future". If you like coding in Python, you'll be more productive in it than a language you dislike. You'll more likely achieve expertise than a language you dislike, and people will keep asking for you back. But consider that your favourite obscure language (mine's a mainframe 4GL I used 10 years ago;) ) may not have a future.
I'm considering building new things (particularly for my own consumption) in Python and not.net. Not out of philosophical reasons, but for business reasons.
The key reason for me is the value of my investment. I know companies running COBOL mainframe apps with a 20 year lifespan. It's being modified, but due to the non-decaying nature of code, that investment keeps giving a better return year on year, and each year in service, bugs are detected and destroyed.
VB6 is being killed off. Support has already finished. So, what happened to what you built 5 years ago in VB6? You've got to convert it (which doesn't work too well) or rewrite it. How long until c# or asp.net get killed off for Microsoft's next big thing, and all your team have to go through another pointless set of learning to deliver nothing to your business?
When I was 17, I worked for a factory that made shoe soles. They wanted a small production control system writing, and they didn't have much money, so approached the local college.
The coding had to be done on a computer which was kept in the same room as the coffee area. People walking in and making coffees wasn't the worst thing.
The worst thing would have been the machine used for testing the strength of the compounds. Kept away from the factory for being too noisy. How do you test the strength of the compounds? You make a stiletto heel and put it in a special machine that hits it repeatedly with a hammer until it breaks, at which point the counter stops. Imagine trying to code with that going on?
If you are doing OSS for direct financial reward, you'll be disappointed.
There are some complex reasons for doing it (like getting others using your code can give you feedback, bug finding, or because you are charitable, or to raise your profile).
It seemed to me that the X-Prize, whilst giving some compensation was only a fraction of the amounts spent. I think the money helped to create publicity and make it look worthwhile.
I don't quite agree with your distinction. In my experience the pro developers are just interested in a different problem space.
The people I like to work with aren't those who will spend time tuning an overnight print process from 3 hours to 10 minutes, they are the people who prefer spending time dealing with understanding the business needs. They don't really like coding, beyond what it can do for them.
The need for "hackers" in business development is diminishing. C++ coding skills are diminishing in demand. For many companies, the speed of code is getting to the point of being irrelevant, beyond network and database IO. The mainframe departments I know have less than 5% hackers to developers, because they're not required. This trend will happen to PC/web departments.
I am a computer programmer. I make computing devices do what I want. I will use any tool at my disposal, to hell with my employer's proposed "beneficial" restrictions.
Sounds like you are lucky to work in an ill-disciplined company. I've ran a programming team, and you'd be starting down the road to getting fired if you did that with me, or most managers I've known.
I spent a year fixing code in a company where all sorts of not just languages, but different libraries used (which did the same thing) even in the same program. Programmers just did things in certain ways because they'd never tried them before, or to put something on their CV.
... and then what happens if you then want to put some of the functionality that you wrote in your flat text reader into your web service (for example)?
Multiple languages in your example are only justifiable if I know that the file processing in our key language could not meet the business requirement (like it was overnight processing and would take 20 hours in our key language and 2 hours in an alternative). Even then, I'd seriously consider what else could be done first.
The cost of programmers and delivering the service is a far higher consideration to me than the cost of machines. More languages means more complication and risk.
As computer scientists, you either know all the languages, or you can pick up a new one overnight.
And be as productive as after 2 or 3 years? Hardly.
Some languages are not that regular, either, because they are more specific than general. An old mainframe 4GL I used was built around developing screen applications. Once you got going in it, it was rapid to develop in, but getting going in it had a considerable lead time.
Using multiple languages for a given purpose just creates more of a legacy liability.
That's the key distinction. It's also, to some extent worth thinking about Using multiple methods for a given purpose just creates more of a legacy liability.
For instance, I once set down a rule for a.net programmer - all database access must be wrapped in a stored procedure or view. It was simply for consistency sake. That any database processing could be more easily understood as it would be in the SQL Server, and no-one would have to look in two places.
In another company, no program reporting method was agreed. So, some people were firing out to Crystal reports, others were using a homebrew PDF generator, and someone else was using Excel. The key problem was not that anyone was wrong, but that there was an inconsistent approach which introduced problems in maintenance. In such situations, it can become a battle of egos, with each defending their option. It's up to managers to resolve such conflict.
From what I understand, Toyota takes the approach of "consistent method", but makes sure that the method is constantly under review. If someone finds a better way to do something, they suggest it to the team, who consider its merits and then get on with implementing it.
Switching to any language requires some retooling of the mind. It's nearly always going to be slower than using what you know. If you have a live bug to resolve, would you rather it be in the language you've been writing in for 5 years, or something you've never seen before?
For instance, with your set, would PERL make sense? For me if a developer said that they wanted to add a step to a process as PERL, I'd tell them to just write it in one of the core languages. A 10% time saving wouldn't justify the legacy costs and lack of leverage. On the other hand, if someone suggested that we install Bugzilla, even though it was another language, it could make sense.
In the end, it's about what the most cost-effective decision is. And most of the time, adding a new language doesn't meet that. The most common justification to me is actually switching languages (like companies I know that decided to stop writing new VB and switched to C#, or in my case, making a cost-based decision to switch to Python).
In my experience, I'd rather steer clear of such programmers.
I've had to debug hideous code because developers decided to make use of a technology just to boost their CVs. Programs mixing ADO and DAO because someone added some code and thought they'd try out ADO (even though having consistency in the same program was more important).
My favourite programmers are those who concentrate on delivery. They keep an eye on what's around the corner, but at the same time, have a balanced view of using new tech over old. They get the job done because they have been using the same tools and methods for so long that they know how to handle certain issues, and coding it is almost second nature. Which means that they are more focussed on things like getting the business requirements right.
Slashdot Mirror
I didn't really write that well.
What I mean is more like when I've made a change to some OSS code I'm using for my own projects, I frequently offer changes to the author to use. I don't expect to get anything from it, like they are going to offer me a job working on it, it's just what I feel is the honourable thing to do.
Where once, artists rose because of live performance on the basis of talent (and I include the talent to sell records - it's always been an industry), the marketing is about things like image and the artists being known commodities who can generate column inches at the point they are signed. Image is not the same thing as presence, though.
Technology has also played a part. Vocal performances can be tuned and stars can be airbrushed.
The pop star's musical talent or charisma is almost irrelevant. The most important parts to selling a pop song now are the songwriting, image, production and marketing campaign. The pop songs that are good are mostly because of good songwriting and production (like Toxic).
The problem is that once the star puts on a few pounds, and after the media are bored with their various scandals that sell magazines, there's nothing left. They rarely have singing voices of either beauty or distinction. They can't write songs. They can't play. It's time to then bring on another new pop star.
A lot of pop stars in the past "grew up". Madonna has changed and experimented. George Michael is respected as a songwriter. I don't see Britney or Justin Timberlake doing likewise.
I spoke to the C++ guys one day about learning it, and they lent me a book. I got to the part about pointers and put the book down.
When building business applications, you want to be as close to expressing logic as possible, with nothing else getting in the way. You want the minimum amount of code you can do to express this logic, as anything that you write needs to be tested, raising costs.
I write business applications for clients, and I want to build things as cheaply, quickly and reliably as I can (and be cheaply maintainable). If someone gives me this, then I'll take it.
A lot of people bad mouth MS Access as a "toy", but for small data-centric system development, there's not much better. Is it a great performer? Can it make coffee and dance the jitterbug? Does it scale? The answer to all of these is no, but then the requirements didn't need any of these. We needed something that could be built fast, on a small budget and would be disposed of within 18 months. I could express all the business logic I needed to with it.
Programming is getting easier as machines get faster, and not only that, it means that the tools will get closer to the business.
A friend of mine said to me some years ago that he was thinking of learning C++ and I advised him not to bother, because C++ would be the preserve of driver and OS developers. I know that someone's going to say "We build our core apps in C++" but there really isn't much out there. People want higher level stuff like .net, java and PHP.
The thing is, this abstraction will continue to rise. Ruby on Rails give some insight into where this will go. I think that web tools will become more data-centric and less hand-coded. Understanding the business needs, and managing the soft stuff well is getting more important.
You know the first time I heard the expression "warm body syndrome"? In the early 1990s, over a beer with a co-worker discussing how difficult switching jobs was now that we'd gone past that stage.
As budgets got cut, less projects got done and managers focussed on the best people. Then, as the economy improved, managers got bigger budgets, more dumb projects were being done, which meant more warm bodies arriving.
I have a problem with GUI designers, in that they give the perception of creating large productivity improvements. When, in my experience, the GUI part of an application is one of the most static parts of the application. Most code changes in a complex application are the back end. In addition, GUI designers aren't good if you are trying to build an interface that is OO, and by definition, the controls are created at the time you run (and the IDE can discourage developers from thinking in those terms).
You're running an ASP application, and you like the look of ASP.NET. So, what you think would be good would be to write some new forms in ASP.NET as part of an eventual transition.
Only problem is, sessions in ASP and ASP.NET are incompatible. The company that wrote both couldn't be bothered to make them interwork. So, you either have to rewrite your ASP, or use an ugly kludge that stores your session details in a database (meaning changing your existing ASP to allow this to happen).
The freelance market in the UK is not as good as 7 or 8 years ago because no-one builds large projects here. But small projects still have a market, because the communication and management overhead with other countries are larger.
It's also fair to say that doing small jobs means you can't just be a coder. You have to get into the project management, analysis, design and all that too.
A few have some idea of client needs, and actually spend time talking to them about it. Most just get an email of requirements, put it out and keyword match.
I've had agencies tell me that I couldn't be put forward for a contract because I had a skill with currentversion-1, where the differences between currentversion and currentversion-1 were almost indistinguishable AND that you know the company are unlikely to be using any features that were added since currentversion-3.
Your comparing two things here. How much people are paid for using something, with how good the product is.
The other thing is, that following the money in anything is generally a really bad idea. Surveys like this will have thousands of guys looking at .net, simply for the money. I've seen it with a few skills - something pays phenomenally well, so loads of people try and switch to it, resulting in a market adjustment, and it pays little better than where they were before. Of course, if your skills are completely dying out, you might want to consider switching.
Personally, I believe in "do what you like doing, do what you think has a future". If you like coding in Python, you'll be more productive in it than a language you dislike. You'll more likely achieve expertise than a language you dislike, and people will keep asking for you back. But consider that your favourite obscure language (mine's a mainframe 4GL I used 10 years ago ;) ) may not have a future.
The key reason for me is the value of my investment. I know companies running COBOL mainframe apps with a 20 year lifespan. It's being modified, but due to the non-decaying nature of code, that investment keeps giving a better return year on year, and each year in service, bugs are detected and destroyed.
VB6 is being killed off. Support has already finished. So, what happened to what you built 5 years ago in VB6? You've got to convert it (which doesn't work too well) or rewrite it. How long until c# or asp.net get killed off for Microsoft's next big thing, and all your team have to go through another pointless set of learning to deliver nothing to your business?
The coding had to be done on a computer which was kept in the same room as the coffee area. People walking in and making coffees wasn't the worst thing.
The worst thing would have been the machine used for testing the strength of the compounds. Kept away from the factory for being too noisy. How do you test the strength of the compounds? You make a stiletto heel and put it in a special machine that hits it repeatedly with a hammer until it breaks, at which point the counter stops. Imagine trying to code with that going on?
There are some complex reasons for doing it (like getting others using your code can give you feedback, bug finding, or because you are charitable, or to raise your profile).
It seemed to me that the X-Prize, whilst giving some compensation was only a fraction of the amounts spent. I think the money helped to create publicity and make it look worthwhile.
The people I like to work with aren't those who will spend time tuning an overnight print process from 3 hours to 10 minutes, they are the people who prefer spending time dealing with understanding the business needs. They don't really like coding, beyond what it can do for them.
The need for "hackers" in business development is diminishing. C++ coding skills are diminishing in demand. For many companies, the speed of code is getting to the point of being irrelevant, beyond network and database IO. The mainframe departments I know have less than 5% hackers to developers, because they're not required. This trend will happen to PC/web departments.
Sounds like you are lucky to work in an ill-disciplined company. I've ran a programming team, and you'd be starting down the road to getting fired if you did that with me, or most managers I've known.
I spent a year fixing code in a company where all sorts of not just languages, but different libraries used (which did the same thing) even in the same program. Programmers just did things in certain ways because they'd never tried them before, or to put something on their CV.
Multiple languages in your example are only justifiable if I know that the file processing in our key language could not meet the business requirement (like it was overnight processing and would take 20 hours in our key language and 2 hours in an alternative). Even then, I'd seriously consider what else could be done first.
The cost of programmers and delivering the service is a far higher consideration to me than the cost of machines. More languages means more complication and risk.
And be as productive as after 2 or 3 years? Hardly.
Some languages are not that regular, either, because they are more specific than general. An old mainframe 4GL I used was built around developing screen applications. Once you got going in it, it was rapid to develop in, but getting going in it had a considerable lead time.
That's the key distinction. It's also, to some extent worth thinking about Using multiple methods for a given purpose just creates more of a legacy liability.
For instance, I once set down a rule for a .net programmer - all database access must be wrapped in a stored procedure or view. It was simply for consistency sake. That any database processing could be more easily understood as it would be in the SQL Server, and no-one would have to look in two places.
In another company, no program reporting method was agreed. So, some people were firing out to Crystal reports, others were using a homebrew PDF generator, and someone else was using Excel. The key problem was not that anyone was wrong, but that there was an inconsistent approach which introduced problems in maintenance. In such situations, it can become a battle of egos, with each defending their option. It's up to managers to resolve such conflict.
From what I understand, Toyota takes the approach of "consistent method", but makes sure that the method is constantly under review. If someone finds a better way to do something, they suggest it to the team, who consider its merits and then get on with implementing it.
Switching to any language requires some retooling of the mind. It's nearly always going to be slower than using what you know. If you have a live bug to resolve, would you rather it be in the language you've been writing in for 5 years, or something you've never seen before?
For instance, with your set, would PERL make sense? For me if a developer said that they wanted to add a step to a process as PERL, I'd tell them to just write it in one of the core languages. A 10% time saving wouldn't justify the legacy costs and lack of leverage. On the other hand, if someone suggested that we install Bugzilla, even though it was another language, it could make sense.
In the end, it's about what the most cost-effective decision is. And most of the time, adding a new language doesn't meet that. The most common justification to me is actually switching languages (like companies I know that decided to stop writing new VB and switched to C#, or in my case, making a cost-based decision to switch to Python).
I've had to debug hideous code because developers decided to make use of a technology just to boost their CVs. Programs mixing ADO and DAO because someone added some code and thought they'd try out ADO (even though having consistency in the same program was more important).
My favourite programmers are those who concentrate on delivery. They keep an eye on what's around the corner, but at the same time, have a balanced view of using new tech over old. They get the job done because they have been using the same tools and methods for so long that they know how to handle certain issues, and coding it is almost second nature. Which means that they are more focussed on things like getting the business requirements right.