Live data from Hacker News

Suppose I wanted to kill a lot of pilots

historyofyesterday.com

171–178 of 178 posts

Re: Suppose I wanted to kill a lot of pilots

#171
post #92

Earlier quoted context omitted.

You need a distinct pre-mortem where everybody brings a list of the ways a project could fail. https://en.wikipedia.org/wiki/Pre-mortem

I just deployed something worldwide that took about six weeks to develop and our initial guess was about two weeks, so this is fresh in my mind. I was able to lay out a list of work items at the beginning that stayed like 80% the same from the beginning to the end, but didn't account for the possibility that each one of these could be push-button, or could lead to a blocking problem that needed a day or two of resear…

I do remember doing a risk assessment as part of a proposal for a client. They pushed back hard on a number of points and got the sales person to remove them.

The funny thing is the risks that were removed all occurred during the project. We should have stood our ground.

Re: Suppose I wanted to kill a lot of pilots

#172
post #97

There is a good book employing the TRIZ mindset for self-improvement called "How to Be Miserable: 40 Strategies You Already Use"[0]. Although some of the outcomes the book lead you to can seem banal, if you approach them from the perspective of how to optimize misery, it can give you a new perspective. It certainly did for me in some areas. CGP Grey also made a video based on the book, called "7 Ways to Maximize Mise…

I have always had trouble making short term attainable goals. For example I want to restart doing yoga. But it's been a few years since I've done yoga and now I can no longer touch my toes. Whereas before I was able to do the full primary sequence of ashtanga. Every time I think of my decline it kills any motivation to do anything to stop it. Anyone have any tips?

Re: Suppose I wanted to kill a lot of pilots

#173
post #115

Earlier quoted context omitted.

It seems pretty snappy aside from the first page load (and refreshes, ...). Not perfect (some actions take a few frames sometimes), but not anything I'd spend more dev time on. The first page load is nightmarishly slow. I tend to avoid services that pull in that much data because they're nearly unusable in low bandwidth scenarios (e.g., lots of stores or other commercial buildings made from steel, if you wanted to ch…

Thanks for the feedback! After first load the assets should actually all be cached in your browser, so subsequent loads will be much faster (including full page refresh). But yes the initial bundle size is one of those things we could probably spend more time optimizing for. We recently released desktop apps (and will hopefully release mobile apps soon) where this is of course a non-issue. Could you tell me which key…

I appreciate the response! Sorry to only be pointing out problems by the way. Plenty of other components do seem well done. I just know that in your shoes I'd want to know where users struggle.

> Initial load

I just poked around a bit, and I think the other commenters on mobile or firefox might mostly just be noticing main.[key].js being slow. The inital load is structured as a couple of sequential requests followed by a lot of js (device dependent, 0.5s - 7s+) and then a lot more requests fired off mostly in parallel.

> Refresh bandwidth, caching

Your heaviest assets are set with max-age=0, and the server often responds to an if-none-match header by regurgitating those assets. Refreshing after doing stuff in the app (or just waiting) for 3min reliably generates nearly as much latency as a cold load.

If you expect most mobile users to prefer your mobile app it might not matter, but a workflow that looks like doing something on your site, navigating to another site or app for a few minutes, and then coming back can often trigger a mobile browser to refresh the page -- especially on lower end devices where the cold load is most expensive.

> Native apps

Awesome!

> Shortcut hijacking

Mostly a misunderstanding on my part. It looks like the following things are happening:

(1) Keyboard hooks apply across the whole app, even in screens where they do nothing (like using CTRL+SHIFT+I in the settings) or when the elements they would apply to don't exist yet (like navigating between cards).

(2) I falsely assumed the cheatsheet of commands was comprehensive.

(3) Nearly every navigation keystroke (space, shift+space, arrows, ...) is actually used by something in the app, mostly stuff that doesn't work till you have cards and friends and whatnot.

The net effect for me was that it looked like all my favorite shortcuts were being swallowed and not doing anything useful in return. I don't have much useful advice here, but easy discoverability of all commands might be nice.

> Privacy

That makes sense. Reflecting back on exactly why I found that off-putting in the first place, I don't necessarily think the problem is with the search feature (some people probably disagree), but with the fact that it wasn't clear the information would be public when I was first asked for it. That might lend itself to a simpler solution.

Re: Suppose I wanted to kill a lot of pilots

#174

Earlier quoted context omitted.

This. Most engineers delude themselves and plan for the happy path. I was famous too for "being negative." In the planning of a complex project once a rather dull engineer, after I had just pointed out a major potential problem asked, "Why are you so negative?" "I'm not negative, I'm planning for success."

I've seen a lot of engineers be negative in a destructive way. They tear down ideas, but fail to offer solutions. Usually this is about their ego rather than a desire to help the team.

I agree that's a dark pattern and something I hope I have never been (I realize you weren't accusing me of that).

