ITT people replying to candybar and thremp

This is a bizarre tangent given that my speculative reason was a just an example of something that people are not considering as opposed to something given as "the reason" and I gave multiple other possible reasons in that same post:

Furthermore, it's absolutely not because I was pretending to know why Microsoft did something that you jumped in. Your actual point before you pivoted to this tangent was:

And basically that Microsoft doesn't care about Excel's minor shortcomings because it's dominant. The specific reason you gave (somehow breaking your own rule about not speculating about unknowable reasons for why someone did or didn't do something):

is contradicted by history as they did build the exact thing suzzer wanted in 2000 and replaced it with something better. I let this slide earlier but pointing this out in case you are actually trying to argue that it's important not to speculate about why Microsoft did or didn't do certain things..

You're preaching to the choir bro. I used to have a subtle jealousy of iPhone users because every Android phone I had used was always a bit too unpolished an laggy for my taste. But ever since I ditched Samsung and started using stock Android I feel like I have the perfect phone. My Pixel is amazingly smooth (equal to any iPhone I've used, fiance's iPhone 8 included), drastically better UI (notification pane and navigation buttons), and I can use a keyboard (Gboard or Swift) and launcher (Pixel or Nova) that isn't absolute dog****.

Lol. I talked about this right in my first post on this subject. It's that whole last paragraph about where I talk about your weird claim about why Microsoft didn't build this feature.

Yes, my other point was about choice. But you're doing the same thing which is picking one simplistic angle (that isn't obviously wrong) and then making some big long rant about how its THE thing that matters.

I dropped this because your whole argument about choice and Apple stuff is silly and crazy simplistic. My point about lack of choice giving rise to lots of ****ty features is absolutely not controversial and I don't need to write thousands of words about it. If you disagree... ok, cool.

Lol. Yeah yeah yeah.

FWIW - as I said I'm open to the argument that not a lot of people use Excel the way I do, and probably don't crash as often as I do (due to battery issues) - so for that reason my desire for Excel to behave like Sublime isn't worth MS's time. I can accept that.

Technically unpossible because reasons - not so much.

In the paragraph you gave an alternative reason that was demonstrably wrong and you happened to be completely misinformed about what we're even talking about. Like literally you didn't read the posts you were criticizing which already pointed out that the feature that's being talked about had been implemented in Office 2000 as an add-in, then replaced with a more complete, complex version that surely cost more money and time, which entirely precludes the alternative reason you gave to build a narrative about your point:

The irony here is that you're doing this yourself - you're not even bothering to understand what's even being discussed and just going off on a simplistic, generic tangent, about I don't know, my posting habits or something.

I'm sure that's a possibility - but then how about actually explaining why it's silly and simplistic? How about addressing the psychological bias I pointed out that is relatively well-known and dare I say, relevant to the phenomenon and the selection effect that appears to statistically bias the criticism in the exact direction that I'm pointing out? All you've done is posting counterfactual speculations - which don't even support your other point since every company has to deal with finite resources, not just companies with dominant products without strong competition - regarding a specific example in question, then more or less just asserting your way to victory. Oh yeah my point is silly and simplistic and weird - who can argue with that?

Why even bother posting about this, when you're saying amounts to, I'm right, you're wrong, QED? And somehow you have the gall to talk like this:

Also, to elaborate on what I think is just sloppy thinking:

The limited time/money issue applies to every product, but it actually applies less for dominant products at this scale. This is why Excel has so many features. This is why Facebook is tens of millions of lines of code. So this isn't merely irrelevant - it actively contradicts your other point. Furthermore, what's true at the level of products isn't true at the level of feature requests. While all products are constrained in terms of time and money, most feature requests as conceived by users are rejected not because they cost too much but because they make the product worse. Product design is essentially a governance function - sure there are budgetary constraints but mostly you're trying to make products that appeal to the broadest group of (paying) users as possible. Some features may be desirable but cost too much. Others may be desirable to one group of people but not to another group. It's a balancing act and the larger the scale and the more trivial the feature, the more it's about this compromise and less about the budget.

