In a field which is not regulated and where tools are not standardized, how do you know if the greatest and latest tech is actually any good?

The job title of "programmer" (and its variants) covers a large number of different actual jobs and fields. What you've said is not true of every programming job out there.

You end up recognizing that there are different types of programming jobs, in your final paragraph, but I wanted to emphasize it.

The need for "constant technical learning" can true for example, if you work as a consultant, and are placed in different projects, with different technologies, every x months. It is also true if you want to change jobs with some frequency. In those situations, being able to to work, from the get go, with several different technologies is a plus.

But a lot of programming jobs are not novelty technology based. For example, if you work at a company which develops products (instead of services) or at a company that does some in-house development as means to support other business areas, you'll find out that the company as little (or no) incentive to change. Also, in places where the focus is in the domain knowledge, people put way more value on that domain knowledge than on knowledge of technical stuff. These companies may decide to update their technology, or adopt a new complimentary technology as they expand their products, but, with that, typically comes company provided training.

Are you joking? Or are you using a loose meaning of the word "know".

People need to start being realistic with this "keeping up" stuff.

Let's take a look at the stuff you listed and where they are typically used:

1) web - Java; Python; Javascript; HTML; .NET
2) mobile - Objective-C & iOs for iPhone; Java for Android
3) desktop - C#/WPF; Java; Objective-C & iOS; C/C#/C++

You just described three different development roles (although there may be some intersection of technologies).

Let's say I'm working as a full time as a "desktop developer" in a company product where I work with a Java development stack. Do you think I should spend my free time doing web development and mobile development , in order to be considered "current"?

Which other professions have these kinds of expectations?

I like code reviews and think they can work. Here's some anecdotal evidence:

I work at a company where the "code review" is part of the process, but not all teams end up doing it (i.e. for time constraints). Specifically, there's a smallish team who mostly does not do them.

This has given me the opportunity to see the result of work done with "code review" and and work done without code reviews, by people in the working same environment, hired under the same (or similar) criteria.

In summary, there is a significant difference in code quality in the code written by these folks who usually skip the code reviews. Sometimes these guys work on code that's under my team's irresponsibility and we end up having to cleaning it up (to the point of rewrite).

If these people would do regular reviews, and talk about the code, and what makes it good or bad (this usually happens in a code review), their code would eventually improve. I know my code improved a lot by being reviewed by my colleagues.

The code review allows for some knowledge passing, and is also a quick "code readability" sanity test.

Its been publicized that the cost of correcting a bug goes up with time (i.e. its cheaper to fix a bug that is found in the development phase, than if it is found in the QA / testing phase; its cheaper to fix a bug found in QA, than a bug found by the client). I think I first read in the book "Code Complete".

Code quality issues are not caught up by the QA / testing people.

If your code reviews are not improving the code, maybe the process is not a good one. Maybe you want to share how you guys do it?

In some cases, translating from language-X to language-Y is a straightforward line-by-line-with-a-few-additions conversion. The patent would not be of much value since anyone could just use the reference implementation and translate it to very-similar-language. This would possibly mean that the original "inventor" would start patenting the same algorithm implemented in sevaral programming languages, as long as the conversion is simple and/or has little cost.

(And I'm not defending the patents system.)

Just to say thanks for making those textbooks freely available :).

Best Regards.

I was not saying that Unit Tests cover everything. I was just saying that doing them raises my enjoyment of testing... I still do other kinds of testing and so does the company's QA team.

The same is true in the company I work at, which develops products related to resource planning. Most managers and team leaders of my department are both managers and coders. They have a lot of valuable knowledge.

Domain knowledge is essential because it makes you more valuable. Specially if the products are complex, since the new guy will have to receive a lot of training before he can become useful.

If you work on generic applications or websites where you only need to know technical skills (like a Programming Language + SQL) you are easier to replace with a younger guy.

"I'd rather write half as much code, spend half as much time debugging it, and go home. "

Thats why I like Test Driven Development: when I'm writing unit cases, I'm doing test case design AND I'm coding. Then I also get to write the code that passes the tests. So I end up enjoying the testing part of the work a little more.