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.
Recurrence is something we will improve. But you have pretty specific ones :)
We will actually add a planning view with a full week. We are definitely aligned on that. Stay put.
For the future dates, yes indeed it's not ideal. We are in the process of fixing that. Well spotted.
For the navigation, again, need to improve you are right. You need to ESC to come back to arrow navigation for now.
Clicking out of the console is not easy to solve unfortunately. We are on it as well. What you can do is either focus on the console and press ESC. Or you can hit CTRL+SPACE once more and it will hide the console.
We do support "do something on DAY at TIME for DURATION" but it's still a bit buggy. We need to improve it :)
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).
Ironically whole thing started with CIA staged double coup(first one did not work apparently) in Iran during 1953(declassified recently). It was so successful that they copy-pasted it to LATAM and elsewhere. [1]
Interesting fact: Kermit Roosevelt Jr. a grandson of U.S. president Theodore Roosevelt, played the lead role in the CIA-sponsored overthrow of Mohammad Mossadegh, the democratically elected leader of Iran, in August 1953. [2]
After World War I the British redrew the map of the middle east pretty arbitrarily after defeating the Ottoman Turks founding modern Iraq. It wasn't really guaranteed in the first place to include people who like each other.
I'm totally in agreement with you, and yet I'm still saddened that people fall prey to this trick which they have in their power to fix, by learning to forgive and live together in harmony and piece. The tragedy is how hard it is for people to come together and collaborate in good faith. And when that truth is exploited it's even more sad.
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.
Not the OP but I've quite a lot of trust in Microsoft when it comes to long term support and stability of their frameworks. They have their problems, but when they commit to something it's usually supported and stays around.
> What source would you prefer an open source UI library come from, that would avoid this concern
Note: "this concern" is not "the library may go away or be unsupported". That's true of any open or closed source library.
The concern specifically is "this may get hyped to the point where it feels reasonable to depend on, then go unsupported". And that's never a surety, but frankly Google makes it MORE likely than, say, some random internet package that it will build enough of a groundswell to be seem safe, then suffer a sudden Nest-API-like strangulation. (Convenient for my argument that that announcement came out between my original post above and this one, but it's convenience that is directly my point).
Some rando package is unlikely to be broadly adopted unless it's actually good stuff...and the good stuff tends to get well supported, even if that means the occasional fork. Google has name cachet that can build support quickly, but the track record doesn't support that.
There's never a guarantee...but there are performers that are above average risk, and that's where I put Google when it comes to APIs and libraries.
I am excited by the Quasar framework, getting ready to launch their version 1.0. The vision is to simplify the Vue stack and automates and simplifies the onerous elements of webpack, linters, tree shaking, etc. It uses Material for UI and lets you push the same code to IOS/Android (via Cordova), desktop (via Electron), PWA and SSR.
What sold me on the framework is the focus on good documentation and sensible defaults. I could use more example code, but for its youth the framework is very exciting and has really made picking up Vue much more straightforward.
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 you are probably right. When starting the project, creators value their work very little, but value any attention given to their project very highly, thus a permissive license makes sense. Only after success hits do they regret it.
Even so, if someone was seeking fame and fortune through OSS (a somewhat foolish mission, but whatever), I would still probably recommend they release their software with a permissive license as companies are far more willing to get on board with MIT/Apache licensed software. I mean just look at the incredible amount of hate Facebook got for having the gall to offer a free patent grant with gasp a condition that you not sue them.
The best way to personally profit from OSS is very oblique. Assuming you make a kind of software useful to businesses like Redis (not end user software), it can look very good on a resume, can help you land some speaking gigs, maybe a book deal, and so on. If you build up your reputation like that, it should be possible to land a cushy, high paying job at a tech company somewhere or high paying support consulting.
This is true. Most people who start an open source project don't do it for financial reasons. Usually they want to learn, to build a reputation or to create a good product just for the sake of it.
Later, after many years, the developer sees other companies making a lot of money using their OSS project but they themselves are basically broke; they're forced to work for other companies during the day and they still need to spend nights and weekends to maintain their OSS project on the side.
I'm in this situation right now but actually I'm very happy that companies are making money on top of my OSS project; I'm 100% certain that these companies would not have used my project if it wasn't MIT open source licensed.
Most companies who used my project had alternatives in the form of other OSS projects or third party services so they put a lot of trust in me and my project at the beginning. People underestimate how hard it is to compete at the beginning... Even if you're giving away product for free; it's really hard.
Just try to launch an OSS project on GitHub and try to get it to 1000 stars; I see lots of people try all the time but almost none of them make it.
> I'm 100% certain that these companies would not have used my project if it wasn't MIT open source licensed.
Nope, instead they'd have hired you or a programmer like you — or figured out a way to make money from GPLed code.
The trouble with the MIT & BSD licenses is that they encourage corporations to freeload. That's why Google, Facebook, Amazon & Apple love them so much.
The great thing about the GPL is that it levels the playing field. We all get to share in a software commons.
In spite of the MIT license and my project having thousands of GitHub stars, it took several years before any big reputable company started actually using it.
The problem is that if tou want to make an impact in your industry, you need big companies to be using your project; to achieve this, you need to distribut your project under a license that they like.
Facebook got hate for making the patent grant skewed, i.e. you have no right to sue them for /any/ patent of yours that they use in return for not being sued for the /specific/ patents that cover React etc.
Nope. Nothing in the patent clause made any restrictions on your right to sue Facebook.
It simply made the patent grant conditional on not suing them for patent infringement. i.e. if you want Facebook to pay royalties on your patent, you would have to pay royalties on their patents. If that’s not reciprocal, what the hell is?
- If you, as the licensee, sue Facebook on /any/ of their patents (not just on the ones that are subject to the patent grant), the license terminates immediately.
- On the other hand, if Facebook, as the licensor, is only promising not to sue based on the /specific/ granted patents.
The "any" vs "specific" part is what people where annoyed about.
Note that if you required CLAs that allowed license change you can change it later (e.g. OpenText did that). If you just accepted contributions you can't change the license without agreement from all contributors.
Depends on the license. You can just fork a MIT project and incorporate it in a project with a different license. The MIT licensed part would still be MIT licensed, but any newly written code not. Makes little to l no practical difference.
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.
As someone who did a long string of failing small companies and finally settled in among the FAANGs, I respect your experience but disagree with everything you said.
Wide breadth of skills? If you’re hired as a code monkey you’re going to monkey code. Nobody ever asked me what I thought about the latest business partnership or synergy strategy. Just code.
Career progression? Another nope. With only a few people in the company, you can’t go up and you can’t build a team under you. Who are you going to manage? There’s nobody under you! My startup coworkers used to jokingly give each other fake “Senior Director” titles which were meaningless of course because there were two managers in the whole company, one was the CEO. Even if you did somehow get a fancy title or a team under you, and got bought by a big company, you’re back to “3rd engineer from the left” in their hierarchy.
Hard problems? I don’t know, not in my experience. Just problems unappealing to the bigger players.
And for all that you risk the company not being able to make payroll or canceling your benefits. Sorry, I can say definitively that working at small companies probably set my career back 10 years.
EDIT: I suppose it’s highly dependent on the company.
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.
I’ll also point out something I learned the hard way. Junior folks take note: Career progression, if important to you, is something you absolutely must ask about and confirm during your interview. Some employers want to hire you as a mid level engineer and have zero intention of ever promoting you past that. You need to be able to identify and walk away from those companies. You also need to take responsibility for it. Your manager won’t. For a long time I had this romantic notion that if only I did a really awesome job, someone would notice and career growth would happen. It just doesn’t work this way. You need to take direct action.
I remember several exit interviews where I told my managers that one of the reasons I’m leaving was no upward career movement. They looked shocked, like they couldn’t imagine that would be important! Maybe they were legitimately surprised, I dunno. I’ve also had managers say things like: “oh trust me, you don’t want to get promoted or go into management, it’s so much stress!” They will try to gatekeep and you need to push through that.
But, as "First Engineer", you get maybe 1/25th or 1/50th the equity of a founder, and you might join 3 months after the company's "founding" pre-product / pre-product market fit. The company might pivot substantially 5 times before finding fit, or might not find fit at all, or it might take 10 years to see any benefit in the 1% of cases where the company does make it.
I'm not disagreeing with your comment, but if the reason you join is to work on hard problems with passionate people then there ought to be a strong reason why it makes sense to be engineer #1 and not yourself a founder.
Not to say it can't happen, but I dislike the meme that early engineers for startups are working on "hard problems". From a business and social sense, for sure, having to develop quickly, pivot even more so, and pound dirt to carve out a fit is an experience in itself. But, from a technology side, most startups are positively mindnumbing for engineer one. Think your Ubers, your Instagrams, your Facebooks, your Dropbox, the problems don't get technologically interesting until you start doing them at scale. Until then you've got a bog standard php/phython/whatever web/mobile app. Compare that to the opportunity to work with the cutting edge in machine learning, or deployment at scale, or bleeding edge hardware that you'd get at your Facebooks, your Googles, your Microsoft. To me working at a startup I expect hefty comp to be giving up getting to work on interesting problems for the chance of having more agency and winning the lottery if we get huge. YMMV of course, but for me and I think a lot of tech people I'd rather do interesting work for a soul crushing application than soul crushing work to #changeTheWorld (especially if the former pays upwards of 5x more and the latter only pays out to the founder(s)).
For future career prospects, a stint at FAANGM is a safer bet than joining a small startup. Most startups fail and it may not easy to find another job right away. If you're at a big tech company, you'll have the credential to find a job more easily (and with their job stability you can generally choose to look for one while working there).
>Anyone else getting a little tired of the immediate reduction of any conversation around early-stage startup job opportunities to "comp vs FAANG"?
The difference is so big, that I hope it continues to get repeated, until we start seeing a fairer distribution of equity.
>- 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.
Yes, this is true. Note, however, that this exposure isn't necessarily that transferable, unless you plan to become a founder yourself (which isn't a bad idea).
>- 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.
Only internally. It won't transfer to long term career progression unless your startup happens to be widely successful.
>- Companies (including FAANG) will look for folks with your skillset (my startup experience was a huge plus in my recent job search).
Nah. Experience in general is a huge plus in today's job market - but non-founder startup experience is no better than any other experience, unless your startup happens to be widely successful.
>- You will work on hard problems, with passionate people; folks aren't punching the clock here. This is fun.
People are passionate and not punching the clock in most places. You certainly do get to work on hard problems at small startups much more though.
>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.
And your comp today directly determines how much of your waking life down the road you will need to spend on work. Higher comp today means financial independence tomorrow (allowing you to work on whatever the heck you like).
Note: I'm a happy early engineer at a startup that offers competetive comp (based on my personal evaluation - and I'm normally a skeptical person - the expected value of my compensation is clearly higher than what I would get at FAANG), so I'm not agains startups; it's just highly unfortunate that most startup founders are incredibly stingy with equity.
They are stingy with equity because it's easy to make a bad hire and then be unable to fix the cap table. I do think there should be a better balance, though, and agree that they can be quite stingy even with those who turn out to be good hires.
I feel being first engineer at a startup gave me the skills to found my own company and make a living on my own terms, which is ultimately what I want from life. Being super rich isn't too important to me as long as I feel I have broken out of the mold and am on a path to greater personal and creative freedom. I honestly wanted to kill myself after a few years at a well-liked, growing 1000 person company. It was too confining and I was too distant from the real world. I can't imagine ever being happy at a FAANG Corp, even if the work is initially interesting. The weight of layers of managers above always becomes unbearably heavy for me, especially since I naturally struggle against authority.
Well, while large companies are moving towards immediate vesting, startups continue to have 1 year vesting cliffs, so they have plenty of time to fix the cap table after a bad hire.
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.)
- 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!