Herd mentality. Work in the same kind of startups, with the same kind of people, drink in the same kind of bars, live in the same trendy neighborhoods, date the same kind of chicks/guys.
It's kind of amazing that every once on a while something original actually comes out of all this.
>What are the chances this book will be reviewed by influential critics? Intuitively, I'd say close to zero.
In that particular genre, in the UK market, you'd be incorrect. For a better understanding of where the books sales fit in terms of crime writing in the UK, there was an excellent piece written by Kristine Rusch a couple of days ago.
Couple of things spring to mind. First, regarding the articles:
Article or blog traffic is a long term strategy. You shouldn't expect to see a real return for 6 months to a year, and when the return comes, it stays for years. You should be writing a blog yourself, not farming it out to jokers on fiverr -- that's if you want to go down that route. As I said, it's a long term thing, and not everyone or every business is suited to it, as it takes a regular and continuous work.
Second:
>I wasted too much money on AdWords
>As of now I've put about 300 dollars into AdWords and it has all been completely wasted.
That's peanut and pizza money. You should have spent that running an ad campaign before you wrote a line of code. Seriously though, if you can't afford to spend $300 on advertising, you haven't got a pryer of generating traffic in the early days. And without traffic, you have no sales. And without sales, you have no business.
The Linq answer is fine for an academic exercise, but it doesn't handle any of the myriad edge cases that pop up when such functionality meets a live product with actual users.
I say this as someone who has built a 'word counter' as part of a commercial product. We tried Linq, but had to abandon it due to speed issues as well the sheer number of edge cases.
"var words = s.Split(' ');"
Example edge case: Words separated by an em, en, or ordinary dash. In the first and second cases, they're two words, in the third, a single word. The basic Split by space function is insufficient for all but the most basic interpretation of a 'word'.
In terms of speed, that 20% becomes significant when you're processing millions of words, not a short Wikipedia article.
Expand the 'word counter' function to become a unique 'phrase counter' and you have to toss Linq out the window.
We're actually starting a rewrite of an old Windows product next month. It was first released in 2005, and it simply doesn't stand up anymore -- looks like a Windows 3.1 product trying to run on Windows 8 -- but it still sells. It was our first product, which meant a terrible code base, shocking feature creep, and a hundred and one mistakes made at every level. We considered using some of the old code, but the logic is so entwined with the GUI that it's simply not possible. First product sins!
We're using the rewrite as an opportunity to re-brand it as a new product, removing 40% of the old features, and adding just a tiny number of new ones. Our hope is that the rewrite will keep sales coming in for a few more years. The rewrite should be made easier by the fact that the 40% of features being removed are the most complex (and worthless) features -- the price of listening to the small number of techie early adopters, who we've now learned to ignore.
Really looking forward to rolling out the new version.
A landing page about the product - as if it's almost ready - and a series of Google ads. $200 of ads can tell you a heck of a lot about traffic, keywords, click thru, etc. And that tells you a heck of a lot about whether your potential product has potential.
If you ask people would they use X, many will say yes, sure they would. And they'd be lying - not intentionally, but lying none the less. Their search activity doesn't lie.
Almost all of our products use one or more third party components, so we could never release the code.
Another reason is that for many of the products, the code is really, really bad. Now, the products all worked fine, and still work fine, but we wouldn't like to release an embarrassingly bad code base. Who would?
Seriously, the code in many (if not most) closed source products, especially old products that have had years of development from many developers and years of bug fixes, can be very very unpleasant to look at.
>Writing lots of code quickly is not a good thing. You shouldn’t be writing more than a few lines of code per day. And if your editor is helping you write a lot of code really quickly, it’s encouraging you to write bad code.
Here speaks a man who has never worked on a green field project, never built something from start to finish, never had to write more than a few lines of code a day.
How many programmers would it take to build a new version 1 product if they're all writing just a few lines of code a day? Would 10,000 do the trick, with six months to finish? There's a time to talk, discuss, prepare, plan, draw stuff on whiteboards, etc. And then there's the other time, when you sit down and build the product, which means writing all the code.
I'm not talking about an app that displays a random number, in which case, fire away with your few lines a day, and you'll be up and running in a few days. I'm talking about products with a capital P.
I'm starting the coding work on a new version of an existing product the week after next, and I'll be spending 15 solid 8 hour days writing code. I've made the plans, sat in the meetings, tossed more than half the features over board. And now comes the time to actually build it -- or at least, a first iteration of it before I get hit with user feedback.
I recognise myself in your story. I took off with a backpack before the ink had dried on my last exam paper. I look back on those years now, 15 years later, and wish I'd had the courage to walk off earlier. In retrospect, it's obvious to me that everything I learned at university I learned in year 1. The remaining years were simply "finishing what I started" because a "degree is good to have."
We're all different, and we all get different things from formal education. If it's not for you, do your future self a favour and don't waste the time.
I'm four months into a new corporate job after running into financial problems towards the end of last year. I didn't shut my business down, but things had gotten very dicey financially, making it necessary to get a regular pay check. I don't do much work on my own business these days (desktop, not web, and few support issues to handle), but I do have one product released late last year that is starting to show real promise.
The day job is driving me nuts. I thought at first that I could easily give it a year and a half, but now I'm counting the days to when the financial mess will have cleared up enough to resign - 2 more months. Maybe it's the company I'm working for (evil banking software), but more likely it's me. I have great difficulty working for someone else on one small part of a huge, 10 year old product.
Over the past 4 months I've drawn up a detailed plan for the new product that I released last year, and I'm sure it's going to work (heard that before). Roll on July 1st. I feel bad about the company I'm now working for, knowing that I'll be resigning soon and that I'm effectively using them, but not bad enough to stay.
It's kind of amazing that every once on a while something original actually comes out of all this.