mful

I've been looking for a combined task manager and calendar for a long time, and have often entertained building one for myself. Some feedback that is preventing adoption for me:

- Complex recurrence is key. I exercise 4 days per week. I only process my inbox (GTD-style) on weekdays. I triage bugs twice per week.

- Need to be able to view more than one day at a time on the calendar, and add tasks to specific days in that view — I plan out my weeks.

- Looking at future dates, it still shows my tasks scheduled for earlier dates. This makes planning difficult.

Ergonomic feedback

- Keyboard shortcuts (including arrow key navigation) does not work if you are focused on the name field of the task in the list. This means I can't really navigate, open, archive, reschdule tasks without using the mouse. Or at least I can't see how to. Might have to change hotkey scheme (use control or option?) as well, as command+A, for example, should probably still select all text in a field.

- I should be able to click out of the console — I keep trying to click or alt-tab out of it, like it’s spotlight, and it just hovers empty in front of my screen until I click to refocus on it and hit escape.

- When I've thought of building this myself, a key feature was adding tasks to the day's calendar (like, "I plan to work on X from 2-3:30pm").

Currently I use Asana for it's calendar view (note: this is not a calendar integration) and great keyboard shortcuts.

Anyway, congrats on the launch!

Modeling them as independent businesses that can decide — based on any non-protected principle they choose — to censor speech is too generic to be useful. They are closer to telephone or radio or broadcast TV companies than to private enterprise as an overarching category. Communication business are, of course, regulated around what they can and cannot say on air (the broadcast ones, specifically), and we probably need a similar approach to handling social media.

Yet we do not treat them like regulated broadcast media, which I guess is unsurprising in that regulation lags behind technology. In the context of Parler, it seems they tried to make the best of a bad situation.

But I don't know that we should cheer this as "the right outcome", even if, in this case, it seems justified (my gut is that this was the right thing to do, in this specific case). It's time to ask broader questions around whether these companies should have that power at all, or if we need government to step in.

Engineering learnings at big cos vs startups are wildly different. If your goal is to learn what it takes to start your own company, you are much better off working at even a mid-sized startup, than a big tech co. There are a number of reasons for this, but a particularly consequential one is that you will learn to build/manage/deploy applications from 0, and if things go well, through a variety of scales thereafter. At a mid-size startup you'll have less of the "from 0" bit, but you are much more likely to learn to deal with the scaling issues that manifest as the software that was built in the early days starts degrade with growing load. You will also likely be using similar open source tools in both the early & middle startup stages.

Building features in a large, existing codebase, in the robust tooling context of a big company, is nothing like building services from the ground up.

> The initial government was pro-American, but the consequence of pushing a country to have democratic elections is that they sometimes elect people that you don't like.

I don't the right prior here is "elections = real democracy", for cases like Iraq. The US has long history of installing "democratic" governments that are not actually democratic, but rather military states who violently suppress the people, but support US interests. The list of countries where this has borne out is long, but if you are interested, an easy place to start would be Cold War era South America (Guatemala and El Salvador being two straightforward examples).

What source would you prefer an open source UI library come from, that would avoid this concern?

Open source software lives and dies with adoption. Starting off with a (paid) development team, marketing team, and large initial user base (google internal) puts a piece of software in a good starting position, but doesn’t guarantee success.

Disclaimer: I work at Google, though not in a Flutter-related role.

It's hard to imagine you actually believe that maturity and experience are not related to job performance. Regardless, it might be helpful to think about experience as a hiring heuristic, like having a college degree: you certainly don't need it to be a good programmer, but having it is positively correlated with skill (in a way that is rationally causal, unlike, say, race). Recruiting, screening and hiring are massively expensive. Screening every inexperienced candidate who wants a senior position to find the rare gem would have an outsized cost.

> One mistake founders make is thinking that they need to be finding a lead investor first. By allocating chunks of your round into portions that are available for three types of investors — lead VCs, follow VCs, and angels—you can create a lot more urgency out of the gate

...

> If you talk to a VC who says they’d be interested in following if you found a lead, you should tell them that you have limited spots for follow VCs

Really interesting way to create urgency when there may not be any (yet).

> Are you willing to release your code, both in the sense of putting it out into the world and emancipating it from your ownership? Do you accept that your code could be renamed, rebranded, repackaged, rented, traded or sold? Would you be happy if your code made someone else rich, famous or successful while you saw no benefit at all?

I suspect it's a lot easier to say "yes" to these questions when you're just starting out (and thus picking a license) than when you see a bunch of other co's profiting signficantly more than you are.

This seems to be an attempt to fix that mistake (I wonder if the Redis creators would call their license choice a mistake?). Like a train gone off the rails, there are probably only messy solutions that no one is super happy about at this point.

I think your edit hits the nail on the head, as we’ve clearly had different experiences.

I should clarify that a lot of the hard problems at early stage cos are around creating something that is not only new, but is also a viable business, with minimal resources and huge time pressure. Whether the technical side is hard or not is another question entirely.

Anyways, thanks for the comment — in addition to providing a good counterpoint, it’s a good reminder for me that my experience is neither universal nor even necessarily the general case. YMMV.

Anyone else getting a little tired of the immediate reduction of any conversation around early-stage startup job opportunities to "comp vs FAANG"? As someone who spent the last 5 years in early stage startups, before recently accepting a FAANG offer, I'm starting to realize folks who only think about comp probably aren't good fits for startups. Here are a few quick reasons to take less comp at a super early stage startup:

- You will develop a wide breadth of skills you simply can't develop at FAANG, as you will be involved in product meetings, business strategy conversations, and will regularly eat lunch with the CEO. I imagine the reverse of this is true as well, in that there are skills developed at FAANG that are hard to develop as employee <50.

- You will get to fast-track your career progression, in that you will be in line for promotions much earlier than in large companies, as opportunities emerge.

- Companies (including FAANG) will look for folks with your skillset (my startup experience was a huge plus in my recent job search).

- You will work on hard problems, with passionate people; folks aren't punching the clock here. This is fun.

Also, for folks just thinking about comp, I'd like to gently point out that a 40 hour week on work you feel "meh" about is ~35% of your waking life. That's not to say you can't find exciting work at FAANG (I hope I have), but rather that there is more to a job than comp or career progression, and working with passionate folks on hard problems can be incredibly fulfilling.

Edit: formatting

Yes, they did. It's great that they explained their config choices, so that folks with domain knowledge can evaluate reliability of their test, and report back.

For those of us without domain knowledge, however, what the ACLU published is wildly misleading, to the point of being actively disingenuous. What are folks without baseline STEM education, much less AI education, supposed to take from the ACLU article other than "Amazon AI is racist and dangerously ineffective"? Do you think they are opening up the Rekognition docs to evaluate if the default config is appropriate for this test?

(By the way, I wouldn't be surprised if Rekognition is actually racially biased. I also feel a bit icky criticizing the ACLU here — they do great work, and I encourage everyone to donate.)

> I can't even begin to imagine where the idea that the hour of the day matters would have come from.

Many bodily functions such as hormone production are affected by your circadian rhythm [1]. Ambient light also seems to have an effect on quality of sleep.

[1] https://www.nigms.nih.gov/Education/Pages/Factsheet_Circadia...

I've been using the pre-1.0 version for over a year, and recently switched to using the beta of the 1.0, and just want to say thanks — this is far and away the best UI kit I've come in contact with. It's well-designed, comprehensive, customizable, well-documented, and fun to work with. Great work!