783 karma · joined April 12, 2008
Previously: PhD in CS at MIT. Worked at ACN, MSFT, MOT, etc.
Find me at https://twitter.com/VineetSinha
E-mail me at: vineet dot sinha at gmail.com
However, if you are making a case for standards in this space - I agree.
In my experience there are often a large set of work that is left when a big production release happens - from the minor like bug fixes and features that were deprioritized to the bigger and often more urgent ones like performance problems and non-validated 'shadow beliefs' being tested.
I would recommend sticking with your original plan, but making sure to spend the next week or two to mentally prepare the team that they are likely only just finishing the boring 1/3 of building software and going to start making an impact in the 'real-world'.
The two big tips that I think have worked best for me over the years, is:
- Let your code repository do most of the talking. I don't stop a work session without committing what I have been working on, and therefore I work really hard to split any work item into small chunks. Also, given that I am sometimes interrupted in the middle of some work, it really helps to try to get the code committed after every few lines of work.
- Keep the management tooling really simple, the more complex it is the harder it will be to manage. I have evolved into keeping 2-3 types of documents (in evernote): an operations cheat sheet (how to start the code, and manually how to do things especially if I have not automated it) and 2-3 types of todo lists preferable on one page (some which I need to do in an hour, others which would be good to do, and finally some which will revolutionize the industry :-) ).
I would argue that both should be required for any college degree. And yes, they are not the same as a 4-year degree. And those that do the 4-year degrees should have enough more knowledge and experience that people want to hire them as well.
I think there is more of a problem with the lack of great 4-year degrees as opposed bad 6-week bootcamps.
Thanks for filing the issue. I will reply there.
I noticed that some of the docs require a login, for ex: https://wpcalypso.wordpress.com/devdocs/design Anyone know if this is a bug, or part of the new approach?
Maybe they need to create a 'Google Reader' :)
[edit: fixed typo]
If you are building a video hosting service for businesses, do you know what they think of your business?
One suggestion would be getting someone unbiased to look at your competitors websites and your website and to pick who the top 2-3 solutions that they would evaluate.
If bills have to be paid, then pick up a job. But before you spend it on someone else, make sure that you are spending it on something that will have results.
One thought is if your product is in a mature space, I would recommend innovating with the channel. Maybe target a lower cost do-it-yourself customer? You will want your marketing (design, pricing, outreach/ads, and feature additions) to line up with that.
Not sure if this is the right reason to do so, but I have 'flagged' the link for this reason.
1. The Mile High View: A layered architectural diagram can be really helpful to know how the main concepts in a project are related to one another. 2. The Core: Try to figure out how the code works with regards to these main concepts. Box and arrow diagrams on paper work really well. 3. Key Use Cases: I would suggest tracing atleast one key use case for your app.
The bigger challenge in my opinion is that this is a two sided market (and building such business is very hard).
But even if it is not being used yet - do we know if Facebook uses Typescript (or some extension of it)?
Interesting to see references to TypeScript. Is it prevalent at FB?
- Meet your customers needs: I don't really know what this means, make sure to hear from those that are using it right now, and those that will say that they will do it. You might end up getting feedback to add features like: a) Templates: You support only OpenOffice templates? I believe it should not be too hard to support more formats like RTF, Text Documents, and MS Office documents. b) API: Supporting Node.js, Java, and other languages. You might want to look at a site like Stripe.com for examples on how to structure developer documentation. c) Output: Perhaps supporting HTML outputs as well as PDFs.
- Homepage: I think your homepage looks good, but can get much better. It might be a good idea to find similar/adjacent companies and see how they do their homepage. I think you should move the 'reasons to use' further up the page.
- Pricing Page: Not sure if I really care about the number of servers running. Also, jobs per day - are you really expecting that many users? I think you might want to significantly reduce the amount of usage per day in each tier. I think you will also likely want to tier on different criteria - perhaps support, keeping a history of converted documents, and others that your users will ask for.
- Conversion: Are you tracking what percentage of visitors are converting to signup? Are you trying A/B testing different prompts to them?
- Driving Traffic: You could think about doing guest posts, blogging on your site, buying ads, and building integrations into other tools to drive traffic.
You should have a broad agreement before you go to the lawyer. Are you thinking about a 50% share in the company or a 1% share in the company. You need to talk about it and be on the same page. After you talk about it, I would just get a confirmation via e-mail. Some documentation is better than no documentation. (Yes, you ideally want a lawyer looking at it, but it also would be a legal liability for him if there is a rough e-mail agreement that he hasn't given you shares for).
The idea guy will likely want you to be working full time on the company. I think your answer should be something of the order of 'Yes, as soon as you are also full time meeting goals XYZ and that we have enough runway to pay me 50% salary for 18 months'.
Until the company exists any work that you have done you own it (unless he has paid you and you have explicitly assigned the IP to him).
If he waits for investors before incorporating, there is going to be a tax situation (because then the company will be worth something). You ideally want to incorporate and value the entire company in the beginning at $1 or something similar.
Most investors will likely want the technical talent that they are investing in. If he gets good investors then they will likely want you to have an comparable share in the company as him. However, in my opinion, your worst case scenario is that he could say to the investors you are not too important, and that he can toss your code and get it built offshore for cheap (which might be easy given that there is an already working prototype).