wmij

Thanks for sharing this. I grew up a few miles away from the Sikorsky plant in Stratford, CT. and as a kid remember seeing on a couple of occasions some of the experimental helicopters flying overhead. A lot of my friends parents worked at Sikorsky and sometimes would mention the program, in particular the ABC (advanced blade concept). It was mainly hushed but after what seemed like many years the experimental programs were moved out of Stratford or maybe scrapped. Then all the overhead traffic everyday were from the Blackhawk and Super Stallion programs the company was focused on to keep themselves going.

I still marvel at the Sikorsky Skycrane, IMO one of the most underrated aircraft ever produced. Whenever I see one I'm transported back in time seeing them flying over my neighborhood thinking that it was like a big giant wasp in the sky.

Yes. The ability to turn features on and off, especially on demand is an important part of the applications and services my team is responsible for. We have a few different levels where features can be enabled or disabled ranging from configuration injected into applications, configuration stores to lookup settings giving us the ability to expose/hide features.

To support per user or group settings we have a `canary` role that can be set to allow access to new features that have been integrated but not available to the general users. The nice thing about having something tied to roles is that the changes can take effect immediately without the need for redeploying, or reinitializing applications in our footprint. Also, the role based model can be made as fine or coarse grained suited to the app's and user's being served.

We tend to avoid encoding feature flags into URLs because users can bookmark them, revisit via history or navigate from old emails, messages, etc. and we'd rather not expose these flags or have them memorialized anywhere.

This just recently happened to me with an old eBay account I've had 20+ years. After reading the story in the document above, you could easily search/replace Apple for eBay and it's identical to my story, aside from emailing the CEO. The reason given in the permanent suspension message to me was a vague reference to the TOC docs and links to support that all lead to dead ends. After, resigning myself to not caring further, because I use eBay these days rarely, the next day my account was just as suddenly and without reason reinstated, as if nothing ever happened.

I'm left scratching my head as to what the reason(s) were for this to have happened and can only think of 3 possibilities.

- An overzealous, newbie type operator that suspended me by mistake - Some kind of error in automated flagging and error in review - eBay's radical way of engaging with me to spur me to buy/sell again as the account's last activity was more than 1 year ago

It is the "chief" type roles in a company - CEO, CTO, CFO, COO, CMO, etc.

Wake turbulence was a factor in the crash of AA587 from JFK back in 2001. The FO flying the take off encountered wake turbulence from a 747 that took off just prior and overused the rudder in response to the point it snapped the tail of the jet, an A300.

https://en.wikipedia.org/wiki/American_Airlines_Flight_587

Oddly a similar engine incident happened on the same United flight route back in 2016. Apparently it was a bird strike back then. Link: http://avherald.com/h?article=4999bec5

I knew about the story of Phil Katz having read this article before and was also a user back in the day, but just recently watched the movie 'Leaving Las Vegas'. Reading the PK article again in the link reminded me so much about the movie. If you haven't seen the movie it's worth watching and maybe an insight into the problems he was going through.

Ok, thanks. I set what I thought was a username during signup but looks like that was just the name. I see now there's a second step going to https://spacehey.com/settings and the username URL is working for me.

The original myspace used the profile name for URLs - https://myspace.com/some_name - maybe the reboot will eventually. I tried with mine and it was a 404.

Maybe, I'm being somewhat superficial but I can't help to wonder that the name of the company/app "Quibi" only hurt their launch and not helped aside from other factors pointed out.

I wonder how many times in talking about the app have people needed to spell it out or say it's pronounced like "kwibee" not "keebee", etc. I actually needed to go to wikipedia.org to see the exact pronunciation.

So much about the branding reminds me of the "Cuil" search engine failure a decade ago. I remember seeing the original name "Cuill" in some of my request logs and thinking at the time that it was some malicious DDOS bot that wanted to see my site as "see you ill". First time that I saw in the news about "Quibi" I immediately thought of the whole "Cuil" search engine failure. Not a great first impression, but that it was.

One aspect of Eddie's playing that rarely gets mentioned was his rhythm and chord playing. His chordal phrasings and how he could make a song sound huge for just a single guitarist was amazing. AND The first few early albums were mixed with the main guitar track panned hard left.

One of my favorites from his Edna character.