I try to ask questions like, "What happens when X goes down?" What happens when network latency goes up?

I quit a job over this one. I had designed an API for a consumer IP/IR control type thing. You say, "I want to tell that thing over there to turn on." The API does the thing, and then exits. The API does retain state-- but only in as much as it wakes up when it gets a packet from a device, parses it, etc, and makes any internal state changes.

Well, management decided they wanted to demo it running continuously for days at CES. Now if you've never done a demo for CES-- it is the worst environment possible. Networks go up and down, there is so much radio traffic that WiFi, BT, anything are unreliable.

I told them I would need to harden the API, that it wasn't designed for that scenario and most of our tests didn't last more then a few seconds keep in mind that at this time, this was a skunk works sort of thing that had not yet been productized. Also, keep in mind there was an aggressive, aggressive development schedule.

They predictably lost their minds. I know its crazy right? Test for the exact scenario you plan to show to customers? They forbade me for doing any sort of test like that and charged ahead with the demo. A month later a manager dressed me down in front of my entire team. About the bug that they had forbade me to fix.

I walked out and never went back.

EDIT: That turned out to be more of a story about ruthless management and constructive dismissal.

Re: Suppose I wanted to kill a lot of pilots

#175
post #150
post #73

Earlier quoted context omitted.

> Sounds familiar, maybe like a scathing criticism of OOP? No, not really. For example: > - make it hard/impossible to set the true state of the system in its entirety Strangely enough, environments like Smalltalk allow you to do exactly that, but other environments not so much.

The problem is, semantically and linguistically, there are two OOPs. There's Smalltalk OOP and Java OOP. I haven't worked with Smalltalk but from everything I've heard, it "does object-oriented right ". Unfortunately, Smalltalk just isn't popular (not even in the top 50 on the Tiobe index, though it fares slightly better on Redmonk). For better or worse, Java is massively popular, and thus the Java conceptualization…

In which camp does Simula (arguably the first object-oriented language) fall?

In which camp does CLOS (the Common Lisp Object System) fall?

Re: Suppose I wanted to kill a lot of pilots

#177
post #140

Earlier quoted context omitted.

It's not a redundant data structure if you need it to figure out the necessary changes. You are free to choose other approaches for your frontend projects. Just don't expect to get hired into larger teams easily.

> It's not a redundant data structure if you need it to figure out the necessary changes. And why exactly can't you "figure out the necessary changes" without it? > Just don't expect to get hired into larger teams easily. Honestly, I see that as a win-win.

Seeing how much you like trolling, that is not a surprise.

Re: Suppose I wanted to kill a lot of pilots

#178
post #140

Earlier quoted context omitted.

> It's not a redundant data structure if you need it to figure out the necessary changes. And why exactly can't you "figure out the necessary changes" without it? > Just don't expect to get hired into larger teams easily. Honestly, I see that as a win-win.

Seeing how much you like trolling, that is not a surprise.

Sincerely held opinions are by definition not "trolling". I just fail to see that as relevant, just as I fail to see the number of Big Macs being sold globally as being relevant to food choice criteria.
Post reply on HN