GaveUp

I'd argue that's a sign that John Deere is just out to maximize their profits at the expense of everyone else. Plenty of evidence out there to support that. Sure, any company's goal is to maximize profits to some degree, but instead of manipulating the market to extract additional money target a product to what the market can afford. If a market can't afford the product the problem isn't the market, it's the product. Instead Deere has has manipulated the market to extract money the market can't sustain.

I don't know if I agree that the second pass is optional. I've found that pass is the one I've seen have the most benefit, particularly with newer developers. It serves two purposes when done well.

First it gives you an idea of how well thought out the implementation was (i.e. was this a quick hack to just finish a asked for requirement) or was a best design targeted. It also helps newer developers develop a voice. Often, at the start, newer devs will take what a more senior dev says as gospel, but by striking up a conversation and, in some ways, making them defend their choices it can help build confidence and that voice to speak up when something doesn't seem right.

Second, I've found it a good way to introduce people to new approaches to accomplishing tasks. Not everyone spends their off hours studying patterns and practices and rarely is there time during a work day to do this properly so code reviews are a natural place to bring these things up as there's concrete comparisons and examples to work with. That helps spark a dev's interest to look in to the topics further.

I’d be happy if the existing bindings just behaved closer to how they do in vim. As with all vim binding plugins there’s always slight differences that drive muscle memory mad.

The key part in that is communication. That’s makes all the difference whether it be with BA’s, QA’s, or the end user. Speeds up the development cycle and greatly reduces the number of bugs.

The best experience I had was on a team that had essentially 2 BA’s and 7 devs. There was constant communication to clarify actual requirements, devs would build automated tests off them, BA’s would test against the requirements and then a business user would do a final look over. All in all features were able to be released usually within a day and there would be days we’d get out 3 or 4 releases. Only in one case did a major bug get released to production and the root cause of that was poorly worded regulations which had a clarifying errata come out at the 11th hour.

For as many faults as that company had that caused me to move on I’ve yet to run across a team that functioned as well as that one did.

I noticed the same thing when interviewing people. Answering why a decision was made would always trip people up, but it's far more revealing than any demo project can be. It doesn't matter, to me, whether the solution was right or wrong, but more the "why" that got you there and how it will get you to where you need to go. You can't problem solve effectively without understanding the reasons you're making the decisions you are.

The same follows for patterns, I think. If you haven't thought about it critically and really done the work to understand the "why" (being told the "why" is not enough) you're going to struggle and mostly fail to implement it properly are in the appropriate situations.

Hardly accurate but coming from the C# world I thought of traits as a hybrid between an interface and extension methods. I think the biggest challenge was that, at first glance, a trait does appear to be very close to an interface, but really it is it's own beast.

I'm on that boat too. Most recently had a ticket about their DNS servers not picking up changes. If I recall correctly the initial response was quick but every subsequent response was from a different person that would run through a script, one step of which was "disable your firewall completely," even though that had been shown to not be the issue not to mention just being a bad suggestion in the first place.

Ended up after a few back and forth replies it was escalated to the "DNS team" but they weren't around until the AM. It ended up being the next evening, after I followed up that I got any response. I ended up making a change on my side to at least get websites back online, but it was over another week before any real "answers" were given.

Of the two issues one was due to certain CNAME records not being supported/allowed by their servers (not documented anywhere) which took over a day to get a final answer on. The other issue, one of their servers connecting/disconnecting to mine (seen in my logs) but not actually doing anything was labeled as something to just be ignored. My logs still fill up with those errors.

I've been with linode a long time and do like them, but as they've gotten larger their support has increasingly gone the way of other large companies...largely useless.

The levels I'm thinking of are the ones that require 200 green or multiple combos of special candies. Add in the chocolate things and the tornadoes and it just gets worse.

I don't know if it was poor design or purposeful to get more money out of people, but I tend to think the latter because of just how many places it begs to buy things.

People probably do get frustrated and quit. I know that's what I end up doing. Especially when my gaming habits are 30 minutes here and there. I just want a short session, not play for 5 minutes and have to pay more or wait 30 minutes to play more.

My biggest gripe is that the game is designed in a way to extract as much money as possible to the detriment of the game itself.

