6-12 months learning how to code? Good luck building a business on top of software written by a junior-level programmer. Even better luck expanding and scaling it if/when the time comes.
It takes years to reach a reasonable level of competence in software development and on the order of a decade to master it.
The problem with taking people's word on how much work they do when they are involved in marketing and the soft sides of business is that they have a disproportionaly (as compared to tech specialists) large amount of experience in marketing, negotiation and soft skills. Hence, they market themselves and over inflate how important their contribution is. In my experience.
Acknowledging that most people won't be a very useful developer at that stage, I always propose a different approach..
I tell the person to sketch out the how a user moves through the app, what they can do where, and how it should work. I even tell them to sketch out something basic with powerpoint.
If they make it through those stages, it does two things: First, it demonstrates that they're relatively serious about the idea. More importantly, it lets them get a bunch of the oddities, inconsistencies, etc figured out before there's code involved. Making radical changes at that point is File->New.
First thing I tell people who ask "how would I get started?" 1) talk to people you think might want to use what you have in mind and see what they think and 2) build it on paper, because no matter who ends up building it, your ability to clearly express what you want in a very literal way is going to be key to getting what you want.
> Good luck building a business on top of software written by a junior-level programmer. Even better luck expanding and scaling it if/when the time comes.
You're absolutely right that this isn't scalable, but if you're just looking to validate your idea why shouldn't an app made by someone with a few months of experience suffice? Once you've proven there's value in the idea with the prototype, I imagine it'd be a lot easier to get more experienced developers on board.
Yes and no. The problem is that most of the time the train of thought goes something like:
* we already have a working product
* we might aswell just add the features and visual polish we need and then launch as soon as possible
* we have too much work to do to rewrite it
* we can't refactor effectively because automated tests are mostly missing
This results in the project becoming increasingly burdened with technical debt, where it becomes impossible to add new features without breaking something. The next step after this is usually a rewrite (which, given the low quality of developers already in the company, since nobody sane will work on such bad code, is also likely to fail, unless IT is restaffed completely).
If the prototype is binned outright and the rewrite happens at the very start, I imagine that this can be avoided. Again, the trap here is that if the founder learned to write code in 6-12 months then they will be in that cute phase where they think that programming is easy and will not realise this.
In short, having a senior developer on board (at the very least as a consultant) from the very start appears to be mandatory for long term success and minimisation of headaches. It's just what I've seen in the real world. Companies which went for quality from the very start grew rapidly. Those which attempted to minimise development costs at the expense of quality did not reach the heights.
I just got off a short contract where this exact thing happened. The company had a MVP they were using that was made by the founders. They were obviously young and inexperienced. The code was awful to say the least. I told them straight up it would be best to just throw all this code away and start again from scratch. Its best to do it now while the company is young, rather than much later. They were neck deep in technical debt.
They claimed it would take "a really long time" to rewrite everything. I can understand a junior developer thinking that (it apparently took them 2 years to create the code they were using at that point). But using good engineering practices, building a site that did what they needed could have been done within a few weeks using Django and MySQL. Its really hard to make this point stick when you're dealing with developers in that "sophomore zone" of programming ability.
Needless to say, they told me "no way jose". I ended it with them right then and there. I can't tell you how many times I've seen that happen.
Depends on how complex your MVP is. The problem for non technical people is that they probably don't know how technically challenging the problem is.
If it's a cat pictures site maybe a few months is enough to learn enough code to validate the idea. OTOH if you want to build a search engine maybe not so much.
Novice with 7 months of learning here.
Quit my strategy consulting job to focus full time on learning to code, and am currently working on this project, built in Rails, on Heroku (it's all in Japanese, but the concept is similar to Hacker News/Reddit)
http://www.daidake.com
Is this a bad idea? Would like to hear your thoughts.
I have to admit I do feel like I'm in a little bit over my head, in that once/if I start getting a lot of users, I really have no idea how to scale this thing. I figure I need to start networking to find a brain that wants to team with me.
I'm glad I've learned to program though, even if at a beginner level. If this fails (I already have a previous project that was a resounding failure), I can test out new projects easily.
I don't think it's a terribly bad idea. As someone said above, doing at least some of the technical legwork yourself will buy you a ton of credibility with experienced programmers when you go to hire. It often becomes somewhat insulting to developers when he/she has to argue schedule with someone with no experience. Often the client thinks it should X should take Y long, and you're telling them that X might not even be possible, but you can do X' in 4 or 10 Y. "What do you mean? You must not be as skilled as so-and-so said you are."
However if you've fought even the initial stages of the battle yourself, you understand the idea of the vision, and the reduced scope which is your next step toward the larger goal. Further, we understand that the part of the learning curve you're in right now is the steepest, and if you're willing to endure it you're either stupid or you really do believe in your business.
> you're either stupid or you really do believe in your business.
haha, I'll refrain from trying to answer that for now ;)
You're right in that by far the most challenging part of the learning so far was the first day, and trying to get rails working on a Windows PC. For a person with no technical background, it takes a huge amount of persistence or stupidity to get past that stage.
I actually learned to program so that I'd be in the position to build my own MVCs. The idea came to me as I was learning.
I don't have a lot of money, so I figured the only way to win over a good developer was with credibility (an actual product that at least somewhat works and has some traction).
I appreciate that resources are always tight in these situations so I would recommend that you hire an experienced developer to review your code. It's cheaper than hiring someone full time and you should still be able to get a lot of value out of it. They will know about nuances and gotchas that only years of working on code can teach. Addressing those early rather than late is probably a good idea.
A cheaper (no money but more time spent) alternative is to use forums and IRC channels to get advice. There are plenty of knowledgable people who are more than willing to help if you ask.
Some basics which are vitally important to cover are ensuring that the object model and database schema are solid and extensible, that there are automated tests in place (especially for business critical functionality), that everything is documented (otherwise you will waste inordinate amounts of time explaining how things work to any developers you hire in the future and/or relearning parts of your own code after forgetting what it does) and that everything is backed up to multiple locations. Addressing those concerns puts you well ahead of the pack.
That's normal when you're starting out. The only reason more experienced developers do not give into this impulse is because they've learned of the consequences through painful experience.
I would recommend looking at the people who contribute to Rails, Ruby and related projects on Github. The core developers will be far too expensive but people who throw some code out every so often (assuming that their pull requests are usually accepted and nobody is shouting at them in the comments) will likely know their stuff and may have reasonable prices.
IRC channels on Freenode such as #ruby and #rubyonrails will likely prove useful too. Look out for people who answer a lot of questions (and get them right). One strategy is to try to design a solution for a feature by yourself, then summarise the design (i.e. show the relevant code snippets) in a Github Gist or pastebin page and ask for feedback. If there are any glaring faults or simply better ways to achieve the result then they will be pointed out to you.
Re: where to find experienced developers with no tech connections, that's not really a problem. Here's why: It's similar to a man asking, "Hey, know any models I can date?"
Actually, beautiful women are hardly rare. But it's the qualifier that's important: "models I can date??"
Good developers might be rare, but they're not hard to find. They are, however, hard to woo. You know the drill on how to woo them, it's just inconvenient/hard/expensive. But at least it's pretty well laid out.
I heartily agree that good code makes sense on it's own.
One of the things which good code and inline documentation (comments) do not communicate very well is a high level overview of the architecture of the application. In my opinion, it is better to describe such things using external documents and diagrams.
The same goes for the deployment procedures and the way the servers are laid out as well as dependencies. For example, the place I'm currently at had no documentation what-so-ever for the libraries and modules necessary to run the in-house web application and, consequently, it took us more time than it should have to figure out what needed to be installed when we moved to a new server.
Thanks for the book recommendation, seems like a great one judging by the reviews. It's always useful to learn more - will add it to my 'to read' list.
> is this a bad idea?
Well, what do you bring to the table? Do Japanese people read HN or reddit, or are they hindered by the language barrier? If they are, then it's not.
Damn, ideas are never bad. As long as you do stuff, it's all good.
Yeah, Japanese people are shockingly bad at English. The idea is for Japanese users that CAN read English to provide short summaries of interesting English articles. While the Japanese media is pretty open and liberal, there are still some topics of (possible)importance that never make it into the headlines there. The US media isn't necessarily great, but if you can read English, you have access to A LOT of info to form your own opinion.
I think that the point is more to demonstrate that "Hey, what I do takes a lot of skill and expertise, it's not just something you can throw together in a weekend". If an idea guy wouldn't be willing to invest at least a year to learn how to do it themselves, the idea's probably not as great as they think it is.
I am nearing the end of a "crash course" code lesson and have no intention of creating a company on this knowledge anytime in the near future.
However... I would like to start building out some of those "annoying itch" ideas I have been sitting on and feel this enables me not only to prototype those out, but also allows me to have a half-intelligent conversation about my idea with someone who is a far better dev than me.
> However... I would like to start building out some of those "annoying itch" ideas I have been sitting on and feel this enables me not only to prototype those out, but also allows me to have a half-intelligent conversation about my idea with someone who is a far better dev than me.
Oh man, I can't tell you how much instant respect this would gain an "idea guy" who contacted me for development. If you've already tried to prototype your idea, it would tell me that not only are you dedicated, but you will also not underestimate my contribution to the endeavour.
you're too easily offended. He only needs to learn enough to implement one idea: his own.
Are you saying you are only capable of implementing one idea? Then maybe you should work on that, instead of taking offense at other people learning something new.
It takes years to reach a reasonable level of competence in software development and on the order of a decade to master it.
The problem with taking people's word on how much work they do when they are involved in marketing and the soft sides of business is that they have a disproportionaly (as compared to tech specialists) large amount of experience in marketing, negotiation and soft skills. Hence, they market themselves and over inflate how important their contribution is. In my experience.