One of the things that I've learned in recent years closely relates to several of those points: There is no shame in being wrong, it is much more important to quickly adapt to new information that has since proved your original assumptions incorrect.
Especially on the non-IT side in the corporate world, it seems like a lot of people have an irrational fear of making a decision on anything in case that decision ends up being wrong. Instead you end up with either a watered down solution that doesn't really solve the problem or the decision to delay the problem entirely.
That's an interesting idea. Did the original author of the work walk the junior team member through what was going on, or did they just point them at it and have them check through the work on their own?
It seems like that could be helpful. My main concern is that a lot of junior devs need some specific direction (as opposed to just telling them to go read some code) so we might need to setup some specific expectations for the results of the code review (maybe have them help write documentation?).
We're currently transitioning away from TFS and I think locking down changes to pull requests (and potentially blocking most devs' access to commit to master) will help quite a bit. You can pull off a similar workflow in TFS, it's just much less convenient.
I think being able to see the full end-to-end diff for a task/story (as opposed to digging through a series of changesets in TFS) will make the benefits of any suggested refactorings much more obvious.
Off hand I can think of a few reasons for using the mapping object as they did in angular-translate:
- It may make sense to translate the same English sentence to something slightly different in different contexts in German.
- JSLint/JSHint should be able to check for usages on an identifier like TITLE, PARAGRAPH_ABOUT_FOO, etc. easier than comparing strings (you'd have to build something custom for that).
- Brevity. If you have the same long string of text written twice it may be useful to have a shorter identifier for it.
I agree with not translating language names though, in the real world that doesn't really make sense.
Office design should reflect what the employees in the office are trying to accomplish. As a developer, all of that crazy stuff in Zappos' office would be a huge distraction to me. I haven't checked, but I'd be a little surprised if developers' cubes/offices were as over-the-top at Zappos as those for their customer service reps.
With services like Rdio, Netflix, and Steam it's actually easier for me to get what I want legally now. Lots of people don't pirate because of the cost, it just used to be the easiest/fastest way to get music/movies/games.
I greatly over-simplified the algorithm in my initial post, but there are advantages to a straight hash of the password.
Even if you can intercept the person's hash and login to that site, you still don't know the user's original plaintext password. A lot of people re-use the same password throughout many (or all) of their online accounts. The attacker may be able to impersonate the user for the current site, but they don't have their actual password to gain access to other sites.
What I was talking about in my original post (but didn't properly explain) was using hashing as part of a larger algorithm for doing a challenge/response login. The idea is explained here: http://pajhome.org.uk/crypt/md5/auth.html
I agree that HTTPS is the way to go if security is a huge concern (like for banks), but for a simpler site you could get away with using CHAP and still provide a reasonable level of security.
I haven't verified that Digg does this, but most big sites that do logins over http do some sort of hashing on the client side so that the actual password isn't sent plaintext.
As has been mentioned, there are all sorts of issues with using https, and for sites where security isn't a huge concern (it's always important, but not as much for a site like HN vs. a bank), hashing client side and sending the data over plain http can be enough.
I've been using PHP at work and on personal projects for years. It has a very low "barrier for entry", which is both good and bad. It's easy/cheap to hire entry level programmers to write simple PHP, but it's all too easy to let them jump into big projects too soon and write something that turns into a huge mess. Well written PHP code can be just as easy to read as Python/Ruby/etc., but PHP makes it far too easy to write something that is a horrible mess.
At work we are still mostly a PHP shop, but anything I write on my own now gets done in Python. PHP's complete lack of a coherent function naming scheme is enough reason alone to get away from it.
Especially on the non-IT side in the corporate world, it seems like a lot of people have an irrational fear of making a decision on anything in case that decision ends up being wrong. Instead you end up with either a watered down solution that doesn't really solve the problem or the decision to delay the problem entirely.