There are several levels you'll play where you have absolutely zero chance of winning (particularly the later levels where you need X of this and Y of that) because the colors just don't come up. Yeah, that's down to randomness, but it's one of those things that could be resolved. Also, when playing if you receive a call or switch to some other app in the middle of a game you lose your game and that life. Yet another way to pluck more money out of people. Then you have the arbitrary play limits (3 days to unlock another pack via bonus levels, 30 minute waits for lives, etc).

I'd have much less of a problem with the game if each level had a solvable method to it. Then you can make it pay to pass or skill to win.

I realized over the years that it's those high school and college years where you can really expand your skill sets where as once the real world starts throwing things at you you start to stagnate. Makes me regret a lot of the time I wasted in those years.

Well, on my system (Ubuntu) at least this is not the case and renaming the files gets past the errors and on to actual build errors:

  runtime/cxx.cc:74:41: error: ‘operator new’ takes type ‘size_t’ (‘unsigned int’) as first parameter [-fpermissive]
  runtime/cxx.cc:84:43: error: ‘operator new’ takes type ‘size_t’ (‘unsigned int’) as first parameter [-fpermissive]
  make[1]: *** [runtime/cxx.o] Error 1

I haven't tried myself but it looks like a casing issue. All the makefiles have a lower case m. I'd suspect correcting that would do that trick.

I forget where I read it but I remember a quote the basically boiled down to "The only people willing to attempt writing an OS are those too naive to know how much work it really is." Part of that probably explains why you can learn so much when just starting out...you just don't realize, yet, how much of you're life it will consume.

I wish I could say I had the same experience with the box. The firmwares were consistently buggy and never quite worked well.

By far the two most frustrating aspects being the forced updates (which were often more buggy or broke features) and the lockups while in sleep. There was nothing more annoying than having to get up and hard reboot the thing every time I wanted to watch something.

Once the Pi and raspbmc became a viable alternative I quickly replaced my boxee boxes because, while not bug free by any means, they're much closer to "just working" than the boxee box ever was.

The one good thing I can say about the boxee box, though, is that its remote was a real treat. That thing worked like a charm.

This reminds me of a situation I've seen and found myself in far too many times. When I encounter a performance problem I immediately think about areas where, during initial development, I stopped and said "this might cause a problem with a large amount of data" versus doing the proper thing of actually hooking up a profiler or doing proper testing to determine what the actual problem is; Rarely is it in an area I previously identified as potentially causing future problems.

Ego (I know what the problem is!) and the drive to fix problems quickly always get in the of finding the solution. Tales like this are a great reminder to not assume you know what the problem is.

I've always thought "being the dumbest person in the room" was a bit of overstatement to the truth. It's probably more accurate to say you don't want to be the smartest person. Not so much because you avoid having a target on your back if something fails and a scapegoat is needed, but more because you not only have the ability to teach those that know less than you, consequently reinforcing things in your head and giving yourself a better understanding, but also having people around that you can learn from.

I can say being the smartest person in the room gets really old fast because you always feel like you have your hands tied behind your back and as much as X may be a better solution to a problem you have to fall back to something the entire team can understand.

The general environment would probably make a difference too. If you in an environment with people that enjoy learning and sharing the knowledge they gain being the dumbest person in the room probably isn't as bad. I can't say I've met a work environment that is like that, though.

I'm by no means an expert but these are some of the links/books I've found informative.

Smashing The Stack For Fun And Profit [1] Reversing: Secrets of Reverse Engineering [2] The IDA Pro Book [3]

The iOS Hacker's Handbook [4] was interesting as a sort of case study on exploiting and hacking embedded hardware.

Mostly what I've found, though, is just starting with a question and googling the answer yield the most results. For example, see mention of a stack overflow attack google how and why stack overflow attacks work (or don't) and once that side of things is understood the thought process behind finding them becomes easier to understand, although not really easier to do (for me, at least).

[1] http://insecure.org/stf/smashstack.html

[2] http://www.amazon.com/Reversing-Secrets-Engineering-Eldad-Ei...

[3] http://www.amazon.com/IDA-Pro-Book-Unofficial-Disassembler/d...

[4] http://www.amazon.com/iOS-Hackers-Handbook-Charlie-Miller/dp...