"Edna: Which of the following would you most prefer? A puppy, a pretty flower from your sweetie, or a large, properly formatted datafile?

Scammer: I would choose the datafile"

I'm also in the GitHub as a tool vs. social app camp and have rarely if ever had the inclination to visit the daily trending page (cue Pete Davidson - "my bad"). One feature I do like though is to see what repositories get starred by people I follow.

One thing has left me wondering after reading the article, is what the algorithm has changed to if it used to be just most stars in the given time period? Does anyone have any insight in how the trending repos are ranked?

For example from the article:

> ... the notion that stripe-samples/subscriptions-use-cases, which has 13 total stars with exactly zero new stars today is the new JavaScript “hotness” is a joke.

I'm left wondering then how did that get to the top? Views? Clones? API requests? Something else like paid promotion? Or manual curation?

Looks great man. Once you have your main board set (like you do), don't forget to think outside the board you've built to add things like a wah and volume pedal. For me these have both been staples of my rig that sit outside the "effects" part and can be be added/subtracted as necessary.

> Don't write unit tests. Don't accept pull requests. Simply write software for yourself and have fun doing it.

There's a careful balance here though right? For most projects your first users or clients are the unit tests. Why not have a future of repeatable client/user tests that insulate from regressions and to be your wingman to navigate future iterations? Also for me, I still review and accept my own pull requests on solo projects, because it is that last step when working on my own where I know I'm at a good point looking at my diffs and the last step in introducing mistakes.

First off, I'm so sorry to hear that you've been diagnosed with this condition. I haven't read through any of the replies to your question aside from a quick read through, so I'm sorry if any of my advice is redundant, helpful or not.

My immediate advice to you as an engineer is to remember that your most powerful and valuable tool is your mind. The ability to solve software engineering problems starts with the cognitive aspects of your knowledge, intuition, experience and who you are. An engineer's cognitive ability to solve problems and guide outcomes is the most valuable thing that we bring to any project we join or undertake.

Look for a team or project that values critical thinking to drive execution over just banging out code. Don't sweat being hands on in the long run, i.e. writing code and pushing features. Make the most of the work you're doing now to start honing your skills to be able to drive things like architecture, implementation choices, etc. based on experience, lessons learned, people you enjoy working with etc.

Also, keep in mind that you have a unique albeit unfortunate set of circumstances that can bring a perspective as you're going through this to what works and doesn't for others in similar circumstances that want to have careers in software technology. Be open to an awareness for areas where you can help solve problems and be involved in building solutions for others in a similar circumstance as you're in. Look for ways to develop products, tools, advisory groups, training, etc. that can help engineers with similar disabilities.

I wish you the best and again, I'm very sorry you're facing this. I hope that my thoughts help in some way.

Are there other sources you're using besides LinkedIn? I ask because every job listing I clicked on is taking me to LinkedIn as the next step to learn more details and apply. I realize that you're probably just getting this off the ground and leveraging LinkedIn's data, but I'd trust and recommend a service like this where there are native listings and not just an aggregated wrapper over LinkedIn. Why not just use LinkedIn to begin with?

With the post a resume feature it's not clear how that data is being used to connect me to "the right recruiters" and makes me wonder if this is just a way for your service to collect and sell my resume and others to recruiters as data vs. matching resume content to the jobs directly then notifying me.

Also, if you have other sources for jobs besides LinkedIn, native or otherwise, I'd trust this service more if the links/listings had a LinkedIn (or wherever) label or icon to let me know the source before clicking through to the details.

Other than the concerns about LinkedIn as your only source of content and how your service is using my resume data, I think the site itself is easy to use, understand and ultimately could be a useful tool in finding remote work.

"The treasure of a life is a measure of love and respect The way you live, the gifts that you give In the fullness of time It's the only return that you expect".

- Neil Peart, The Garden

Something that has helped me with recognizing incremental progress on long running side and personal projects where completion seems so far off is relating it to the crawler vehicles NASA used to get the Space Shuttle to the launch pad.

https://www.nasa.gov/content/the-crawlers https://youtu.be/N1WvVRavXsI?t=60

Incremental progress and speed seem slow (1 mph), but eventually you will get into position for launch.

