sure. It used to be that major releases were tied with major features. InvokeDynamic on 7, Lambdas on 8, Jigsaw on 9. So since these were the features that were expected, the release only shipped when they were fully baked. Now is on a train-release model. You get whatever is ready to ship (big features can't delay a release anymore).
Can't stress this enough. If you have Employee Incentive Options is way better to exercise them as soon as they are vested than to wait (if thinking of exercising at all). When you exercise them you pay AMT on what they are worth when exercised (of course the "fair price" is a hidden secret left for the CFO). As time passes, the "fair price" is probably going to keep increasing, but with no liquidity and inability to sell your options you are stuck with the AMT with the fair price at the moment of exercise
I disagree, I think the hard skills for being a successful software developer are picked up by honing your craft daily working on the same project. Hackathons are too contrived since the goal is to have a finished product in 24 ~ 48 hours. Every time I have done one I throw away all the "Danger, Bad practice" signals from my sub conscience and work towards finishing the product/idea. Things that are important like maintainability (even if your hack is successful, and get investor funding you want to re-write it properly), coupling, testing, documentation, API, Memory profiling, Logging, performance optimizations, design patterns are thrown out the window to get that idyllic prototype out. Even working as a team, there is very little you gain from spending 48 hours with (mostly unknown) individuals than it is for your peers in a job where you actually have a favor economy.
And I don't mean that there isn't any value on hack-a-thons. I think you're right on dealing with deadline pressures and the ability of working yourself out of a problem in a pinch are valuable skills. I just don't think that's where the "hard" skills needed to become a successful software developer are learned.
I would biased-ly recommend javapubhouse.com (I host it). Is a tech dive on a Java topic that you can listen while on the radio/threadmill (you can close your eyes and follow the code) :)
Neat, will check it out. Yeah, Kanji might be a tall order right now (still working with Hiragana/Katakana first), but found the forums. Kinda nice to find a community of Japanese learners
Spanish native speaker here. I'm still waiting for my ah-ha moment (I'm learning Japanese for the past 4 months at a rate of 4 hours per week), I do hope it arrives. It took me probably 5 years to be fluent in English, and probably 4 more to actually be good enough as to read/write government proposals, abstracts/CFP, and finally co-authoring a published book "Java 7 Recipes"; my accent still lingers (javapubhouse.com if you want to hear it), the Ys, Js all come out with the same sound for me. I did learn French for 5 years, but lost most of it due to not practicing it. Learning French coming from Spanish felt a little weird because there are gender swaps (for the inanimate objects) that do trip you up. Did try to learn German for 5 months just after finishing French, so I ended up sounding like a French speaking German, which my teacher hated (and whom scared me away from the language!)
I noticed that I'm not really going anywhere fast with my Japanese and I think I might be doing it wrong (listen to one hour podcast while running / biking). Some stuff sticks but in general it does seem that my progress is nowhere near what I had when learning the other languages in a more structured format.
// and Wing Commander including Armada, Descent, and Freespace (even Star Wars Tie Fighter). The last Space Sim that I found was Strike Suit Zero (http://store.steampowered.com/app/209540/) which is nice, but not as epic as the WC series.
Working with the JVM, there is definitively more cross-platform support (I know there's Mono for CLR but it's not the same support Oracle's JDK gets), GC has a ton of heavy hitters investing time (from IBM JRockit acquisition to collaborations with Azul's Zing) and while I haven't seen first-hand CLR's optimization the JIT optimizations are pretty impressive.
In our company we understand that testing up-front can be off-putting, but we rather pass up a great candidate than hiring a poor one (we do subscribe to Polsky view on candidates http://www.joelonsoftware.com/articles/GuerrillaInterviewing...). We allow them to test at their pace (codility.com) from home first, then we re-test them on-site (to avoid the 'someone doing my homework' effect). After that the next interview is pretty much talking on the code written code and approaches or decisions that the candidate took. So in that sense is a great piece to further discussion.
The issue is that where I work we can't subcontract as a way to 'test' for candidates. The code is so proprietary, and have so much red tape (Options Trading platform) that we don't trust anyone unless you are full-time. Also, the code is fairly complex and embedded in it's industry-speak that unless you come from the same industry subset, you will not be productive (like knowing what Black-scholes, instrument, or delta means). So the investment to getting any good developer to be able to produce is immense. We considered subcontracting for assessing a candidate, but it is fairly hard.
Also we have seen people that do extremely well on every other aspect of the interview but can't deliver when asked to write a piece of code. Good or bad it does show your ability to work under pressure (I am not sure if it's extreme in the financial industry, but stress levels here run fairly high... for a fun read http://codesnipers.com/?q=interview-the-wall-street-programm...). So when you're getting your coffee, someone comes and says 'we need to fix this' it will probably be as intimidating (or more) as having a code interview.
Lastly, maybe because we've seen it often enough, there are a ton of programmers that can't write code (yes, the fizzbuzz crew). Having the codility test filter in front of all eliminates a lot of that chaff we see, so we don't even bother with the candidates unless they get a good-enough result in codility (we do look at the code, not just if it passes/fails the unit tests, but we don't bring the candidate for an actual interview until we have a reasonable expectation that they can program). We understand we will miss Ike Ellis, and we accept that as part of the tradeoffs between time and opportunities.
You're assuming that the code is executing in the way you read it, which is false. With the advent of branch prediction and Instruction reordering in CPUS (to gain performance), a CPU have the liberty of reordering operations for efficiency (http://en.wikipedia.org/wiki/Out-of-order_execution) EXCEPT when there are memory barriers (or explicit synchronization instructions). With a multi-core processor things get even more complex, as you have cache locality (a thread reading the point value might be hitting the CPU cache and not main memory). If the thread happens to be executing on a different core than the assigning thread, disaster ensues.
Not sure this is true. There is the concept of final fields, but that doesn't make objects immutable, and thus even when declaring object finals (or arrays) you can pretty easily shoot yourself in the foot by mutating them in-place.
