Surprisingly enough, this can even happen in academic environments that should know better.
Though far from the level of difficulty presented by jacquesm, the same thing happened to me with an end-of-term project a few years back.
We had to make a small piece of software in Java. Most of my mates were going for boring stuff, such as sudoku solvers or small neural networks to play the likes of Connect four.
I wanted to make a Gameboy emulator.
"You can't do this", said my professor. "At least not in two weeks' time."
Well I don't remember much besides coding during those two weeks, but guess what - after 14 days, my program could boot Tetris. No sound, granted, but it was playable.
My professor was quite the sore loser though - he considered the program incomplete since it only booted a few roms, didn't have sound and could crash randomly. I ended up turning in a gameboy rom dissassembler instead, complete with GUI and breakpoints setting.
Professor told me to do self-localization of soccer robots based on greyscale images and assigned me to a PhD student.
PhD student said "This can't be done, at least not in real-time" and was angry about his professor because he now had to look after me somehow. Of course, he didn't.
Six months later, my program could self-localize a soccer robot based on greyscale images, in real-time. On large fields and with varying light sources, which the previous, color-based algorithm couldn't.
Unfortunately, PhD student was a sore looser and still gave me a bad grade. Professor didn't help.
That is an impressive accomplishment. I've never been a "fast" coder like that. I've never met a problem I couldn't solve or code I couldn't figure out, but, as my iOS app can attest, I'l can't crank the code like that.
There may be one important lesson in that experience, though (not that I believe the prof was trying to teach it): complete, rock-solid software with few features beats glitzy, bug-filled software with many features. Users will never know what they are missing.
That's almost the exact experience I had in my first term of university. Everyone was making connect 4 and sudoku and they told me I couldn't write a Doom-style raycasting engine. That was the reason I had to do it!
It didn't even count towards course credit, but by the time I submitted I'd built everything, with an in-game level editor and reflective surfaces (all software-rendered). It was way beyond what I had ever achieved, and completing that project totally changed my view of what was possible.
The first engineer we hired got the job even though he us still in school for exactly that reason. He had a hardware assignment to build a bios: he built a real OS on top of that with a compliler just to finalize it in his mind.
Make sure that story comes through on your resume.
Hmm, a term was about 10 weeks so I guess this must have taken about 4 or 5 weeks. But I was working on it a ridiculous amount.
My friends called it "Ray" and would leave funny drawings on my desk depicting them partying while I played with Ray. Or if I had been partying with them, they'd all groan when we arrived home and I set to work. But it was definitely worth it.
For my final thesis in college my professor made me change my mind. My initial project idea was a music instrument, a polyphonic digital synthesizer (TTL-only, no processors). I had a single wavetable "voice" implemented in silicon already, as a proof of concept.
Instead, he convinced me to make a boring sawtooth variable current generator for his lasers. :( Grrr, I wish I didn't listen to him.
And in my experience when enough people are saying that 'you can't do that' there is an opportunity waiting for you that is proportional in pay-off to the number of people asserting that it can't be done.
Great thought.
Most of my most memorable successes were when others said that something couldn't be done. First you think, "Why not?" Then you think, "What would it take?" Then you figure that you'll never find out for sure unless you try. The reward is compounded by the initial skeptism.
Just a few silly examples (any of these sound familiar?):
Manager: Shop Floor Control is impossible.
Me: Why?
Manager: Because the base data is so inaccurate.
Me: So?
Manager: It would take years to fix all the data.
Me: What if we turned in on anyway?
Manager: The output would be worthless.
Me: Wouldn't it show where the base data was inaccurate?
Manager: Yes.
Me: Then you could fix the biggest culprits?
Manager: I suppose.
Me: So turning it on would expedite data fixing?
Manager: Yes.
Me: So it's not really impossible?
Manager: Well...
Manager: Bug free software is impossible.
Me: What would it take to make is possible?
Manager: Nothing. Can't be done.
Me: What if we added systems testing to unit testing?
Me: And then built rigorous test plans covering almost everything?
Me: And then enforced User Acceptance Testing?
Me: And allowed nothing into production without passing?
Me: Would it be better?
Manager: Yes, but we can't afford to do all of that.
Me: So, bug-free software isn't impossible, just expensive?
Manager: No, it's impossible. Get back to work.
Me: Sigh.
Manager: A web app is impossible.
Me: Why?
Manager: Because it depends upon data entered by regular people.
Me: So?
Manager: People are idiots. They enter wrong data all the time.
Me: What if we trained them?
Manager: Impossible. They don't work for us.
Me: What if we made the software smarter?
Manager: What do you mean?
Me: Data validation.
Me: Data reasonableness based upon rules or history.
Me: Crowdsourcing data validation.
Manager: The data would still be bad.
Me: What would it take to make the data good?
Manager: Nothing. Impossible.
Me: Sigh.
This is just a case of poor communication, people talking past each other. There's a big difference between the following two questions:
1. Can the proposed idea be implemented as stated?
2. Does the proposed idea degrade gracefully, i.e., will an imperfectly achieved solution provide significant benefit?
The answer to #1 is almost always "No" because the simplest way to state an idea, the normal way to refer to an idea in conversation, implies that it will work perfectly in all cases. For instance, "bug free software" is impossible in practice, but if you achieve nearly bug free software, you'll have much less buggy software than your competitors.
You can't talk sensibly about any idea without explicitly moving on to question #2 and talking about costs versus benefits. Will one bad data point in the Shop Control Application cause an accident that costs ten times as much as the efficiency gained? Will the value of "bug free software" be negated by a single bug in a release? If your boss is still talking in absolute terms about question #1, then you need to move him to question #2 by explicitly talking about what the benefits of an imperfect solution are. In your mind, it may be obviously implicit in your proposal that there will be cracks in the system, but you can't blame your boss for taking your proposal for "bug free software" literally unless you explicitly address how an imperfect solution will be useful.
To the contrary, with adequate rigor it can be done. Naysayer complaints of "that takes too long" forget that there is no subsequent time spent fixing bugs because there aren't any.
Using formal methods, the only place where you have near-perfect assurance of no bugs is between the spec and the code. You can't have a bug-free spec without bug-free requirements gathering and bug-free documentation. You can't have those without bug-free natural language communication. Also, a reasonable spec for a complicated piece of software is itself a complicated piece of code. If you can prove the spec is accurate by checking it against a smaller spec, and that spec against a smaller one, until you've reduced a problem of arbitrary size (say, the Eclipse project?) down to a reasonably human-checkable spec, then you run into complexity barriers. How is it possible to rigorously specify something as complex as Chrome or Microsoft Excel in a spec compact enough that you can certify it is error-free?
How is it possible to index the entire Internet's content, and perform nontrivial searches fast enough that a page of hits can be rendered as the searcher types? That may work on a small scale, but scaling up you run into complexity barriers. It's impossible in practice.
Oh, right, Google did it.
Your reasoning is exactly what the article criticizes: the notion of "that's impossible, don't bother" vs. "so what, let's do it anyway".
Our ability to handle complexity scales exponentially over time, and we're on a fast-rising part of the curve now; even if something is "impossible in practice" now, get started on the problem and predict at what point the industry _will_ have the technology to handle that level of complexity.
Hard != impossible.
Hard now != hard in the relevant future.
I don't want to be harsh, but I really hope you aren't really like that. This is really arrogant and you would hardly gain anything by acting like that. It seems like you are trying to demolish him by proving you are right instead of helping the team growing to a better solution.
Manager: A web app is impossible.
You: Yeah, I agree that it would be really hard to build,
but it would give us great advantages.
Manager: Maybe, but we can't trust data entered by regular people.
You: Yes, this is a pain to deal with. Fortunately, from
my past experience, I learned good ways to cope with that.
At the end, everyone agreed that it was well worth the
trouble. Anyway, I don't want to annoy you more with that,
I know you are really busy. Let me find the project I
worked on and let's talk about it later on.
So basically, here's your way:
Manager: "I'm the manager and I know what to do"
You: "Fuck you, I'm the coder and I know WAY MORE THAN
YOU"
Manager: (Don't like being contradicted by an employee..
even less being told fuck you): "I am right, here's why"
You: "Fuck you, I'm the coder and I know WAY MORE THAN
YOU"
Manager: (Don't like being contradicted by an employee..
even less being told fuck you): "I am right, here's why"
[..]
You: "Fuck you, I'm the coder and I know WAY MORE THAN YOU"
Manager: "No, you fuck you. I'm the manager and you won't
win"
Here's my way:
Manager: "I'm the manager and I know what to do"
Me: I know you are the manager and you choose what to do,
but as a programmer (and from my experience), I could help
you take the best decision.
Manager: But I'm still the manager and I WILL CHOOSE WHAT
TO DO, not you.
Me: Yes, totally. I'll get some facts about xyz and get
back to you, so you can choose the best thing for the team.
I don't think it is fair to frame it so dramatically. I think you're arguing for strong diplomacy in negotiation, which I completely agree with. You could presume the original dialogue was not indicative of absolutely perfect diplomatic practices, but to say he is extremely arrogant... I would say he is justifiably confident if he has encountered relevant situations many times before and an adequate technical skill set. Either way, to pass any judgement, we're making way too many assumptions.
And ultimately, isn't this irrelevant? They are just a few general, entertaining anecdotes. I hope you don't take Dilbert or The Office seriously as well.
In my experience, good managers would never take things that way. I read edw's post again just to be sure I didn't miss something. But none of his comments are malevolent, nor are they rebellious. They're calm, rational, and probing.
So correspondingly in my experience, only poor quality and insecure managers would get the same impression as you. High quality managers would value the feedback and expertise from their technical folk, and never take direct comments, questions, or contradictory points as insubordination.
It's the first lesson I learned in management anyway. You hire people who are smarter than you, and you correspondingly depend on them for the questions you hired them to answer. Direct to-the-point conversations aren't conflictive, they're productive.
I can't tell you how many times, I've told people, "OK, just tell me the point." Likewise, I can't tell you how many times people have told me, "OK, just tell me the point." People don't like wasting time with unnecessary chit chat when they can get things done, and if there's professionalism and respect in the group, there's no chance such a direct contradictory statement could ever be perceived as an FU.
Most people do prefer wasting time. It is the few that actually get things done that don't. If you think productive people are the majority, you have been really lucky in the places you have worked.
Manager: I pay you to know about this stuff. Also, it's
impossible.
You: No it isn't
Manager: (Likes wasting his money paying people then not
listening to them): I am right.
You: No you aren't.
Manager: (More interested in asserting schoolyard social
dominance than running a business) I'm not
listening la la la
You: *sigh* But....
Manager: I'm the manager and you wont win.
You: When we as a company do the impossible, we all
win. We can do it.
Manager: I don't care. I'd rather we all lose than you
win.
You: *sigh*
What if someone said it isn't impossible, but there are big challenges, and based on your skill set, you're likely to fail. It is those kinds of non-glorified situations where perseverance is crucial, but it can also lead to spectacular failure.
Isn't the point that "unlikely" is a vague (with negative innuendo)?
...and that a more rational approach is to say, "The value of a possible success" is high enough that it's worth the expenditure of energy to bet the "losing" side of a p = .01 (or whatever)".
[of course it's going to depend on who is expending the energy - and who get what portions of the possible success benefits]
It's a rhetorical bit of three card monte. Note that he seamlessly shifts from pursuing an absolute of bug-free software and instead offers some techniques for reducing bugs, which the manager deems more expensive than the gains they'd offer. Then he conflates "would be better" with "bug-free software" in a bit of snark at the end, and you can almost hear the eye-roll from the manager.
"In the end the project led nowhere, apparently there was a patent that it violated (of all things, one that had to do with the codes on laundry for hotels and hospitals held by Philips) but that by itself had nothing to do with the technology or whether it was possible to build this."
Hurray for the patent system supporting innovation.
I'm interested to know why they decided not to move forward anyway. Every entrepreneur I know personally (admittedly, mostly software people) is steadfastly avoiding looking at patents, figuring you don't have to worry about the patent problem until you are big enough that you might have some ammo to fight back, and they don't want the triple penalty for knowingly infringing. Maybe physical devices are thought of differently.
Guess how well this article encouraged the readers to go out there and do something.
When you think about the huge number of patents the big companies sit on, it's pretty much Russian roulette to try and to something new. At good chance to shoot yourself in the foot and waste a couple of years even if the idea works.
A caveat: In creating something, requisite domain knowledge is required. Know where your strengths and experiences are, how to leverage them, and be resourceful enough to obtain new skills. Don't be afraid to seek help.
I hate to say it, but the question "It's impossible?" is my kryptonite--but in the opposite perspective.
I accidentally established myself as a capable and competent worker at my job and have unfortunately given management the confidence that I can do anything. I'm using a negative context here because I've lost the ability to say no to them. I suppose since my job as a programmer is to give them what they want I should never want to say no, but I'm a sucker for elegance and I really try to avoid solutions that are overly complex and convoluted. Unfortunately, there are occasions in which a feature requirement requires such a solution. Or rather, not the actual feature requirement, just one of the "tweaks" they like to nitpick on to make it perfect. I.e "This is great, but you know what would make it perfect?" syndrome. Usually, I'm fine with these but when the tweak requires a complete overhaul or reimplementation--potentially days worth of coding to implement I'll try to dissuade them from it. Inevitably, if it's something they are really stubborn on when I say "well, I can't really do that--the system doesn't support event callbacks which is what would be required to implement...." I'll get back "It's impossible?".
And thats it, cat's got my tongue. I want to say yes. So bad. But I know the answer is no. I know they are confident in my ability, so they think they know the answer is no. But, seriously I'm gonna have to write a third party application in a different language and write a service protocol to communicate between the main ERP suite and the third party app to accomplish this and it's just so they can get an extra description feedback to an auto-complete feature. I know there are more important, more critical, more exciting issues that I could and I think I should work on. Whats worse, is that if I were a little less proficient, if I knew one less programming language it would impossible for me. Then again, it still wouldn't because I know I could just learn that one language and it would be possible. Arrrggghh there's no way out of this question.
"Well, no it's not impossible. I can probably do it. But it's going to take an extra couple of days.."
Management ahold be making those decisions based on ROI. That implies they are responsible for understanding the value the change will bring and you are responsible for educating on the costs. I would respond to the "It's impossible?" question with "Is it worth seven man days of work, a potential for tricky-to-find bugs because we adding a square peg to a round whole which will increase maintenance costs, and the opportunities lost by me not working on something else for those seven man days?"
I've worked at few places that have done the real analysis to know the answer to that, but very few even consider it.
You have to start using the words "risk" and "maintenance cost" when talking to managers then.
The main drawback to the solution you describe is not the "two days to develop", but doubling or tripling the complexity of that part of the application. It will be a pain to support and enhance in the future.
Manager: "Is it possible?"
You: "Yes it can be done, but you're basically making this application twice a complicated for this one feature. This makes deployment and support more complex, and if anything ever goes wrong, it will take a lot longer to even find the problem. If we ever want to upgrade the underlying software, this could break."
Yup, I know what you mean. In fact, when people explicitly tell me something is impossible I just take it as a challenge. And I often succeed.
Of course it usually takes me more than a couple days to do the impossible, but maybe you're faster than I am. ;)
Seriously, though, if there is a trade-off in feature value, the "agile" approach would be to point that out, and let them know what features they might be losing by having you work on one with only a lesser value.
Or in the words of a good friend of mine, if they're asking you to do it anyway, you're not charging enough for it. :)
One of the best problem-solving strategies I was ever taught was to respond to things like this with "well, what if it wasn't?" Don't try and fight their reasoning about why it's impossible, because you won't win - instead, step around it by getting them to ignore the part they're/you're getting stuck up on.
It takes a bit of persistence and convincing the other party to engage in what they consider a flight of mental fancy, but once you get over the "impossible" part and start figuring out how to solve the rest of the problem, I find that a solution that avoids the initially-impossible part tends to present itself. That, or you'll figure out why what you thought was impossible isn't. The beauty of this is that it works equally well when you're trying to convince someone else of something you know to be right and when you're trying to figure out a solution yourself.
The other easy strategy I use all the time (and this is more for concrete problems, as opposed to intellectual/theoretical ones) is start by deciding if the problem is one that can easily be solved by throwing money at it. If it can be, then it's a much easier question - you just have to determine if the problem is worth the money it would cost to fix it, which is simpler. If the problem can't be solved with money, then you know where to start to find a solution (enumerating all the non-monetary resources you have and seeing what might work).
This shows one of the reasons I love math: mathematicians only say "you can't do that" when they can prove you can't, otherwise they'll say "I don't see how to do it and it would be hard because ..."
In the case of some brutally hard problems there is virtually no difference. When yet another person claims that she proved that P=NP they usually don't read tha paper at all unless they feel that the author is a serious mathematician. Otherwise they should read amateur's papers all day long. To be honest they make fun of these people and basically they say: you cannot do that. And the truth is they are right with a 99.999999999999% probability.
Edit.:
In these extreme cases it may even do good to discourage people to deal with these demonically hard problems. If you are addicted to thinking these problems are dangerous. Such hard problems ruined mathematicians life. You can become addicted to solve the problem, but you cannot solve it so you try harder. There is no sign of success, so you try even harder... When I was thinking about P vs. NP for 1 month I could not sleep well and could not concentrate on my job well. It was terrible. After the dark period it was so good to think about business, software development again where there are problems (or at least subproblems) which you can actually solve or partly solve.
Great article. Whenever someone's usually said that to me, my first thought is usually, "Why not?".
From the other end, in my experiences, hearing "you can't do that" in a corporate setting has often (not always) meant that the manager/company didn't feel it worth the risk to the company. The manager won't be around 2 years from now when your project is completed, so he would rather you work on things with immediate impact so it benefits his review. Because of this big companies often get very risk averse, focusing on big, cash-cow projects and consequently slow their innovation.
Contrast that to startups where you've got a bit more freedom, I'd think you're less likely to hear it (if so, it might mean more of "we don't have the resources/money"). I think it's often less of the person being an ass, and more about what they're incentivized to promote.
If someone says: "That’s impossible;" You should understand it as: "According to my very limited experience and narrow understanding of reality, that’s very unlikely."
I find that the "You can't do that" is often said by people who just don't want to bother.
I was recently working in a company where the task tracking system wasn't linked in any way to source control. I thought linking the two would be a great gain: being able to see the modified files from the task management system, and resolving the task directly in the commit message would allow managers and developers to easily increase productivity, if only by a little bit.
I had to have 3 different meetings with the sysadmin to get him to do that, each one escalating further up in the company hierarchy. Eventually, we had to tell him exactly how to do it, and my boss said it had to be done. The main reason the sysadmin said he did not want to do it was that he felt there would be no gain.
I've witnessed more than one person set out to do something that requires them to have solved the halting problem (without realizing or knowing of it). Basic comp-sci education isn't all the value that some ascribe to it, but it's surely non-zero.
With a caveat added: "... in general". As mentioned by sokoloff, the halting problem is solved routinely by people in software engineering research groups. This does not invalidate the Halting Theorem simply because the Halting Theorem talks about the impossibility of a single Turing Machine FOR ALL programs.
If there is a proven theorem that something is impossible, either the theorem is wrong or it's impossible.
> the halting problem is solved routinely by people in software engineering research groups
I'm not sure how I'm meant to read this.
If it is that people do the solving of the halting problem (that is, people read the source of the program and say "this will halt" or "this will not halt"), then they have not solved the halting problem: the halting problem states there is no way to do this by algorithm.
If it is that people write software which solves the halting problem, then you are wrong, and you explain to yourself why you are wrong. They are solving a different problem, namely, whether some very small class of computable functions halts.
Your two sentences "the halting problem is solved routinely" (assuming you mean the latter case, as above) and "this does not invalidate the Halting Theorem" do not logically work.
> If there is a proven theorem that something is impossible, either the theorem is wrong or it's impossible.
It can get a lot more subtle than that. I do not want to elaborate, but there are classes of problems for which we can only guarantee SOME hard problems (or undecidable ones) but MOST of which are easy. There are other classes of problems where MOST problems are hard.
> Your two sentences "the halting problem is solved routinely" (assuming you mean the latter case, as above) and "this does not invalidate the Halting Theorem" do not logically work.
I agree it sounds illogical, but my phrasing was poor. I meant, if problem instances that arise in real life are easy to solve, yet there is a theorem that states that NOT ALL problems are easy, these two are not mutually exclusive. I agree "routinely solving the halting problem" is an exaggeration on my part.
Technically, the theorem doesn't apply. Actually built computers aren't Turing machines: their memory is finite.
The algorithm to answer if a program running on a deterministic finite-memory machine is trivial: Run until it either halts or repeats a state. Halting means it halts (duh); repeating a state means it doesn't halt. This algorithm is, of course, not implementable.
On these lines, there's lots of sharp restrictions and heuristics you can use to get problems out of NP into something manageable. And a lot of the time a decent approximation is good enough.
This is a motivational article, which is fine.
Some people (depending on their personality and their current state in life) need motivation: 'you can do that'!
Some other people, the born dreamers who are overly motivated and naive by default need experience, need to fail a lot to learn that some things are harder than it seems. (I am more in this category.)
But in reality there is a market for the belief of whether 'they can do that': (angel) investing.
If someone bets that people's capabilities are undervalued she should buy into the market (invest in early stage enterpreneurs).
If someone bets that people's capabilities are overvalued she should sell (not invest).
Saying 'you can do that' is cheap. If you really trust he/she can do that you invest. I think the market is balanced in Silicon Valley (some say overvalued) and undervalued in some countires where there is virtually no angel investing in technology startups at all. (Like where I live in Eastern Europe.)
In a similar vein....I am presently working in more of a business analyst / advanced end user for a product under development. I don't know how many times I've been told by developers on the project that something "can't be done". Some good fun was had for the first few weeks before they found out I was a developer, after a few times of sending them the code to accomplish "the impossible". But now it's just getting annoying...they still regularly fall back on the "can't be done" crutch, even when I tell them otherwise. Absolutely zero curiousity in learning something new....yet their considerable egos seem to remain fully intact.
Good advice. Generally when I give feedback on an idea or proposal that is not possible to implement I try to give it as "I see the following challenges, ... " and try to outline my reasoning for problems for which I am not aware of a solution to. If you come back with credible ways to attack those issues I'm all for it.
Its a big demotivator if you feel like you are being dismissed out of hand. So if you're managing a team or have folks coming to you with new ideas, 'you can't do that' is probably the worst thing you can say to them.
A coworker of mine shared an experience she had in college a while back.
Many years ago, for a course project, she proposed software that would allow you to tag songs and get information about it. Perfect for identifying that obscure song at a bar. The professor told her, flat out, it was impossible. He explained his reasoning and then suggested she work on another project.
All of this came to light when I showed her Shazam. Her first words were "I KNEW IT WAS POSSIBLE!"
That's not going to be useful for identifying that obscure song at the bar, is it?
The original post is pretty unspecific. Did the professor claim that creating a general system with a large database is impossible? That it's impossible as a term project? That creating a proof of concept system with 3 GB of music from your personal collection is impossible? That simply identifying a song given a part of it and the source file is impossible?
Personally, someone saying to me "You can't do that" is a great motivator. "You cannot get A+ in that class, it's impossible." == me studying way harder (and finally achieving that A). In fact, ironically, I always tend to do better when people think something is really hard.. maybe because I'd take it more seriously.
You know what, that card IDing idea is awesome. What sort if douchebag says 'you can't do that?' My reaction would be positive/excitement and a desire to contribute, but it seems there's just this large subset of people out there who react to every new suggestion with total stick-in-the-mud negativity. Like it's their natural, gut-instinct. Maybe they just never see ideas (like the card reader) as these wonderful elegant things, or they can't imagine enough about the rest of the problem domain to see it's potential value, who knows.
At my first job my whole team had to enter details on a shared spreadsheet. I suggested we set up data-validation or drop down menus for input, someone straight off said 'can't be done - someone tried it last year, didn't work.' then took me like two weeks of campaigning just to overcome this initial knock back. What a waste of time.
For many years I would bounce my ideas off of people, and they would look at me like I was delusional. This made me think I was delusional. After working on my MVP for the past 3 years, I have finally figured out that the best ideas are the ones that people say can't be done. With enough time and dedication anything is possible. Disregard the naysayers and keep on truckin'.
In this case the dedication factor is "Improve skills of average driver to the level of skill required by an airline pilot" (not an airline pilot driving his car, an airline pilot doing his "day job") and the time factor is "wait until that happens".
Subverting the dedication part using a highly reliable software solution is acceptable (self navigating carplanes).
Once you've got that down you've solved 90% of the flying car problem. IMHO of course.
EDIT: Of course - the real "end run" around the problem would be to answer the question "why do you want a flying car?" and address THAT instead of building a flying car. Would someone want a flying car if teleportation was available? I'm guessing "no".
Free electricity may be a pipe dream, which is understandably dismissed, even IMO (how could you get free energy from nowhere?). But a gizmo which pulls electrical or magnetic energy from the sun or surrounding space by some heretofore unimplemented and unaccepted method is not as much of a pipe dream. However it's just as quickly dismissed by academic physicists as a pipedream even though they don't know what specifically they are dismissing.
So I agree! Keep your confidence if you think you've got an idea that may work, especially when there's a bunch of people who have a vested interest in your device not succeeding, telling you that it won't work.
The bit about the patent is a little depressing. I wonder how many novel bits of technology were shuttered because some big company had some similar patent that they'll never use outside of lawsuits and as an asset for mergers and acquisitions. "We have the 'read security card with optics' patent. Its worth a lot!" Government mandated monopolies on ideas is just a bad idea.
Everytime I think about starting a company or investing in tech, stuff like thinks makes me reconsider.
I think they mean you can't do that because of the patents? Or you can't do that because it was already tried and it went nowhere, as the author found out.
1) Have problem
2) Find related discussion forum
3) Post problem, state or imply it's probably impossible.
4) Get much more interest and better answers than a plain question would have.
Those people just inherited preconceptions from their environment (co-workers, bosses, common knowledge...). Their brain never even tried to wonder if a new approach was possible.
I was originally met with opposition when I told my family about wanting to do freelance programming out of college. They wanted me to get a "real job".
I think this article describes the situation well. At first I was annoyed with them, but then I came to realize that the reason they were saying this was because they didn't understand what I was getting into, and from their perspective it really was impossible.
I have come to appreciate that they are not out to rain on my parade for the sake of being mean, but because they actually do care about me. I suppose that as with all criticism, discernment is needed.
This article is amazing, One of the best parts of being young is you don't have enough experience to know what you're not capable of. As a junior programmer I went down more misguided pathways than I care to remember, but every once in a while one of those misguided pathways had gold at the end, and I got there.
Though far from the level of difficulty presented by jacquesm, the same thing happened to me with an end-of-term project a few years back.
We had to make a small piece of software in Java. Most of my mates were going for boring stuff, such as sudoku solvers or small neural networks to play the likes of Connect four.
I wanted to make a Gameboy emulator.
"You can't do this", said my professor. "At least not in two weeks' time."
Well I don't remember much besides coding during those two weeks, but guess what - after 14 days, my program could boot Tetris. No sound, granted, but it was playable.
My professor was quite the sore loser though - he considered the program incomplete since it only booted a few roms, didn't have sound and could crash randomly. I ended up turning in a gameboy rom dissassembler instead, complete with GUI and breakpoints setting.
Still, never believe that "you can't do that".