This has helped me understand how weight and physical constraints (these == time commitments to a primary project, family, sleep, etc.) impact velocity on where you start from getting to an eventual goal (starting a side project and coming to release, launch, etc.). Some things just can't travel faster than 1 mph due to external constraints.

I was at an Air Show at the old Willow Grove NAS in Pennsylvania when I was a kid and there was a Navy S3 Viking Jet set as a ground display. They were allowing people time where you could get into the cockpit. A 7 year old kid was in one of the front seats and activated the ejection mechanism and was killed after being ejected and landing on the nearby tarmac.

As I remember, the other people in the plane at the time were injured due to burns and other debris but survived. We were about 150 feet away from the planes on display and I remember hearing how loud and sudden the explosion was. Not sure what happened my Dad said looks like an ejection seat just went off.

I sometimes think back to that day and always do whenever I hear about or come across stories ejecting from an aircraft and how terrifying it must have been to that kid.

I've been using http://zaa.ch/jsonlint/ for a while. Does validation and formatting. All in browser.

My dad was part of this unit.

Back around 1994 we were talking about data and I was telling him about CD-ROMs and how you could buy libraries with public address and phone records. He was ecstatic at the prospect of finding his fellow veterans of the 23rd and the 3132. He would give me lists of names that I would look up for him with potential matching phone numbers. He ended up getting in contact with around 150 men and helped organize what became yearly reunions in the late 1990s because of our research. It was one of the best side research projects I ever did. This was all before Google and online phone search indexes.

My dad passed away in 2005 and I so wish he was here still to see how much attention and recognition the Ghost Army has received. I always felt that much of the attention and recognition the Ghost Army has finally received over the years were in part from my dad's efforts to reach out and help organize the reunions and reconnecting with so many of the veterans in this unit.

I was fortunate to see these planes from the D-Day Squadron fly out of OXC, Oxford CT. this past weekend. There was a really big turnout at this small airport in my backyard to support and have interest in the current mission. Never forget history and the people who made it. Every tech innovation whether aviation, software or textile is important. It was amazing to see so many veterans also connecting to their past and honoring the present. More info here http://ddaysquadron.org/ and here http://ddaysquadron.org/d-day-squadron-launch-week/

NYC area driver here... TLDR the entire article but I'll give my first hand perspective to say that "T" (taxi) and "L" (livery) plated vehicles on the highways in the NY metro area DO significantly add to congestion as the drivers keep their speeds well under the limit while traveling in passing lanes. Frequently I see these non "cab" "T" and "L" vehicles that I assume are "transportation network" company contractors driving unusually slow because they're either on their mobile devices (looking for pickups?) or driving so under the limit that I assume to not break any GPS speed monitoring rules enforced by these "transportation network" companies, or just generally inept.

I'm not advocating speeding by any means, but after driving 500k+ miles in the NYC metro area you can spot the ineptness and/or driving under fear of speed monitoring of these "T"/"L" plated vehicles. All it takes is for one to be driving 45 mph in a 55 zone on a two lane road with an already congested merge ahead, or they travel in the left passing lane at speeds well under the limit preventing other motorists from advancing, or overall poor driving, then it's a chain reaction of braking and delays mounting behind them.

I've always assumed that the monitoring of these drivers adherence to speed limits is the reason why they travel noticeably slower than the average driver in normal traffic. If that's the case it unfortunately causes the average capable driver to become indirectly part of the "transportation network"'s speed monitoring resulting in delays for everybody.

In the relative absence of these "T" and "L" plated vehicles, I've driven in moderate to heavy volumes where the average speeds are in the 60-65+ MPH range. However, when the livery vehicles start to increase within similar volumes of traffic the average speeds seem to drop and the congestion related delays seem to increase.

So if you were to ask me "Do transportation network companies decrease or increase congestion?" My answer would be "yes". Why? Based on my observations, I suspect it's related to the speed monitoring of the "transportation network" company and a tendency of the drivers of these vehicles being inept relative to other non "transportation network" drivers.

I also really like CouchDB and can attest to it being a reliable part of the stack. I'm using it on a personal project (Node/Nano/Couch) that has the potential for needing to store a lot of data but hasn't gotten there yet, so I can't speak from experience yet on performance/scalability. It has been so far great in production and also great for the normal CRUD parts of this project.

