I think there’s something to be said for having an item to center a ritual around. Similar to the “talking stick” concept. Gives people an excuse to share, which can otherwise be hard to find.
Also - great idea while in lockdown.
924 karma · joined May 4, 2018
Also - great idea while in lockdown.
I could use the meeting rooms just as much if I wanted. I don’t see them having very special facilities.
Apple is famously a forerunner of personal computing. They invented most of the mobile UI design language used today. Every OS they’ve built is extremely premium. Their natural language processing is best-in-class.
How are they possibly “below average at best”
A "huge" application can be broken up with code splitting/dynamic imports. Initialisation can be seeded with serverside data or saved in browser storage between pages.
The only semi-unavoidable part is the "subsequent network requests", but even these can be sped up with caching, batching, etc.
> It requires a lot of dev time to properly handle everything.
But yeah, these things take effort
Further, tree shaking is much harder with a dynamic language.
My understanding is that a WebAssembly implementation would usually be smaller than a JavaScript one, assuming you’re using a language without a runtime.
Languages that perform their own memory management (C, C++, Rust etc) will be extremely small. Just one big array of bytes/instructions.
Something like this is exactly what I need! Looks fantastic.
As a “junior” person, I generally agree with this. But not prescriptively, more like a rule of thumb.
Age and life experience are not exactly connected. A younger person could have more life experience than an older one, depending on the intensity and selection of their past experiences.
So although I agree that life experience often helps you be a better manager, and junior people often have less, I don’t think that fact justifies a prejudice.
I don’t claim to be one those people you describe, but this is also what I’ve found works well.
Some books are packed with amazing information, line after line. There is great value in reading the entire thing - the overarching narrative of reading it linearly provides additional value to reading it piecewise.
Other books might present one or two great ideas/concepts, but spread them out over a few hundred pages. These are the books I read piecewise, to “get the gist”.
The tricky part is knowing which category a book falls into. I imagine there is a level of required prior knowledge/experience before you can do this.
Ironically, there are books I used to think weren’t very valuable, or presented “obvious” ideas. Later, I’ve come back and found them incredibly informative. For what I thought was “basic” in my first year of university, I now respect as nuanced and important first principles, for example.
They’re a startup, they need to focus on the fastest and most effective way to create value for their users, today. No point optimising the product if the company dies before it starts slowing down.
With that said, I think product/solution ambiguity is rooted in confusion about the problem being solved. It comes from starting with an idea, and not a painful problem that people already experience. Alternatively, from a problem that exists, but is incredibly ill-defined.
It would be disingenuous for me to comment further, because I'm still learning! My view is it's easy to create a solution, but really hard to find & well-define a really painful problem.
Going further down that line of thought, pen and paper really works. You don't have to bother with colours, fonts and rounded edges.
A fun exercise I do, when solving a creative problem, is this:
1. Divide a sheet of paper into 8 squares
2. Set a timer for 40 to 60 seconds
3. For each square, start the timer, and attempt to draw a different solution in each box
This forces you to stop worrying about the individual ideas, and focus on generating lots of them. It also gets you past the "immediate solution" thoughts you have, and into more interesting ones.
At the end, you can collate the ideas, and pick the best parts from each one.
I only recently realised that, for me, "dev mode" and "product mode" are entirely distinct. I'd been trying to mush them together in a haphazard way, with haphazard results.
In my opinion, this is a really important insight. It's analogous to the De Bono thinking hats, divergent/convergent thinking, etc – distinct phases of cognition that can't happen simultaneously.
> If it helps, try to make rituals around the reflection part.
Great idea! Is this something you learned in art school?
In my experience, every art student seems to incredible at "shipping". I've always been jealous. Way better than most CS or business grads. I guess it's a core part of the degree?
Whenever I'm building something, I get really strong tunnel vision. Part of what makes me a good engineer – submerging myself extremely deep and specific context, "the zone" – seems to work against me becoming a good product person. There's always product stuff I seem to forget, or don't pay attention to, or I end up focusing on the wrong things.
After "shipping", however, the tunnel vision goes away. I can view my work with a level of clarity. Some features I built might be valuable, and some won't.
By splitting my work into build/evaluate phases, rather than continual building, I've become much better at focusing on the impact of what I'm building, and not the engineering in-and-of-itself.
I have a terrible habit of spending too much time building, and not enough time thinking/marketing/etc. This is how I try to manage that.
Iteration speed is incredibly valuable. You often only need <10 users to get an idea about how useful your MVP is.
This sounds similar to linked data formats like JSON-LD
I've heard, on HN, people lamenting that an early vision of computing –– people creating their own applications –– has not arisen. Most people, outside of CS, have no idea how computers work.
I think this post, the no-code movement, and products like Zapier show that there is a future for this. People don't need to know how computers work to create their own services – SaaS applications abstract over the implementation details, and APIs provide the interfaces for prosumers to connect them and build their own solutions.
I'd be curious to hear your thoughts on Zapier. How do you think we can go beyond "API connector" products?
What pains did you have? Docker support was a big one for me, but otherwise I haven’t encountered anything too bad.
I think this is a really nice tool for information synthesis. Instead of manually finding info to think about, it appears naturally, and improves the quality of your writing and thought.
However, for this to work, it needs to find information relevant not just to the last sentence, but your entire of thought. This is better-represented by prior paragraphs than the current sentence.
Further, you probably already know what you’re going to write about, so you could “pre-seed” the results with special words. And if you’re looking for something that’s not appearing, you’d need to search for it.
Just very random product thoughts. Cool prototype!
Potentially operate one or two paragraphs at a time, presenting all related information, and allow people to "pin" search terms.
This would make writing much nicer by collating the information as you need it.
The common advice is to read the abstract and then conclusion, and only the method if you want to dig deeper.
Try to find a well-cited “meta analysis” or “literature review” in the field you’re looking into. These will common on the current state of the research field, and reference influential papers. They’re a great starting point.
I find myself needing to do something analogous to “suspending disbelief” when reading about a new topic. There is usually a lot of terminology I don’t understand, but I put up with it for a while. Eventually it makes sense. Other times, I need to look up the actual definitions.