vineet

Great post (and blog). I would love to see more discussions on this topic.

As an investor, Vinod Khosla's job is to make such bold statements. But his statement will never come true.

Even if you assuming that 'doctors' and 'humans' are old technolgy, whenever a disruptive technology has come to market the old technology has not gone away -- it is still used and is often a part of a growing market (this is partly why incumbents are often so slow to move).

Regardless, I think the right way of phrasing the above is that in the future 80% of medical needs will be met by technology. This statement is actually different from implying that 80% of doctors will loose their jobs, it is more that technology will help them do their jobs - either to service more people or to service more complex situations.

This is very cool.

Beyond the obvious benefit (as stated in the blog) for developers not needing code for db access, authentication, and the overhead of deployment, such apps can bring trust to a different level.

We can now have apps that store data in a location controlled by us users. Dropbox will need to support finer levels of folder access with their authentication, as well as support for making sure the apps don't access other sites.

Great idea. I like the ability to share with friends.

Some improvements/feature suggestions:

1. It will be helpful to have an easier UI to modify the css/js - something like what the stylebot chrome plugin does.

2. This gets into a nice place for discussing web sites within a team. I can imagine this tool being really helpful for Marketing teams.

3. The above might ask for features like the ability to replace some text, highlight other text easily, and add comments. You might want to consider something like WebNotes (http://www.webnotes.net/) for feature additions.

4. Similarly the above suggests charging options based on team size: publicly visible or 1 person teams would be free, but with larger organizations you can have a higher price point. Also paid users might be able to get get benefits like saving pages for more than 2-3 months and being able to create a report of the work that they did (for their bosses/clients).

I am the founder of Architexa, and have been pushing to make this happen for a bit.

I am glad to have made this happen.

Let me know if you have any questions.

Thanks for the pointer. I appreciate it. I am going to try digging up the reference.

I find it hard to believe though. Beyond the code reading challenges that developers have had, I have seen highly varying productivity in code bases that have different amounts of 'brittleness' (and code cycles). On some codebases developers even after understanding what is going on and understanding the change that needs to happen, developers can very easily spend hours making sure a line of code will actually work in different situations.

> More volume = more things to comprehend

I disagree. It is not that simple. If volume is similar code, then sure. But if you are talking about different styles of coding then you have a lot of other things to consider. On top of this, if you have a language that has very few underlying primitive (such as parentheses in lisp as opposed to [,;.] in other languages) then you actually have a higher comprehension barrier as the reader will need have to examine the role of the primitive as well. Basically, the terser the language the harder it is comprehend a LOC in that language.

On the research note, I do agree that most SW engineering research has focused on 'small problems'.

I like what Clojure is trying to do, but comparing languages based purely on LOC is crazy.

Its almost like choosing one car over another because the first one looks better even if it does not have an engine.

At the end of the day, languages help you write code. Comparisons on how much time it would take to write the code would be much closer to usefulness and would be interesting (even though they would have also have their own challenges).

This would be a really hard test to do in the real world, but I would like to see the code generated by 2 teams over a year - each having 4-5 people and each having similar experiences (ideally 10 years of coding background).

I think the spoof was created was because (a) app.net has no value proposition other than wanting $50, and (b) that there were over 100K people out there who put in money regardless.

(No value proposition is more accurately no value proposition for the site by itself. It does have a value proposition if it does billions of users like twitter, but that there is no realistic way of getting there.)

Yeah, but while Google docs does have collaboration features - assigning parts to different people is really hard.

I am not a fan of using another tool, but in my opinion Asana and Trello are light years ahead of BaseCamp (atleast the old version).

Previous (2 months old) discussion here: http://news.ycombinator.com/item?id=4085052

Thanks for sharing. My list has much more CRUD apps with different UI challenges (like a single person todo list).

This site looks good. But I wondering if someone has a similar list of apps that are one steps larger than just algorithms - must have UI and be useful.

Yup. 'Shipping' comes from the old days, when we were trying to ship a product to (from development to users). In the web era, this is as simple as publishing to a server, but you very quickly realize all the tiny things that you need to do to make something that people actually want to you.

When people are looking for older developers they are often looking for experience - for someone who have enough technical understand to command respect and lead a team of less experienced developers.

I do not believe that this first group would be the right fit for you.

However, there are some developers that are worth their weight in gold. In my opinion, age does not even come up in such discussions. These people are usually very good at one thing.

The thing that you want to be good at could be something current like Node.js (which will eventually become an old technology), or it could be something timeless - like 'shipping'.

My suggestion, try to be the person who has shipped multiple products. Think of the smallest products that you can build, then try to remove 99% of the features, while still keep them useful, and build them.

If you have a couple such products under your belt, I doubt that you will ever be job hunting.

I don't know if this is really done by Stack Exchange. If you look at the user 'Stack Exchange' it has an arstechnica e-mail associated with it.

Oh, In that case...

(I can't tell you how many times I have heard the same advice being given seriously)

I have found a particular/simple solution very helpful and I am surprised that people don't talk about it (or perhaps don't know it).

The basic idea is to, try to spend 1 hour on each of: 1. examine the code very quickly (try to do it in an hour or so), and based on the scan to guess what the top 4-5 subcomponents of a system are. 2. do quick code examinations to figure out what each subcomponent is supposed to be doing, and how each subcomponent is supposed to depend on the other subcomponents. 3. Now modify the code to reflect the above components. At the simplest, just move code into new directories for each component, but at more detailed levels you can make sure that there is never any single source file that has implementation for more than one component.

Now you are done. You can clean up code more if you want, but do that slowly. Just make sure to not put new code in bad areas. Yes, you will possibly have spent more than 1 hour on each part. But you should have a much better grasp of the code, and the code will not keep on deteriorating.

I am not really talking about badly documented code or code with bad naming conventions, or other related problems. However, when the big problem is the 'spaghetti' (and cyclic dependencies) - this has really been the only solution that has worked well.

Sorry, but this is really bad advice. It is very tempting to redo something from scratch, but in doing so you will end up spending a very large amount of time fixing issues and adding details that were already done in the original code.

Yeah. There is no value being added beyond just copying Stack Exchange.

Is Ars Technica in trouble these days that they are just copying content?

ESP?

I love the philosophy behind the annotated source for backbone. But, there seems to be something more going on with commenting - especially given that the content of the backbonejs.org homepage is different from that of the annotated source.

I guess the comments are meeting the needs of two different audiences (those looking at just the api and those looking ay the code).

Hmmm... this would be great especially for cases where you have documentation that applies to multiple methods or classes.

Ofcourse, the devil is in the details of getting it right.

I do want to support you guys.

But just having 10K people who want App.net successful is not enough to get me to put in $50 (or to even try it out for free).

Now, if this a community of a 100 entrepreneurs, I might be more interested. Perhaps, you guys need channels for various groups or something.

My point is that I cannot yet find an excuse to see why you will be successful and therefore would want to bet anything on you. Help me find that excuse :-)

Looks pretty.

I definitely want to support entrepreneurs and App.net. But, quite frankly I don't see how they are going to build a user base.

I have been trying to help with API Documentation as well (mostly because of my frustration as a user). My main focus currently though has been in helping you use the API of code as opposed to REST API's (because most people have languages wrappers).

Check it out: http://docmaps.io/

Hey guys, DocMaps.io is a fun project that I have been working on. Would love any feedback.

Glad to see the initiative sharing their notes.

As someone who has worked closely with MIT Faculty I did feel like one of their challenges would be in discussing and iterating on their learnings rapidly (as opposed to focusing on the learning quality them and seeing that they are of academic rigor).

The Gamification course (https://www.coursera.org/course/gamification) seems to be a great resource.

It is one of those topics that there is not too much helpful material online - so I am looking forward to it.

I used to think that PostGIS is not avaialable on Heroku, but this seems to indicate otherwise: https://devcenter.heroku.com/articles/is-postgis-available

The article does suggest a simple way of finding out if the plan supports PostGIS.