I suppose if you aren't interested in reaching many users, that developing for a single platform like the iPhone is a decent choice. However, if you want to remain viable both in terms of independence and also monetarily, you need to have a broad base of users, not just a small group of fanatics.
You seem to have a different definition of "many" than I do. iPhone adoption has been huge so far, and not just "a small group of fanatics."
The difference between 1d and 2d is fairly small, the difference between 10k and 11k is trivial.
The difference between 5d and 6d ("merely" one stone) is enormous, and the gulf just keeps increasing. It will not, even doubling the processing power, clear 9 stones in the next year unless there's some truly amazing breakthrough in store for us.
Meanwhile, even a fairly weak pro tends to be 7d or higher when calculated among amateurs. In the AGA right now some pros are considered "strong 9 dans."
Beating a human pro at 9H is an accomplishment, but to put it in perspective... I'm probably a bit stronger than mogo, and I don't even recommend people take handicaps with me until they get to where they can beat me at 9H because they don't have enough basics down to make a serious game with handicap worthwhile.
I have had clients do or threaten to do all of the above.
From there you seem to go off on a tangent and make some errant assumptions, so let's be clear.
It seems to me that you don't understand that what I am talking about is the response "patches welcome" and its degree of utter unprofessionalism. Why, if the users are acting as rudely as you say, do you even give them the time of day?
Even if customer acting rudely is no excuse for you to act rudely back. There are exactly two professional (or professional amateur) responses: a) A calm, rational response of one of the forms that others have pointed out (e.g., "I don't have time for that right now, but I'd gladly look at a patch," "It is on the queue, but that feature is a very low priority for me right now unless someone is willing to pay me for it," "I'm sorry, could you be more specific about what you mean by 'sucks?'") or b) Ignore it.
So they don't respect you or your time? Try emphasizing the value of your time while not demeaning the value of theirs. Sniping back, caustically saying "patches welcome," etc are just escalating a situation that you have no need to escalate beyond stroking your own ego.
Unless, of course, you don't mind being locked in a room with a "Beware of Cougar" sign outside.
I am a developer, I am also responsible for interviewing junior developers.
If I found that someone I was interviewing had an attitude of "You accuse developers of being jerks, yet you're the one who started being a jerk. And then you expect them not behaving like jerks in front of you," even on "free" open source projects, I would consider them unsuitable for dealing with clients and potentially even other developers. Full stop. It doesn't matter if it is "for pay" or "for free."
If I were to even consider hiring them, it would be because I have a position open in a back room that I can lock and that has a sign on it saying "beware of cougar." Then I could lock the "developer" in question back there and slide the occasional pizza under the door, and never have to worry about them seeing another human being.
Zealots? What exactly do you think I'm talking about?
I'm talking about the difference between "professionals" or "professional amateurs" and "hobbyists." This is about professionalism, not zealotry or developers.
This is the difference between people who care about quality, usability, and other such metrics and those who just want to hack something together for their own use and put it up in the internet under the GPL.
Now, tell me. I have a job. I maintain this software in my free time. Why should I devote that time to you, for free, instead of, say, hanging out with friends or seeing a movie? You're not paying me for this software. You probably would go away if I ask you to hire me. What exactly do I owe you? I already made the source code available. Why do you criticize me for not working for you for free? Why don't you do it yourself, or hire someone to do it for you? If you can't do either of those, why don't you contribute documentation, mockups, or something else that's not technical but is still useful? Do you expect a baker to give bread to you for free when you criticize his breads for not being tasty enough?
Do you want me to use your project?
I also have a job. I contribute to a short list of open source projects in my free time, and a few non-open source personal projects as well. My time is just as valuable to me as yours is to you. So the time it would take me to learn your codebase, etc just to add the fix is generally nor worth my time the amount it would cost for me to buy a professional product that does the same thing.
So convince me to write a patch. You are the maintainer, do you want your software to be used? Do you want it to improve? What if I'm not a programmer or totally unfamiliar with the internals of your app? For anything past "trivial" why should I embed myself in your project if I have any other option out there? The statement "patches welcome" presupposes that your time is _more_ valuable than mine, as a user of your product.
Which leads us to the actual problem with the statement "patches welcome." There are a variety of better approaches than "patches welcome" from a customer relationship standpoint, and if you have users then you functionally have customers. File it as a bug or an enhancement request, mention that its a low priority for you right now, or that you would "certainly consider a patch" for it but "don't have time right now." This recasts the problem and the potential range of solutions, and it recognizes the value of your time while not demeaning the value of theirs.
As a software development *student*, you should be focusing more on the concepts, on engineering problem solving, and on reasoning skills than on the specific technologies.
As a software engineering professional, I learn the tools that I need to effectively do my job. I learn things that look interesting and applicable to whatever it is I am doing. Thus, I work with the GWT and with AJAX because I decided that's what I needed in order to tackle a problem we were having. As a senior engineer who is engaged in the hiring process, I care more about that you can think than that you happen to have seen and worked with twelve dozen technologies by the time you graduated. As a job posting I saw recently says:
We do not hire based on a specific list of buzzwords, technologies, or popular acronyms on your resume. Today we happen to use Wasabi, JavaScript, xhtml and CSS, and C++ to build FogBugz, but Python and.NET are likely to be important in the future. We use C++ and Objective C for Copilot. We have server systems in C# and legacy code in VBScript. Tomorrow we may be using something different.
Whatever technologies, languages, or development environments you've been using, we expect you have mastered them in depth, and we expect that you will be able to master any technology, language, or development environment that we need in the future.
You can't predict it and the specific tools will change tomorrow, so as a student I would generally say that learning it--unless it is for a specific project or class of projects, or because it contains a concept or problem solving idea that you want to learn--is a waste of time. I learned R back in school because it was more efficient than using Minitab for multivariate statistics and for statistical modeling, not because it was out there and I needed to put it on my resume. On the latter point, I still think learning Prolog and LISP were extremely valuable despite that I never use them professionally and will probably never use them professionally.
Incidentally, if you are a good engineer, the language doesn't matter. If you are a bad engineer, the language still doesn't matter. *Problem solving* counts for more in the long run than bullet points.
My business--as a application engineer--takes me across the ocean on a regular basis. Knowing Thai right now would be tremendously useful purely from a professional perspective, let alone for navigating the country. This is despite that most of the engineers who I deal with speak at least passing English, but Engineers are not the ones who we are delivering a product for, nor are they the people who work in taxis or restaurants, nor are they the ones I have to get directions from on the street.
Knowing Japanese or Mandarin would be similarly useful.
Saying that it is "utterly useless as far as the engineering career goes" is extremely shortsighted.
While interesting, what does any of that have to do with what I pointed out?
My point: the situation is complex and influenced by a myriad of factors, trying to say "we need to increase staff" is a knee-jerk reaction and not necessarily the right one. Other systems--which have flaws and good points of their own--manage to do better with similar or worse ratios of students to teachers, and there's nothing unique about the US school system that makes the student:teacher ratio a magical number that will fix more intrinsic problems.
Ever seen scans from a FOIA request? They redact certain information regarding sources and methods (and some would claim whatever they feel like at the time). *That* would be a "use" of this technology.
"Enter the registration key" type schemes are more easily accomplished without it being underhanded in nature.
iTunes offers a specific set of services to its customers (us). If Radiohead does not like or does not want those services, they are free to sell with someone else who will offer them that option.
The Windows game market is also more of a red ocean. The mac market has fewer games and, hence, less competition. There is also no telling what percentage of the marketshare of D&D users use which OS, but there does seem to be a significantly positive movement toward macs (or at least systems that run MacOS X) among individuals.
Markets are substantially more complex than their marketshare would indicate. Attempting to say "the marketshare is small, therefore the market is small" is specious reasoning.
I remember quite distinctly spending an hour inserting all of the issues into a code review that FindBugs came up with, and then going through and explaining each one. That time could have easily been spent by the author of the program, which would have then freed me up to focus on higher level problems that the static code checker can't detect (logic flaws, etc). Many of them can also detect things quickly, such as deadlocks and improper synchronization, that it can take a developer a while working with a pad of paper to catch.
It isn't a substitute for a proper code review, but it can make code reviews substantially more efficient and productive.
FindBugs is becoming increasingly widespread on Java projects, for example. I found that between it and JLint I could identify a substantial chunk of problems caused by inexperienced programmers, poor design, hastily written code, etc. JLint was particularly nice for potential deadlocks, while FindBugs was good for just about everything else.
For example:
Failure to make null checks.
Ignoring exceptions
Defining equals() but not hashCode() (and the other variations)
At least in the Java world, I wish more people would use them. It would make my job so much easier.
My experience in the Python world is that pylint is less interesting than FindBugs: many of the more interesting bugs are hard problems in a dynamically typed language and so it has more "religious style issues" built in that are easier to test for. It still provides a great deal of useful output once configured correctly, and can help enforce a consistent coding standard.
YMMV, but in my experience its the techs who are sticking around until 3 the next morning fixing things for the demo that was suddenly moved up a week for political reasons.
The Business Analysts et al have more regular hours and work less overtime.
You have a strong disdain for theory, but what is it you think an actuary or a risk manager actually studies? I'll give you a hint what the certifications look at.
Now, your milage may vary, but I don't think your disdain for what you think of as "theoretical" knowledge is justified or practical. Nor do I think your characterization of "geeks" or "Ph.Ds" is fair.
In the interest of full disclosure: I walk both worlds.
What makes "child porn" worthy of prosecution at the level that it is?
The sexual abuse of actual, living, breathing children.
If someone takes a photo and photoshops it to jack off and leaves it on their computer, it may be sick and "wrong," it may even be illegal, but it is not a crime even within several orders of magnitude of child pornography in the classic sense.
If they distribute it: again, sick and wrong, certainly illegal. But no children were harmed at nearly the level they would have been if they had been involved in the sexual abuse. Virtually nothing is at the same order of magnitude as the child is not actually being sexually abused.
This seems to be a common problem in the united states. We define something in broad terms, e.g., "sex crime" in an effort to "protect children" (or some other laudable goal). Then we classify things into that category that clearly meet the outer definition, but which have nothing to do with the original purpose of that classification.
For example, take the states that consider "crimes against nature" to be "sex crimes." Okay, so they are sex crimes in the broadest possible sense, but as the saying goes "no children were harmed in the making of this production." The same goes for cases of statutory rape between teenagers or even rape between adults--it may be a "sex crime" but has very little to do with protecting children.
Something similar happened with child pornography. Its intent is to protect--as you point out--people at age 8, not to keep 17 year olds from taking photos of themselves. But we have magically classified anyone under the age of 18 as a child. Therefore, it must be child porn since it is porn that involves someone who is legally a child.
Or, it must be "child porn" because it involves porn with an actual child, despite that the child was never present for the making of said porn and has only leant an image. It may be "child porn" in the strictest sense, but in truth it has no relevance on what child pornography laws were actually meant to protect against.
I should point out that the "ability to fix it if something breaks" is not inherent in any definition of "working" I've ever seen, but that aside...
Buildings remaining standing is necessary but not sufficient.
Software "working" is also necessary but not sufficient.
If the software does what it is supposed to then it clearly meets the necessary conditions, but that doesn't mean that it is any good.
Either you need to broaden the definition of 'works' to the point where we get into a circular argument about exactly what 'working' means and how do we measure it, in which case 'working' becomes synonymous with 'code quality' and everything past there is a semantic argument since all of the same debates that go into "code quality" now go into "working," or we accept that "works" is a "necessary but not sufficient" criteria to code quality.
Slashdot Mirror
You seem to have a different definition of "many" than I do. iPhone adoption has been huge so far, and not just "a small group of fanatics."
It is well understood, but it should also be emphasized that the go endgame is P-SPACE hard.
The difference between 1d and 2d is fairly small, the difference between 10k and 11k is trivial.
The difference between 5d and 6d ("merely" one stone) is enormous, and the gulf just keeps increasing. It will not, even doubling the processing power, clear 9 stones in the next year unless there's some truly amazing breakthrough in store for us.
Meanwhile, even a fairly weak pro tends to be 7d or higher when calculated among amateurs. In the AGA right now some pros are considered "strong 9 dans."
Beating a human pro at 9H is an accomplishment, but to put it in perspective... I'm probably a bit stronger than mogo, and I don't even recommend people take handicaps with me until they get to where they can beat me at 9H because they don't have enough basics down to make a serious game with handicap worthwhile.
I have had clients do or threaten to do all of the above.
From there you seem to go off on a tangent and make some errant assumptions, so let's be clear.
It seems to me that you don't understand that what I am talking about is the response "patches welcome" and its degree of utter unprofessionalism. Why, if the users are acting as rudely as you say, do you even give them the time of day?
Even if customer acting rudely is no excuse for you to act rudely back. There are exactly two professional (or professional amateur) responses: a) A calm, rational response of one of the forms that others have pointed out (e.g., "I don't have time for that right now, but I'd gladly look at a patch," "It is on the queue, but that feature is a very low priority for me right now unless someone is willing to pay me for it," "I'm sorry, could you be more specific about what you mean by 'sucks?'") or b) Ignore it.
So they don't respect you or your time? Try emphasizing the value of your time while not demeaning the value of theirs. Sniping back, caustically saying "patches welcome," etc are just escalating a situation that you have no need to escalate beyond stroking your own ego.
Unless, of course, you don't mind being locked in a room with a "Beware of Cougar" sign outside.
I am a developer, I am also responsible for interviewing junior developers.
If I found that someone I was interviewing had an attitude of "You accuse developers of being jerks, yet you're the one who started being a jerk. And then you expect them not behaving like jerks in front of you," even on "free" open source projects, I would consider them unsuitable for dealing with clients and potentially even other developers. Full stop. It doesn't matter if it is "for pay" or "for free."
If I were to even consider hiring them, it would be because I have a position open in a back room that I can lock and that has a sign on it saying "beware of cougar." Then I could lock the "developer" in question back there and slide the occasional pizza under the door, and never have to worry about them seeing another human being.
Zealots? What exactly do you think I'm talking about?
I'm talking about the difference between "professionals" or "professional amateurs" and "hobbyists." This is about professionalism, not zealotry or developers.
This is the difference between people who care about quality, usability, and other such metrics and those who just want to hack something together for their own use and put it up in the internet under the GPL.
Do you want me to use your project?
I also have a job. I contribute to a short list of open source projects in my free time, and a few non-open source personal projects as well. My time is just as valuable to me as yours is to you. So the time it would take me to learn your codebase, etc just to add the fix is generally nor worth my time the amount it would cost for me to buy a professional product that does the same thing.
So convince me to write a patch. You are the maintainer, do you want your software to be used? Do you want it to improve? What if I'm not a programmer or totally unfamiliar with the internals of your app? For anything past "trivial" why should I embed myself in your project if I have any other option out there? The statement "patches welcome" presupposes that your time is _more_ valuable than mine, as a user of your product.
Which leads us to the actual problem with the statement "patches welcome." There are a variety of better approaches than "patches welcome" from a customer relationship standpoint, and if you have users then you functionally have customers. File it as a bug or an enhancement request, mention that its a low priority for you right now, or that you would "certainly consider a patch" for it but "don't have time right now." This recasts the problem and the potential range of solutions, and it recognizes the value of your time while not demeaning the value of theirs.
Yahoo had a music store?
As a software development *student*, you should be focusing more on the concepts, on engineering problem solving, and on reasoning skills than on the specific technologies.
As a software engineering professional, I learn the tools that I need to effectively do my job. I learn things that look interesting and applicable to whatever it is I am doing. Thus, I work with the GWT and with AJAX because I decided that's what I needed in order to tackle a problem we were having. As a senior engineer who is engaged in the hiring process, I care more about that you can think than that you happen to have seen and worked with twelve dozen technologies by the time you graduated. As a job posting I saw recently says:
You can't predict it and the specific tools will change tomorrow, so as a student I would generally say that learning it--unless it is for a specific project or class of projects, or because it contains a concept or problem solving idea that you want to learn--is a waste of time. I learned R back in school because it was more efficient than using Minitab for multivariate statistics and for statistical modeling, not because it was out there and I needed to put it on my resume. On the latter point, I still think learning Prolog and LISP were extremely valuable despite that I never use them professionally and will probably never use them professionally.
Incidentally, if you are a good engineer, the language doesn't matter. If you are a bad engineer, the language still doesn't matter. *Problem solving* counts for more in the long run than bullet points.
Lots!
Er, and GPS, improved audio quality, improved wifi reception, etc.
My business--as a application engineer--takes me across the ocean on a regular basis. Knowing Thai right now would be tremendously useful purely from a professional perspective, let alone for navigating the country. This is despite that most of the engineers who I deal with speak at least passing English, but Engineers are not the ones who we are delivering a product for, nor are they the people who work in taxis or restaurants, nor are they the ones I have to get directions from on the street.
Knowing Japanese or Mandarin would be similarly useful.
Saying that it is "utterly useless as far as the engineering career goes" is extremely shortsighted.
Apple has always gouged on the RAM prices. This is not news.
While interesting, what does any of that have to do with what I pointed out?
My point: the situation is complex and influenced by a myriad of factors, trying to say "we need to increase staff" is a knee-jerk reaction and not necessarily the right one. Other systems--which have flaws and good points of their own--manage to do better with similar or worse ratios of students to teachers, and there's nothing unique about the US school system that makes the student:teacher ratio a magical number that will fix more intrinsic problems.
Read The Learning Gap, about Asian elementary schools.
It may be a factor, but given the student-teacher ratio in such schools there are others that are likely more important.
Ever seen scans from a FOIA request? They redact certain information regarding sources and methods (and some would claim whatever they feel like at the time). *That* would be a "use" of this technology.
"Enter the registration key" type schemes are more easily accomplished without it being underhanded in nature.
Why should iTunes let them do it?
iTunes offers a specific set of services to its customers (us). If Radiohead does not like or does not want those services, they are free to sell with someone else who will offer them that option.
The Windows game market is also more of a red ocean. The mac market has fewer games and, hence, less competition. There is also no telling what percentage of the marketshare of D&D users use which OS, but there does seem to be a significantly positive movement toward macs (or at least systems that run MacOS X) among individuals.
Markets are substantially more complex than their marketshare would indicate. Attempting to say "the marketshare is small, therefore the market is small" is specious reasoning.
For example: The rule book for Kobolds Ate My Baby is 48 pages long with no supplements or extensions I'm aware of. Still a lot of fun ^_^
Will make them a little hard to tilt against. A charge on horseback is nearly as dramatic when they are out at sea.
I remember quite distinctly spending an hour inserting all of the issues into a code review that FindBugs came up with, and then going through and explaining each one. That time could have easily been spent by the author of the program, which would have then freed me up to focus on higher level problems that the static code checker can't detect (logic flaws, etc). Many of them can also detect things quickly, such as deadlocks and improper synchronization, that it can take a developer a while working with a pad of paper to catch.
It isn't a substitute for a proper code review, but it can make code reviews substantially more efficient and productive.
FindBugs is becoming increasingly widespread on Java projects, for example. I found that between it and JLint I could identify a substantial chunk of problems caused by inexperienced programmers, poor design, hastily written code, etc. JLint was particularly nice for potential deadlocks, while FindBugs was good for just about everything else.
For example:
At least in the Java world, I wish more people would use them. It would make my job so much easier.
My experience in the Python world is that pylint is less interesting than FindBugs: many of the more interesting bugs are hard problems in a dynamically typed language and so it has more "religious style issues" built in that are easier to test for. It still provides a great deal of useful output once configured correctly, and can help enforce a consistent coding standard.
YMMV, but in my experience its the techs who are sticking around until 3 the next morning fixing things for the demo that was suddenly moved up a week for political reasons.
The Business Analysts et al have more regular hours and work less overtime.
You have a strong disdain for theory, but what is it you think an actuary or a risk manager actually studies? I'll give you a hint what the certifications look at.
Now, your milage may vary, but I don't think your disdain for what you think of as "theoretical" knowledge is justified or practical. Nor do I think your characterization of "geeks" or "Ph.Ds" is fair.
In the interest of full disclosure: I walk both worlds.
What makes "child porn" worthy of prosecution at the level that it is?
The sexual abuse of actual, living, breathing children.
If someone takes a photo and photoshops it to jack off and leaves it on their computer, it may be sick and "wrong," it may even be illegal, but it is not a crime even within several orders of magnitude of child pornography in the classic sense.
If they distribute it: again, sick and wrong, certainly illegal. But no children were harmed at nearly the level they would have been if they had been involved in the sexual abuse. Virtually nothing is at the same order of magnitude as the child is not actually being sexually abused.
This seems to be a common problem in the united states. We define something in broad terms, e.g., "sex crime" in an effort to "protect children" (or some other laudable goal). Then we classify things into that category that clearly meet the outer definition, but which have nothing to do with the original purpose of that classification.
For example, take the states that consider "crimes against nature" to be "sex crimes." Okay, so they are sex crimes in the broadest possible sense, but as the saying goes "no children were harmed in the making of this production." The same goes for cases of statutory rape between teenagers or even rape between adults--it may be a "sex crime" but has very little to do with protecting children.
Something similar happened with child pornography. Its intent is to protect--as you point out--people at age 8, not to keep 17 year olds from taking photos of themselves. But we have magically classified anyone under the age of 18 as a child. Therefore, it must be child porn since it is porn that involves someone who is legally a child.
Or, it must be "child porn" because it involves porn with an actual child, despite that the child was never present for the making of said porn and has only leant an image. It may be "child porn" in the strictest sense, but in truth it has no relevance on what child pornography laws were actually meant to protect against.
I should point out that the "ability to fix it if something breaks" is not inherent in any definition of "working" I've ever seen, but that aside...
Buildings remaining standing is necessary but not sufficient.
Software "working" is also necessary but not sufficient.
If the software does what it is supposed to then it clearly meets the necessary conditions, but that doesn't mean that it is any good.
Either you need to broaden the definition of 'works' to the point where we get into a circular argument about exactly what 'working' means and how do we measure it, in which case 'working' becomes synonymous with 'code quality' and everything past there is a semantic argument since all of the same debates that go into "code quality" now go into "working," or we accept that "works" is a "necessary but not sufficient" criteria to code quality.