rayvega

My enthusiasm deteriorated very quickly upon discovering that the wireless did not work out of the box which immediately negated the main reason for my purchase.

I am someone who writes code for a living (and for fun) and I found the experience disappointing and frustrating. Imagine how your average non-technical consumer would feel.

http://news.ycombinator.com/item?id=935545

That might not be the case. One of their other products ReSharper, the .NET equivalent of IntelliJ IDEA, is popular in the .NET world. Perhaps that is doing better in sales and they are shifting their attention on what has greater growth potential.

Maybe it is another sign of C# supplanting Java as the more trendy development language for your average developer?

and their original interactive shell just for Python: http://shell.appspot.com/

(at least for the dynamic languages)

Software and technology more than ever is everywhere and becoming so deeply embedded in our lives that the demands for great programmers shall continue to grow to feed those needs.

It surprises me to read this, when most other times all I seem to read about is how a "shortage of engineers" exists in the world.

Are developers at Google as productive as they can be even sharing an office with 3 other people? Does it not matter if you are a certain caliber of programmer that shares an office with others of the same or similar caliber and level?

Perhaps those who work at Google have greater self-discipline and awareness to know when collaborating starts to cross the line into interrupting someone so the need for private offices is not as necessary as with other companies.

Truthfully, most great programmers really do not need formal "training" focused on a specific technology in the sense that they will more likely learn on their own by creating and working on a side project specifically for that purpose.

I will make the distinction that training in this context means something like a course titled "Learn .NET development in only six weeks" versus a broader education as in earning a CS degree. Great programmers can probably learn more on their own than spending time taking a training course, but they could benefit from a few CS courses focused on more general computing fundamentals and concepts.

It just never would have occurred to me to use Emacs as a video editor (my brain has been conditioned to think of it strictly as a text editor). If that idea had popped in my head then implementing it, relatively speaking, would probably have been less of a challenge than coming up with the actual idea in the first place which requires overcoming my preconceived notions.

In this instance, the idea is far more impressive than the actual code. This demonstrates innovation beyond technical prowess because it added a new way of doing something to a familiar software tool that most people would never have thought of.

Not to make generalizations, but it does demonstrate the difference between the user base of Emacs versus the users for most other popular IDEs in that they have both the determination and the skills to make this possible.

http://stackoverflow.com/questions/375263/when-should-you-le...

Somehow the link got lost. Can others flag this post to be removed since I can no longer delete it myself? (unless folks want to discuss the topic anyway.)

I'd be wary of the motivation of those now suddenly deciding to pursue a CS degree who in a different economic climate would have chosen a different path (e.g. investment banking, financial services, etc.)

I have a suspicion that these folks that do follow through with getting a CS degree are really grooming themselves to hold positions in tech management versus jobs that involve actual coding and engineering.

We saw the reverse effect at the end of the dot com era. Those that had no real passion for technology dropped out leaving those who truly care about the craft of programming to remain and to innovate.

I have worked with programmers who felt they lost all control because they were not driving the functional design. However, they did truly have control, as Joel points out, because at the end of the day they still own and decide the technical design which is generally better aligned with their unique skills.

Good functional design tends to be technology ignorant by being more focused on what something is going to do from a user's perspective versus how it is going to do that something behind the scenes in code (as defined by the technical design).

While a functional design can be written out as a spec, the technical design can be developed and evolve as you write actual code if you follow an agile, iterative style of development. I think writing a technical spec (not to be confused with the functional spec) and handing it off to junior developers is why people get turned off by the idea of creating documentation on how something is going to work by someone who is not going to be the one actually implementing it. (In Joel's article, it is what Charles Simonyi was trying to define as program manager.) Once again, this is not the same as someone who provides a functional design spec.

Alan Cooper's The Inmates Are Running the Asylum does a really good job drawing out and describing that distinction between the areas of functional vs technical design (although if I recall he uses different terminology to describe the two but the same concept nonetheless).

It unintentionally and perhaps naively raises my suspicions and skepticism.

They thought they'd be able to dictate they way shows reached audiences.

-->

They thought they'd be able to dictate the way shows reached audiences.

http://news.ycombinator.com/item?id=496285

I have never had the urge to flip that switch. The sheer quantity of the quality links are enough to keep me engaged.

http://forums.construx.com/blogs/stevemcc/archive/2008/03/27...

http://grammar.ccc.commnet.edu/grammar/

"Guide to Grammar & Writing" should have a knowledge exchange with "Guide to Web Site Design & Style".

http://blog.stackoverflow.com/

More than once has it happened to me where I click on the very prominent icon "stackoverflow: a programming community exploit" when I want to either check out some new feature implemented or read some question that is discussed in the blog but I am sent right back to the blog's home page and not the the site itself.

The link to the main site is right below the icon but the two should be swapped. The current way is just not consistent with my general web experience. Yes, a small inconvenience as a user but an inconvenience nonetheless.

The problem is more about internal applications that have nothing to do with the identity of the company itself. Personnel management, time tracking, accounting, and payroll apps suffer from poor quality if built in-house because they are part of the cost of doing business independent of what that business may be.

Is this not precisely what happened when the last big bubble burst, the dot com era? People who had no real business being in technology or had no passion about programming left the industry leaving behind the ones that actually cared and were much more motivated and driven leading to greater innovation.

Taking a page from history, I say this is a good thing for Wall Street in the long run.

That nicely summarizes what I experienced in frustration (and wrote about http://lexicalclosures.blogspot.com/2009/01/paging-in-aspnet...) when attempting to bind paged data to an ASP.NET GridView (list) control.

The only difference is that I used an ORM (NHibernate) and not the database to provide the paged data. It was frustrating because the GridView control just did not want to play nice if I did not play by its rules.

How accurate is to compare the various project teams? It always seems to me that no two projects and no two dev teams are ever the same. How do you account for the differences? The researcher somewhat addresses this but I am not fully convinced:

>>"...The projects developed using TDD might have been easier to develop, as there can never be an accurate equal comparison between two projects except in a controlled case study. In our case studies, we alleviated this concern to some degree by the fact that these systems were compared within the same organization (with the same higher-level manager and subculture).Therefore, the complexity of the TDD and non-TDD projects are comparable..."

Perhaps more data needs to be collected.

http://www.abstractspoon.com/tdl_resources.html