The main reasons I chose Couch over something relational like MySQL was essentially 1. to have a a clear path for data to go as JSON from server/API/client without the need for mapping, 2. Schemaless to allow for quick iterating and development, 3. Easy to start with local first development and then rollout for deployment. Also, I hadn't worked on a stack with a persistence strategy that was solely document oriented so it was a fun and good learning experience.

A few things I learned along the way:

I still needed to create externalized "views" of the data that either combined data from multiple documents and the need to hide private data. I still needed to serve lists of data in pages. More importantly I needed to provide a lot of adhoc reporting over the various data I'm storing across multiple Couch dbs.

The views and paging are all easily solvable with Couch, but so much easier to implement using SQL and it feels like I'm just pushing that need or compensating somewhere else in the implementation. But the friction around quick reporting has made me second guess choosing Couch/document based vs. something like a MySQL/ORM.

The author's point of the custom query language (Mango for Couch) and loss of tooling ecosystem has been the biggest problem for me on this project and I'm considering migrating to a Node/Sequelize/MySQL stack just to avoid wasting future cycles trying to quickly report on the data I'm storing. When the project started the reporting aspects weren't as apparent as they are today since the project has evolved and other requirements became necessary.

If anyone has any experience or recommendations for tools that can easily do adhoc reporting against CouchDB or documents in general I'm interested in hearing about them.

From the interview, this struck me the most:

Q: "How do you produce a great culture in a smaller team--like one operating an airplane or perhaps building a startup?"

Sully: It starts with core values. It starts with leadership by example. Trying to live what you believe and make it apparent to those around you. Especially on a small team, not a single word, not a single interaction goes completely unnoticed or is without consequence. If you walk the talk, people notice it. And if you don't, they notice it. So I think trying to model the attitudes, the behavior, the values that you believe in, that you want to see. If you do that, it can be contagious. Courage can be contagious. Compassion can be contagious. Competence. Continuous learning. Constantly striving for excellence can be contagious. And that benefits not just you and your team but also society.

Assuming your project has an issue tracking system, start adding issues - bugs, technical tasks, improvements, etc. for things you find and discover. If there are no unit tests, add an issue to create unit tests. If there are missing unit tests, add a technical task to create the missing unit tests or expand coverage.

If your project doesn't have an issue tracking system, then recommend something simple that fits into the tech you have, i.e. GitHub or whatever.

Use the issue tracking to create and document the shortcomings and technical problems you're seeing so that the more senior and leads of the projects have documented visibility into what you are seeing with the code and the application.

For example create a technical task: "Add unit test coverage for user sign up" or for whatever gaps you're seeing in testing.

In my projects I always make sure that we have a category available for "technical tasks" and/or "system stories" to document anything that is engineering/code/refactoring/devops related vs. user facing functionality.

If these channels don't exist, then you need to recommend that they are established so you can document and track specific issues you're seeing.

Also, since you've recently joined, any team that brings on new members should be open to what you're seeing as someone new with a fresh perspective and be open to learning from you as much as what you need to learn coming into a new project. Hopefully, your team has a culture that is open to new ideas and if so, don't be shy on bringing up technical issues in standups, chat discussions, PR comments, etc.

Just be proactive in documenting your specific issues, ideas and what you're seeing, ideally through the established issue tracking system. Be prepared to offer, document and communicate solutions to the problems and gaps you're seeing.

Good luck with the new project and I hope it works out for you and your team.

Isn't this why you do pull requests, code reviews and QA before deploying? You need to make sure that the more senior(s) on the team and proper testing catch these things before deploying.

You forgot the 'ba dum tss'...

Some colleagues of mine talk about the prevalence of companies doing this man behind the curtain thing all the time while claiming that there solution is AI/cognitive. When we come across examples of this happening we just refer to that Seinfeld Moviefone episode and say 'Why don't you just tell me [foo]' - or whatever the "AI" is trying to solve.

https://www.youtube.com/watch?v=gSQ6q_rGpI8

It never fails to get a good laugh.

Anyway, I think that human interaction for the training aspects of AI to prepare data, label examples, test models, etc. is really hard to automate entirely and should be considered part of the development process. The execution side of an application component that is marketed as AI/cognitive however is not true AI unless it is totally free of human interaction.