I looked at old data for that 0.3% figure. The percentage has risen since then, and as of last year the estimates are 1 - 3%, depending on who is estimating. Also, entrepreneurs have caught on to the problems with VC money and the number of startups seeking or accepting it is declining.
It's my understanding that what makes a person a VC is when they fund somebody else's endeavor.
More accurately, it depends on the means by which you expect to recoup your investment. If you're giving a loan or gift, that is not being a VC.
A VC, by definition, is taking an equity position: that is, they expect to get their money back through a share in profits rather than a fixed (or no) repayment schedule. That's why some startups seek them -- VCs invest in businesses that are too risky for traditional lenders to touch.
If you've funded a startup, then by definition you are its VC, even if you would not otherwise be considered a VC.
Only if you are the "money man". If you are funding your own startup, you are not a VC.
And, really, even if you are the "money man", I would say that you aren't a VC unless your purpose in investing is as a business activity (as opposed to, say, funding your child's startup because you're doing them a favor).
I want 8-10 hours on a charge. Even then, though, charging things is an irritation I could do without -- but would settle for it if necessary (for now, it's not necessary -- I can still get phones that have a headphone jack, so I'm good).
I also neglected to mention the other necessity that your recommendation, as well as those of other people who brought up bluetooth headsets with long battery life, doesn't meet: I want earbuds. Over-the ear headphones drive me nuts unless I'm listening in a private place, alone.
Good commenting + unit tests will be better than any word doco.
Perhaps we're having a language problem here. In my view, good comments (which are unbelievably rare, in my experience) and unit tests are a form of documentation.
But neither of those are sufficient by themselves, because they're very close-up views. You also need documentation that is from a greater distance. Again, though, this doesn't have to be in form of word documents. Meeting notes, memos, email exchanges, etc. -- all of that is documentation.
Computer engineering is not like any other kind of engineering that it's cool to just improvise as we go along. A colleague of mine describes our job as re-engineering the airplane while it's in the air.
This is often the case, but not because there's anything special about software engineering as opposed to other engineering (there isn't).
It's that way because too many software engineers have absolutely awful engineering habits, and topping the list is the documentation problem. Your colleague's comment highlights this problem -- if that's the way your job goes, then your engineering process is broken.
This allows for experiments, A-B testing, ongoing user/customer inputs and even sensible scope decreases/increases.
You aren't recording the results of those experiments, testing, and conversations? If not, then you're wasting your time and effort doing those things at all. If so, then you're creating documentation.
I start creating documentation the moment that I'm being given specifications for the project. I call them "notes", but they're also critical documentation that is as important to the project as source code.
When they can be bothered they tend to forget that the documentation isn't for themselves - it's so other people can readily understand their solution to a problem and execute that solution reliably.
And for themselves in the future. When you have to revisit code you wrote five years ago, it is effectively no different than if someone else wrote the code.
I've heard a lot of programmers make the claim that good code should be self documenting and while there is truth to that
There is truth to it, but the truth is limited. Well-written code tends to be self-documenting in the local sense -- you can look at a file and understand what is being done in that file. It does not tend to be self-documenting in the big-picture sense, and is not self-documenting at all when it comes to the "why": why was this engineering decision made the way it was? What was the tradeoff here? What were the risk assumption? Etc. Those questions can become crucial to have answers to, and the answers are often opaque even in the best-written code.
On the other hand, there is something worse than no documentation: misleading documentation.
Good engineers write good documentation.
This is 100% correct. If you write stellar code but terrible (or no) documentation, you are not being a good engineer. You are being a code jockey.
The bigger issue is just getting developers to write documentation in the first place. That's a situation that's gotten even worse with the rise of "agile" methodologies.
New uses don't count, since even old devices can be put to new uses. I'm talking about the phones themselves. Besides, using a Bluetooth keyboard isn't remotely new -- I've been doing that for years.
I don't fall into any of those categories, really. I'm a developer, but I stopped doing iPhone and OSX development a few years back. I'm also exceedingly security conscious, but I don't need (or trust) a manufacturer to take care of my security for me. I also want to do things with my phone that aren't possible with Apple's walled garden -- it's not nearly spacious enough. Android is the only platform that gives me the ability to do the things I want and to be secure about it.
Or, to put it more simply, I am not Apple's target market.
I definitely wouldn't sweat paying for a good set of Bluetooth headphones.
I have yet to see a set of Bluetooth headphones, at any price, that can adequately replace wired headphones for my use case. The battery doesn't last nearly long enough.
The smartphone market is officially mature, as indicated by the fact that even Apple can't come up with anything other than incremental improvements and gimmicks.
Much like "small business". Seriously, look at specific companies named when talking about "small businesses". More often than not, they're not small -- they're just not megacorps.
are you going to buy a second ticket to see it again? Hell no. You already know the plot twist and seeing it again... well, no.
A truly great movie does not rely on a twist ending for its entertainment value, and can be enjoyed just as much (but for different qualities) on repeated viewings, despite knowing the "twist".
Slashdot Mirror
I think the question was what the actual accuracy is, not what the claimed accuracy is.
I looked at old data for that 0.3% figure. The percentage has risen since then, and as of last year the estimates are 1 - 3%, depending on who is estimating. Also, entrepreneurs have caught on to the problems with VC money and the number of startups seeking or accepting it is declining.
BS.
You might not believe it, but it's true -- and by a very wide margin. The most recent estimates are that about 0.3% of startups use VC money.
Most startups never seek VC money (for really good reasons -- VC money is very expensive, and you don't want to touch it unless you're desperate.)
It's my understanding that what makes a person a VC is when they fund somebody else's endeavor.
More accurately, it depends on the means by which you expect to recoup your investment. If you're giving a loan or gift, that is not being a VC.
A VC, by definition, is taking an equity position: that is, they expect to get their money back through a share in profits rather than a fixed (or no) repayment schedule. That's why some startups seek them -- VCs invest in businesses that are too risky for traditional lenders to touch.
If you've funded a startup, then by definition you are its VC, even if you would not otherwise be considered a VC.
Only if you are the "money man". If you are funding your own startup, you are not a VC.
And, really, even if you are the "money man", I would say that you aren't a VC unless your purpose in investing is as a business activity (as opposed to, say, funding your child's startup because you're doing them a favor).
I want 8-10 hours on a charge. Even then, though, charging things is an irritation I could do without -- but would settle for it if necessary (for now, it's not necessary -- I can still get phones that have a headphone jack, so I'm good).
I also neglected to mention the other necessity that your recommendation, as well as those of other people who brought up bluetooth headsets with long battery life, doesn't meet: I want earbuds. Over-the ear headphones drive me nuts unless I'm listening in a private place, alone.
Speaking of which, it would be nice if SSH over wifi/bluetooth was a first-class thing on Android.
True. But it's pretty easy to install an app for that.
Good commenting + unit tests will be better than any word doco.
Perhaps we're having a language problem here. In my view, good comments (which are unbelievably rare, in my experience) and unit tests are a form of documentation.
But neither of those are sufficient by themselves, because they're very close-up views. You also need documentation that is from a greater distance. Again, though, this doesn't have to be in form of word documents. Meeting notes, memos, email exchanges, etc. -- all of that is documentation.
Computer engineering is not like any other kind of engineering that it's cool to just improvise as we go along. A colleague of mine describes our job as re-engineering the airplane while it's in the air.
This is often the case, but not because there's anything special about software engineering as opposed to other engineering (there isn't).
It's that way because too many software engineers have absolutely awful engineering habits, and topping the list is the documentation problem. Your colleague's comment highlights this problem -- if that's the way your job goes, then your engineering process is broken.
This allows for experiments, A-B testing, ongoing user/customer inputs and even sensible scope decreases/increases.
You aren't recording the results of those experiments, testing, and conversations? If not, then you're wasting your time and effort doing those things at all. If so, then you're creating documentation.
I start creating documentation the moment that I'm being given specifications for the project. I call them "notes", but they're also critical documentation that is as important to the project as source code.
Creating documentation is sharply distinct from design and implementation.
I couldn't disagree more. Creating documentation is part of design and implementation, not something distinct from it.
The majority of documentation is not for the end user, it's for engineers working on the code.
When they can be bothered they tend to forget that the documentation isn't for themselves - it's so other people can readily understand their solution to a problem and execute that solution reliably.
And for themselves in the future. When you have to revisit code you wrote five years ago, it is effectively no different than if someone else wrote the code.
I've heard a lot of programmers make the claim that good code should be self documenting and while there is truth to that
There is truth to it, but the truth is limited. Well-written code tends to be self-documenting in the local sense -- you can look at a file and understand what is being done in that file. It does not tend to be self-documenting in the big-picture sense, and is not self-documenting at all when it comes to the "why": why was this engineering decision made the way it was? What was the tradeoff here? What were the risk assumption? Etc. Those questions can become crucial to have answers to, and the answers are often opaque even in the best-written code.
On the other hand, there is something worse than no documentation: misleading documentation.
Good engineers write good documentation.
This is 100% correct. If you write stellar code but terrible (or no) documentation, you are not being a good engineer. You are being a code jockey.
The bigger issue is just getting developers to write documentation in the first place. That's a situation that's gotten even worse with the rise of "agile" methodologies.
New uses don't count, since even old devices can be put to new uses. I'm talking about the phones themselves. Besides, using a Bluetooth keyboard isn't remotely new -- I've been doing that for years.
I don't fall into any of those categories, really. I'm a developer, but I stopped doing iPhone and OSX development a few years back. I'm also exceedingly security conscious, but I don't need (or trust) a manufacturer to take care of my security for me. I also want to do things with my phone that aren't possible with Apple's walled garden -- it's not nearly spacious enough. Android is the only platform that gives me the ability to do the things I want and to be secure about it.
Or, to put it more simply, I am not Apple's target market.
Well, OK, that's not the only thing. The other thing (besides sounding good) is that I want them to be earbuds.
I definitely wouldn't sweat paying for a good set of Bluetooth headphones.
I have yet to see a set of Bluetooth headphones, at any price, that can adequately replace wired headphones for my use case. The battery doesn't last nearly long enough.
Then where are these interesting new smartphones?
I dunno, between the two the 8 looks like the more desirable phone to me.
The smartphone market is officially mature, as indicated by the fact that even Apple can't come up with anything other than incremental improvements and gimmicks.
Much like "small business". Seriously, look at specific companies named when talking about "small businesses". More often than not, they're not small -- they're just not megacorps.
are you going to buy a second ticket to see it again? Hell no. You already know the plot twist and seeing it again... well, no.
A truly great movie does not rely on a twist ending for its entertainment value, and can be enjoyed just as much (but for different qualities) on repeated viewings, despite knowing the "twist".
That's the segment of the market that salespeople are useful for.
That's the segment that salespeople will heavily exploit. Commissioned salespeople will exploit them even more energetically.