bokglobule

I guess it's how you look at it, but Indeed still shows very little movement over the last years with interest in Scala developers by businesses. Even compared to Go, it's very small.

http://www.indeed.com/jobtrends?q=scala%2C++go&l=

I wonder if Go will be similar to Scala where it arrives to solve issues with Java (or C++). I found that although Scala is a nice language in many ways, the smallness of the community prevented me from adopting it big time for most work. The same holds true for languages like F#. They're fine for special cases (likely what Google intended with Go), but won't be a general purpose replacement for more mainstream languages without some huge advance in support (like what the Rails team did for the Ruby language).

Just my humble opinion..

I have a BS in CS, Math and Stat, and a MS in CS. I've been a developer for a long time and worked with a lot of other developers. The biggest determinant IMHO to becoming a good, competent developer is the desire to become an even better developer from reading, experimentation on your own time, and an open mind.

If you have that kind of passion for software development, you'll do fine, regardless of your original degree (or lack thereof). Having said that, I'm skeptical of the value of a MS in CS without a BS in CS. In my MS program, the assumption was that you had the basics - algorithms, data structures, language theory, basic hardware design & logic, compiler design. You can certainly gain that knowledge with enough reading on your own, or taking some courses at a local community college to get the basics.

Soylent green here we come... http://en.wikipedia.org/wiki/Soylent_Green

Software is simply the expression of an idea. No different than art, literature or any other creative medium. Never should have been an issue in the first place. Yes, software can be complicated, even very complicated. A painting by one of the great masters is also "complicated" but that doesn't qualify it to be patented. Copyrights work fine for creative media and they'd work just fine for software also.

If Bjarne had been able to keep C++ his own creation instead of letting the "standards" people come in and take the thing over, C++ might have avoided becoming the over-designed language its become. Anyone recall the differences between [const const {star}], [const {star} const], etc ?

Language design has come a long way since the early 80's. His concerns back then were a programming language that would retain the performance of 'C' on most hardware and be straightforward to generate from 'C' code due to re-use of the 'C' syntax (the early C++ systems relied on converters that translated C++ to 'C'). Over time compilers were created to generate machine code straight from C++. When 4k was a lot of RAM, it made sense to focus on this; it still does if you're developing embedded software with very limited hardware. (FWIW, I've written software in C++ since 1990).

I'd argue hard that today, in most cases, and in particular in web applications, the issue is developer productivity. Today we're focusing more on expressing solutions in code that are much closer to the way that we think. Whether it's Ruby, F#, Scala, or Javascript, the tools we're using allow for more powerful solutions in far less code and complexity than C++.

Let the flames begin..

From reading the post, my takeaway is a guy who's probably going to struggle for awhile to find a position. When an engineer says that they only care about the technology and not the product, that would set off my red flags immediately. Frankly, in 99% of the cases, it's the product that pays the bills including the salaries of the team. If I had interviewed him, I probably would have suggested he look for a position in a R&D group in a large company with the funds to do that sort of software engineering.

I find many of the interview puzzles that people have posted on the Web that they've encountered at the Big Name companies as often a bit silly. Having said that, asking software developers to implement a solution to a common programming problem - "navigating a tree using recursion", etc. is perfectly reasonable. I've found more than a few software devs who have great looking resumes but who have no idea what recursion is, what a tree is used for as a data structure, etc. And I consider this the basic, easy, 1st year undergrad type stuff.

If there's an undercurrent to all of the comments here, it's that we still don't really have a good way to sift through the good from the really-not-so-good developers quickly. The programming tests and puzzles are a proxy for this and they only work so far - some people like to think through issues more before coding, or tend to freeze under this on-the-spot pressure. Doesn't mean that they aren't a good, competent developer you'd want on your team; my experience is that the guys who blurt out very quick answers can sometimes write the worst code.

If devs are estimating in hours, days or some other measure of time, the game is already over. As a species, we're pretty terrible at estimating absolutes. But we're pretty good at relative comparisons. If I hold up 2 buckets, 1 small and 1 large,and ask you their precise capacity in liters, quarts, etc., most guesses would be off, many quite a bit. If instead I asked you approx how much larger the large bucket was compared to the small bucket - 2x, 3x, 4x, etc., the majority of the guesses would be pretty accurate.

The better option when estimating is using a system that builds on relative comparisons between work items. We use "points" on a sliding scale. Not only does estimating get much more accurate - "We think that enhancement is about 2x as big as the one we just finished", but the estimation process is quicker.

What brings the point estimation system back to calendar time measures is mapping it to how many of those points of work are typically accomplished in a fixed amount of time - basically typical throughput. Knowing that throughout number, it's a quick calc to figure out how long it will take to complete the work. The throughput number also takes into account all of the little things that go on during the day that no one ever remembers to account for - restroom breaks, emails, phone calls, chit-chats with co-workers, etc.

I've never worked on a project that estimated things with the absolute (days, weeks, months, years) scale that was accurate and didn't require death-marches at the end. Conversely, I haven't worked on a relatively estimated project (points) that has been late or required anything like a death march to complete.

I often wonder if the problem with programming (or software engineering, if you prefer) is that we're still in the stage of where builders were in the middle ages. We assume the model of a "master builder" that has to know every aspect of every part of the process of building something new. Compare that to today where trades people specialize in one part of construction and hone it to a fine point. How many of us would hire an electrician to fix our plumbing, or a roofer to hang drywall? Maybe in the future this will be what happens to software development: you'll bring in a UI trade to implement the UI, a database trade, a caching trade, etc. People who've taken years to fully understand their niche of software construction very well.

The other issue we don't have to face is any governmental enforcement of building codes (yet). When you install wiring in a building, you can't just run it however might be "cool" or "new". There are a variety of rules, that come from best practices developed over many years, that are followed. Imagine if before a client or a customer would accept a finished app if it had to pass inspection by a 3rd party for compliance with these "codes". I think we'd see a lot of the current state of development fall away pretty quickly. The newbies who won't take time to learn their craft, or quickly jump from new toy to new toy without learning any very well would be under pressure to change or leave the field.

Why was Go chosen over NodeJS ?

Are people using C++ to access web services?

I think the comments about e-Ink "going away soon" are badly misplaced. The distinct advantage that e-Ink displays will always have over displays like the iPhone, Android, etc is their ability to be used in direct, bright sunlight. Try sitting on the beach and reading a novel on an iPad. Can't be done.