d0m

I think most great products have that recursive iterative cycle.

Yeah, a bit ironic but don't let that stop you from reading and understanding the content.

Well I'm not saying to become a typography expert, but it's important to understand how font types relate to each other and how to increase clarity based on the context. For instance, print vs slides vs web page, or a little bit of content vs some heavy content could probably be improved with different fonts. Also, even if people don't notice it, the typeface/font is part of the branding and it creates different experiences. I.e. it makes something look more friendly or serious.

Depends on what you're building. But sure, if you can remove the "cross-platform" spec. and say just build a desktop app on Linux, use whatever suits your boat.

Personally, I find it amazing to have one engineer builds a feature end-to-end from the server to the web/mobile devices by using the same language and re-using 90% of the code across all the clients.

A lot of engineers have the mentality of "engineering is hard, but design is just whatever some color matching and styling".

I'll prob. be downvoted but here's my honest opinion: I think you'll gain a lot career-wise to learn about UX and UI. You'll be able to understand products in a deeper level from the customer's side and will then be able to make better decisions as an engineer. You'll also have a much easier time working with designers and PMs. And, of course, your projects will feel and look great.

IMHO, the biggest bang for the buck you could learn is:

  - Visual hierarchy (I.e. the same way you divide your code in modules and functions, you need to divide the visual space in a clear hierarchy).

  - Basic on typography (It makes a big difference even if most people don't notice it)

  - Understanding what's UX (I.e. reading "Don't make me think"). Just "caring" and "thinking" about UX will improve designs, even if you don't have much experience.

  - Basic of color theory; How different colors mean different things (Branding-wise or for alerts/errors/warning).

Reading material design from Google https://material.io is a great start. You may not like the UI of it, but the UX and explanations of why things are this way are really interesting.

What you want is cross-platform:

  - Web (IE, Safari, Firefox, Chrome, and older versions of those browsers)
  - Web responsive (When you access it from small screens or access the web from your phone's browser)
  - Android (old devices to recent ones)
  - iOS (old devices to recent ones)
  - And, eventually, get to a desktop app, ideally on windows, mac and linux.

Say you're the tech lead and you need to make a decision about the stack to support all these platforms, and you're a team of 2-3 devs, yourself included. What stack do you pick?

If you look at the graphql doc from the official website, this is what you get:

"GraphQL is a query language for your API, and a server-side runtime for executing queries by using a type system you define for your data. GraphQL isn't tied to any specific database or storage engine and is instead backed by your existing code and data."

And as far as I'm concerned, this is exactly what I think graphql is and should be. It doesn't say anything about caching or solving the N+1 problem or ACID/consistency.

You say "GraphQL does this, yes, but it's not particularly _smart_ about how caching works or how to avoid the Select N+1 problem.". But the whole point of graphql is to just be a typed query layer and use whatever strategy makes the most sense for your application. I feel like it's like saying "I'm surprised that JSON took off even if it's not smart enough to do X"... where actually JSON took off _because_ it doesn't try to do all of those features.

>> Airbnb's decision to abandon RN is clearly due to engineering blunders and political nonsense internal to Airbnb

I could be wrong here, but from what I understood the cost of maintaining a hybrid RN + fully-native apps > full-native apps. I.e. What airbnb would gain by not having to code both android/iOS was lost by having to deal with all the RN non-sense (third-party libraries being deprecated, very fast non-backward compatible changes, etc.) but also having to always bridge the gap between what was RN and what was truly-native. At the end of the day, you look at your time and you realize that you spend more time trying to make it work with RN to "save time" rather than just coding it on both platform.

But then, most people using RN don't have to deal with this issue because they don't have an existing non-RN code base to bridge with RN.

I like https://www.youtube.com/user/AGADMATOR. He goes over many interesting variations with clear explanations.

An easy refactor for your function is to use a "Builder" for your params, i.e.:

options = NodeBuilder .author({ min: 2 }) .flag({ .. }) .pagitation({ .. })

function a_nodes_list_trees(options) { ... }

Because in the end, if your function is fast and working correctly, it's fine even though it's a little bit messy. The problem is more all the code calling this function and having to pass dozens of params in the right order, and then it's a pain to start adding/changing parameters. Also, when calling this function, you probably need a bunch of temporary variables to "build" all the params; all those temporary variables could instead live inside that builder object.

Would be great to have this HN message in the About page (I.e. who's behind this site and why?)

Written notes, but it's mostly write-only or for very short-term things. I still keep all my notes and from time to time open them just to relive great memories.

Fans aren't angry about the diablo mobile game. They're angry because they were expecting a Diablo4 announcement and blizzard announced a diablo mobile game.. this is very different. IMHO the problem was in the way it was communicated, not with the game itself. It would have been very different if blizzard said:

  A) We've hired amazing people and we're working super hard on the next big Diablo title on PC, and here's one cool cinematic / picture to show it.
  B) A *separate* team of amazing devs has achieved the impossible and created a brand new diablo experience on mobile.

Instead, they announced to the A) fans they were working on B) instead of A).

