Your's is one of the few posts here by a doctor that doesn't come across as dismissive and arrogant. If I need medical care I hope I have a doctor with similar temperament. Nevertheless if you ignore his self-diagnosis, but assume that he is accurately reporting his symptoms, it is clear that there is something wrong.
Even if what's wrong is not really something life threatening, it is clear that he thinks it is and he is terrified because of it. That should be addressed by the doctors he goes to. Even if it is not rational, or medically justified, his fear should be addressed as a serious symptom of whatever is wrong. This is no different than treating pain. Pain is subjective, it is a symptom of something else, but when it becomes debilitating it is treated directly. Fear should be no different.
But I don't think the situation is as completely hopeless for the lone coder. There is still a place for closed source apps serving a niche. Something small enough that you can keep in touch with your end users' (or user's) needs. The "threat" of open source is only a problem for if you aren't doing a good enough job in the areas open source excels. I don't think people are inherantly adverse to paying for software if they feel you are providing them a service and not just milking them. But once the niche is too large for you to provide that service on your own, users will look at open source as a way of getting the software they really want.
And you've missed the point that I was replying to.:)
The parent of my post said: This isn't going to be a popular sentiment here, but I'd say that the GPL and P2P generally make it tougher to make a living.
That poster is probably right, the existance of competing GPL'ed software does make it harder for him to make money from his software. That is what I was responding to. I wasn't trying to argue that he should GPL his software.
But by lumping the GPL together with P2P (I assume he is talking about software piracy) implies some wrongdoing on the part of open source developers. It isn't there directly, but the implication is there that open source programmers shouldn't be distributing software for free because it takes food out of the mouths of other programmers. (as if open source programmers were essentially distributing pirated software)
Each developer chooses the conditions they want to license their own work under. That's how it should be.
What I do have a problem with is closed source programmers who complain that they can't make a living because some open source programmers are creating free software that does the same thing.
This isn't going to be a popular sentiment here, but I'd say that the GPL...generally make[s] it tougher to make a living....and the automobile generally makes it tougher to make a living shoveling horse shit. That's life. Be prepared to change jobs if you have to. One thing for sure, it's easier to now than it was back then.
I make my living writing software too. And I plan on doing so until I retire. But computers don't exist for the sole purpose of giving programmers jobs. People in other fields are end-users. They actually use that GPL'ed software to do THEIR jobs. If that software didn't exist or wasn't open source THEY might not have jobs. Think about that when you complain about Open Source programmers undermining your bussiness.
How convenient...for a company that sells microprocessors;). As market the penetration of PC's approaches 100%, Intel envisions a future in which everybody needs to have thousands (or millions) of devices with a microprocessor, instead of a just a handful. And of course they require zero human input. Nobody could operate or pay attention to thousands of devices at once.
This is something I've wrestled with too. Start where you'll get the most bang for your buck. Start with regression tests. I assume you're doing *some* testing (or at least your users are;). When a problem shows up, make an automated regression test that surfaces that bug. Run it often and make sure the bug stays fixed.
With a 300KLOC codebase I have to ask is it boken down into components that can be tested in isolation. If it is, congradulations you've done some good software architecture. You can start by testing the interfaces to the components. Make a test that triggers each error condition from each interface function/object. The tests will seem braindead simple (like passing in a NULL when a valid pointer is expected), but these sort of tests are suprisingly useful. Infrequently exercised error checking is one of the easiest things to let slip through the cracks when modifing an implementation. That will be enough to get your test framwork set up, and shake out all the forgotten dependencies between your components. Then it will be straightforward to add more testing.
It won't be easy. You should expect you'll have to modify your code to make it testable. But if you expect to keep this code around for a while, it will pay off in the long run.
I think students do know what employers are looking for. What they are looking for are coders not "problem solvers".
The reality is that most employees are hired to do a specific job, and most employers don't have the time/interviewing skill to sift through the applicants to find the really talented engineer. It is much easier for them to look for the right collection of TLAs (Three Letter Acronyms) that indicate experience applicable to the job at hand.
Students and grads find this out quick once they start looking for real industry jobs. So naturally their resume's stress their coding abilities over the general abilities at finding solutions to problems.
Slashdot Mirror
I replaced parts of the case on a Toshiba laptop. When I called to order the parts someone over the phone helped me find the right ones.
Your's is one of the few posts here by a doctor that doesn't come across as dismissive and arrogant. If I need medical care I hope I have a doctor with similar temperament. Nevertheless if you ignore his self-diagnosis, but assume that he is accurately reporting his symptoms, it is clear that there is something wrong.
Even if what's wrong is not really something life threatening, it is clear that he thinks it is and he is terrified because of it. That should be addressed by the doctors he goes to. Even if it is not rational, or medically justified, his fear should be addressed as a serious symptom of whatever is wrong. This is no different than treating pain. Pain is subjective, it is a symptom of something else, but when it becomes debilitating it is treated directly. Fear should be no different.
Yeah I think we see the same things here.
But I don't think the situation is as completely hopeless for the lone coder. There is still a place for closed source apps serving a niche. Something small enough that you can keep in touch with your end users' (or user's) needs. The "threat" of open source is only a problem for if you aren't doing a good enough job in the areas open source excels. I don't think people are inherantly adverse to paying for software if they feel you are providing them a service and not just milking them. But once the niche is too large for you to provide that service on your own, users will look at open source as a way of getting the software they really want.
And you've missed the point that I was replying to. :)
The parent of my post said:
This isn't going to be a popular sentiment here, but I'd say that the GPL and P2P generally make it tougher to make a living.
That poster is probably right, the existance of competing GPL'ed software does make it harder for him to make money from his software. That is what I was responding to. I wasn't trying to argue that he should GPL his software.
But by lumping the GPL together with P2P (I assume he is talking about software piracy) implies some wrongdoing on the part of open source developers. It isn't there directly, but the implication is there that open source programmers shouldn't be distributing software for free because it takes food out of the mouths of other programmers. (as if open source programmers were essentially distributing pirated software)
Each developer chooses the conditions they want to license their own work under. That's how it should be.
What I do have a problem with is closed source programmers who complain that they can't make a living because some open source programmers are creating free software that does the same thing.
This isn't going to be a popular sentiment here, but I'd say that the GPL...generally make[s] it tougher to make a living. ...and the automobile generally makes it tougher to make a living shoveling horse shit. That's life. Be prepared to change jobs if you have to. One thing for sure, it's easier to now than it was back then.
I make my living writing software too. And I plan on doing so until I retire. But computers don't exist for the sole purpose of giving programmers jobs. People in other fields are end-users. They actually use that GPL'ed software to do THEIR jobs. If that software didn't exist or wasn't open source THEY might not have jobs. Think about that when you complain about Open Source programmers undermining your bussiness.
How convenient...for a company that sells microprocessors ;). As market the penetration of PC's approaches 100%, Intel envisions a future in which everybody needs to have thousands (or millions) of devices with a microprocessor, instead of a just a handful. And of course they require zero human input. Nobody could operate or pay attention to thousands of devices at once.
This is something I've wrestled with too. Start where you'll get the most bang for your buck. Start with regression tests. I assume you're doing *some* testing (or at least your users are ;). When a problem shows up, make an automated regression test that surfaces that bug. Run it often and make sure the bug stays fixed.
With a 300KLOC codebase I have to ask is it boken down into components that can be tested in isolation. If it is, congradulations you've done some good software architecture. You can start by testing the interfaces to the components. Make a test that triggers each error condition from each interface function/object. The tests will seem braindead simple (like passing in a NULL when a valid pointer is expected), but these sort of tests are suprisingly useful. Infrequently exercised error checking is one of the easiest things to let slip through the cracks when modifing an implementation. That will be enough to get your test framwork set up, and shake out all the forgotten dependencies between your components. Then it will be straightforward to add more testing.
It won't be easy. You should expect you'll have to modify your code to make it testable. But if you expect to keep this code around for a while, it will pay off in the long run.
is the most beautiful formula in mathamatics
I think students do know what employers are looking for. What they are looking for are coders not "problem solvers".
The reality is that most employees are hired to do a specific job, and most employers don't have the time/interviewing skill to sift through the applicants to find the really talented engineer. It is much easier for them to look for the right collection of TLAs (Three Letter Acronyms) that indicate experience applicable to the job at hand.
Students and grads find this out quick once they start looking for real industry jobs. So naturally their resume's stress their coding abilities over the general abilities at finding solutions to problems.