It's definitely not the development time since they already developed and canned it. It's about the product. They already have a more sophisticated version of this feature that allows you to select the exact recovery behavior at runtime. For any product with a clear file metaphor (I think the expectation of instant auto-save is more common with cloud apps), I don't think any product manager focusing on enterprise customers would choose auto-save-over-existing-file over autorecover-and-let-the-user-choose. Photoshop works in a similar way and emacs works in a similar way. Sublime doesn't have this enabled by default either. Programmers are used to working with version control taking care of file history so they are ok with always saving, because anything not new is already safe. Lots of enterprise users (who aren't particularly computer-savvy) are meticulous about using save-as to create versions so they can go back to where they were. Auto-overwrite would not be great for this workflow.

Well anything at this level of complexity is technically possible - the point has always been that there doesn't seem to be any good way to implement this in a way that doesn't piss off someone. Of course you can tell third-party add-ins to **** off, finance types who care about not overwriting stuff to just adjust their workflow, etc. But this isn't a free lunch program, where everyone is theoretically fine if someone else is paying for it. It's like changing a bus route, where there are competing interests. You can't make everything into an option either - at some point you have make decisions and some people will be unhappy.

I guess I'm a little surprised to see software developers talk about how software X is crappy because it doesn't do this little thing Y, which would make my life so much better because as devs, we're constantly on the other side of this. Maybe I've had a unique experience or overthink about stuff but I've fielded so many bad feature requests that would've made the product worse over the years (and some of them I got to see the negative impact because I lost the fight) that I'm always thinking about how product features interact and weary about product decisions that cannot easily be undone. And a lot of this comes from people not understanding that "this one little thing" may indeed improve the workflow for that one particular person, but can make the workflow worse for others and reduce the conceptual integrity.

For instance, people complain here about PHP and Perl and JavaScript as languages but their main flaws as languages are that they were iteratively designed and fairly liberal about accepting feature requests compared to other languages that had a more coherent design philosophy and was more restrictive about what to accept. And even then, they are far more coherent than actual products most of us work on.

It's fashionable to talk about technical debt, but I feel like it's nothing compared to product design debt and this is something I've been thinking more about. I think very often engineers are fighting a quixotic battle against technical debt, a lot of which isn't even technical in nature. The implementation is often convoluted and terrible because the requirements are convoluted and terrible. The requirements are convoluted because it's just a collection of feature requests, not a coherent product design with features that are designed to work together. No one knows how things are even supposed to work because no one even really thought everything through - it just happened. It's like designing a programming language without a coherent syntax and a semantic model, just adding a special case after another as the customers ask if we can make this particular syntax do this particular operation and just hacking the interpreter/compiler until it works. No amount of technical refactoring can fix this and sometimes products just cannot be refactored. So the product design debt becomes a product design tax - you can never pay it down.

In a microservices/SOA world this gets worse because effective product boundaries aren't even at the company level but at the service/team level. What would otherwise be technical debt with a single system worked on by a single team becomes product design debt once there's no effective way to coordinate changes across teams and systems and you simply have to make sure the show goes on no matter what. Your interface is part of the product design and you're no longer able to merely technically refactor out of your poor decision, you have to convince the other teams to buy a different product and sunset the original product.

This isn't really meant to be anything coherent but I feel I'm seeing more and more of this as we substitute process for thinking, sprint planning and backlog grooming for product vision and design. Slack conversations and shallow code review for design review. UX mocks for conceptual design. I suppose some sort of coherent design is supposed to emerge out of this process, at least occasionally but sometimes it feels like no one is in control and the second law of thermodynamics reigns supreme.

For whatever it's worth....

https://encrypted.google.com/search?...tomatic%20save

Can't wait until you come back and say this macro-enabled book didn't save anything from the past 4 weeks and now the book is corrupted and won't open.

If you aren't getting what you want from Product push back. You are responsible for accepting stories from them, if they aren't where you want them to be tell them what you want. Use the process to improve the product. Start the conversation and see if you are alone in this or if other people feel as hamstrung as you do.

Wow. That was a lot of words.

My day-to-day is fine - the issue isn't really at the level of, well this story looks wrong or we shouldn't implement this feature - I mean those are easy to push back on when it happens and I'm already enough of a pain in the ass, as you can imagine. It's more that product managers don't seem to understand how the product works, in part because the existing product design is incoherent in a way that defies understanding, and the general state of affairs where design then becomes merely reactive to outside pressure. The feature may come from some executive who has some kind of hunch or vision but without enough time or expertise to design the feature in detail themselves. It may come from some customer request. It may be a response to a competitor. I mean, I've convinced product managers to include my little design/workaround/feature/etc plenty of times and I think that's also broken because I'm not an expert in these domains either and these were off-the-cuff suggestions during meetings, not well thought-out designs. Either way, it never seems as though the people designing the product have fully comprehended the problem domain or the constraints. Or even consider this part of their job. It's not clear anyone really does. And at the top level, it seems to me that this incoherence of the product at large is considered to be merely a symptom of success, when I think it's clearly an impediment to growth and survival in the long run. And no one seems to care about this growth in product incoherence and complexity that's disproportional to the value. In contrast, there's all this talk about technical debt at all levels, even though in many cases it's impossibly entangled with product design debt that there's not much you could do.

Also I'm talking not necessarily about just my personal situation - even disregarding my past experience, it's across a couple of companies and multiple teams and products where I currently have visibility. Also the product design issue isn't isolated to the work I do - it also afflicts the products I'm using, though in this case I'm not aware as to exactly how. I'm not even saying things were necessarily better in the past or anything - obviously software development is immensely complex and has never been more so - it may just be that I'm more aware. But either way, something strikes me as wrong. It's possible this is because I'm working on relatively enterprise stuff in specialized domains that is inherently hard to understand because people who design and create the software are not users of the software. It could be that I'm just overworked and stressed out in general. But it doesn't seem right.

Sorry this was the tl;dr:

Anyone know how an amurican can get a programming job in Vancouver?

City of Vancouver was at the job fair I attended. It was the only booth I didn't visit. So they are at least recruiting people from Seattle, but that's all I know.

I understand what your saying. I had to defend myself to one product manager for asking for mock ups of the screens he wanted us to build and have been asked to "mock up a dashboard" in a different project. Agile gets stuff done fast but some things don't lend themselves to being done quickly and design is certainly doesn't.

Start applying for jobs there and the company will let you know what hoops you have to jump through.

saw,

You described game users and on device video encoding as both "negligible". This is painfully wrong and indicative that you have literally nfi what you're talking about. I brought up the fact that games are the largest grouping of apps and still half of of revenue (I think 2/3rds of all apps are games) to help you understand how absurd your comment were. (The larges apps, in terms of revenue, are games btw.)

My point in this post is simply that your opinion while an opinion is terrible and shouldn't be construed as you having the faintest ****ing clue what you're talking about.

I tried to be more diplomatic in my first response, but you don't even understand what people actually do on phones, so obviously in your world MyPhone = iPhone X. Best of luck having a vague clue on what something is used for the next time you try to enter a discussion on the subject.

Your comments about Android porting are also absurd. (Hint: No user gives a **** how the code is written.)

Grue,

Is this really better or worse than suzzer's absurdity? Or perhaps the prior bizarro timeline daveT put us down with his "Windows can't handle 80wpm + hotkeys".

Goofy,

The salary calculator seems low to me. But maybe most devs aren't aggressively asking for raises or negotiating offers or are content to work for peanuts at small startups.

I recently signed up for Hired with 145k minimum salary and I have ~10 requests to interview from companies that know my expectation. And I have only 3ish years experience. The Hired calculator has historically showed higher numbers than the yc one when I've looked.

A bit late but just installed the beta a few days ago and am loving the speed. I don't use a ton of extensions so that's not a problem for me yet.

Hey guys. I'm designing a scheduled package that's to be run daily and sends a list to an external web service. I need to set up some precautionary checks to make sure the list isn't sent if the data is corrupted. Thus I need to store the list count on each run and subsequently check the count of last days run, and fail the job if those two numbers are unusually far apart.

I'm wondering if there is a clean way to do this and make sure the first run goes smoothly, without leaving any unnecessary stuff in the code that would like do initial checks only for the first run and then never used again.

I'm storing the size of the list in a table of it's own - So my best idea is to manually update the table for the first time, which is an ok solution but it would also mean I need to get the size of the list from our databases. I'm trying to do this without doing too much manipulation of our production db's so I'm wondering if anyone has a clever solution

Sanity checks like that are good, but they're not going to work 100% of the time. It's good to have a skip sanity check option that can be used to run when you know the sanity check will fail when it shouldn't.

It's also useful in development and testing when things are more likely to not be the way you expect in production.

Hard to comment without a lot more context, but if avoid having to 'trick' the check and instead be able to disable it. There's very likely to be times in the future where you'll need to do something similar.

Is the list in memory? How big is it? What does corruption mean?

Without knowing more about your use case it sounds like a checksum/hash would be what you need, but you'll need a way to compute and store a valid hash for good data and compare it to the data you're going to send.

Like a force flag you can run the package with that sends the data without checking it. Force it the first time and then it should run normally. Why are you worried about having startup up code that only runs once, are you paying for space by the byte? You could also preload the database with a row with your idea of how much data is being sent.

Are the European salaries pre-tax or post ? The american ones are pre-tax.