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.
overall, the economy is not "fair" by most measures.. older industries do not get new influx of dollars and talent.. people only want to pay so much for a commodity product.
... far from defending John Deere, instead realize that this is an example of a truly "political" problem.. the needs and wants of direct stakeholders are vastly one-sided, compared to the outputs over time for the rest of society.
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.
Communication is great until someone becomes unreasonable and doesn't want to do something. Trust but the chain-of-command must verify. Shouldn't need to, but it should be there as insurance.
People don’t just randomly become unreasonable halfway through. If they’d be unreasonable, they’d do so from the start. If it happens midway, there’s almost always some reason.
That said, I do I agree that the chain of command should always be aware of what’s going on, or have a reliable way to find out.
Yep. People aren't rational, compliant, cooperative actors 24/7. Agendas. Bad days. Illnesses. Family events. So then it's unreasonable and foolish to extend trust unconditionally, perpetually, and without auditing.
If all people were angels, no government (or whoever regulates) would be necessary.
If all people (and systems) were perfect, no backups would be needed.
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.
Can you clarify what kind of CNAME you're referring to? The only CNAMEs that aren't "supported" are CNAMEs on the root of a zone, which are a violation of the DNS spec, as CNAMEs cannot coexist with other records, which must exist at the root of the zone.
> 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.
Yup, me too. Been with them since 2005 and the quality of their support has really tanked in the last 2 years. I think once a company becomes a certain size, it's very hard to provide support that's not just a bunch of drones reading from a script. It's very unfortunate.
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'm not sure -- I think it just a patience vs. money trade off.
Which levels are you talking about? Definitely there are levels where it all comes down to luck, but even with 0.5% of winning, you'll probably get there after a couple hundred games. I'm not even sure it's a good business decision for them, more like poor design imo -- I suspect there are more people who get frustrated and quit than those who actually pay...
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.
make looks for [Mm]akefile if you run it with no arguments, but here it's being run recursively (or included). On OSX, filenames are case-insensitive, which could be a possible reason why it works for some people. On Linux, filenames are case sensitive.
That seems to be the case, since running file on one of the existing .o files says that they are Mach-O i386 objects. The readme doesn't mention OS X though, only Ubuntu
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 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.