What if: - kill the "hard ones" first - wait for the easier one to get very close to atmosphere, and then kill it. - will the algorithm learn to evolve toward easy ones?

I've been keeping a google doc pinned tab to keep track of everything (todo, what to read, etc.) so happy to give journal a shot. Email in my profile thanks

Makes sense to me.. PM are like mini-CEO of a product. Great ones make such a big difference and are a joy to work with.

I mean, learning X is an opportunity cost. Not dismissing your answer, but I guess we could rephrase the question: "Is Rails worth learning instead of X", where X can be some other popular frameworks. Or said differently, both for newcomers or more experienced devs, why do you think Rails is worth learning instead of some other web framework?

Hey, what did you guys use to build the feedback/roadmap part? (https://feedback.muze.charts.com) Is it a third-party service or something built in-house?

IMHO could show a UI demo written in a different language as a "side-app", as long as the core data model is in Alan; that would make it easier to see the power of Alan.

Not sure if that exists, but you may want to do a fake on-site with a coach; you're probably doing a few things wrong and the companies aren't telling you for HR reasons.

Listrunner | Montreal, Boston, San Francisco | fulltime front-end engineer | onsite

Secure collaboration software for doctors (https://listrunnerapp.com/)

We're looking to hire experienced front-end engineers. Our stack includes React, React-Native, Redux, Graphql, Rust, etc.

Please email jobs@listrunnerapp.com

Apocalypse: Documentary on 1st and 2nd world war. I thought it was great because it used original videos. There are 5 episodes for 1st world and I think 5 for 2nd world war.

Yeah.. new the UI feels like a new css had a bad merge with the previous one.

Depends what's your definition of the future. Personally, I have no doubt that it'll soon be connected inside our brain so "monitors" will be useless.. anything will be a "monitor" if that's what you want it to be. But it'll be much cooler than that.. I.e. if you're thinking about "What will be the weather tomorrow?", the whole sky could start "virtually raining" to show it to you with AR. It's scary and exciting at the same time.

Fixing healthcare in the US. Sounds grandiose and having been in the industry for 5 years I would have laughed a few years ago if someone told me that it was their company's mission.. but there's actually a real way to fix it and we're building that solution. Feel free to email me if interested. (Our stack is Rust / React)

One more optimistic way to look at it is using VR it'll make the "boring training videos" much more engaging. I.e. I can think of that annoying video on plane which I hate to listen to, but with a VR where I'd actually have to open that door and jump in it'd be a much more engaging experience.

I always find it cool to see the beginning of projects, but particularly lisp projects where the boostrap language is replaced with the new one: https://github.com/sctb/lumen/commits/master?before=aedf2fd2...

That's great. I like the:

(get '(:a 5 :b 10) 'a)

How does it work in practice.. is '(:a 5) stored as an array or an object?

Listrunner (YC S14) | Montreal, San Francisco, Boston | ONSITE | Senior Front-end Engineers

Hundreds of hospitals and thousands of clinicians use Listrunner to securely collaborate on the care of over a half a million patients.

We are looking for experienced backend and frontend engineers looking to write high quality code. Stack includes Rust, React and React-Native.

We are well-funded and opening new offices in Boston and Montreal.

Please reach out to jobs@listrunnerapp.com

Also, when you're being interviewed, how much should you interrupt the interviewee and nitpick on everything? I'd say Geoff made a mistake here and said "The founder" instead of "A co-founder" but was it worth interrupting the flow, etc?