3oH2y869

I've personally had this experience with Fly on a personal project. My project went down but their status pages said everything was up. It's fine since it's personal for fun project but for anything more serious I don't know if I'd be comfortable using them.

Thank you so much for your helpful responses. At 100dpi how does the monitor look compared to the Macbook retina screen? Does it look fuzzy?

Is there any fundamental guidelines one can follow as far as PPI goes so that the monitor doesn't look miserable? I am looking for something reasonably large and quality that doesn't break the bank.

Unfortunately that is way outside of my budget. At 1.5k, what monitors would you recommend? I would like a larger one.

What do you mean by normal vs medium DPI? Which ultrawide are you using?

Would you recommend this over an ultrawide? Is ultrawide DPI lacking?

I've got the Corne-ish Zen, and I also recently acquired the Kinesis Advantage360. Both very niche, ergonomic boards but I'm very happy with it.

I'm a VP of Engineering and have been a TL at major React shops.

I don't agree with this statement: "The best benefit to all of this, in my opinion, is that it allows more junior-level people build interfaces that they wouldn’t otherwise be able to build at all. I say, React has commoditized the web app development."

In my experience, React is pretty complicated for junior engineers who don't grok how the actual runtime works. On the other hand, what React has really enabled is for large frontend teams to exist and work together meaningfully. I remember the days of vanilla JS and large codebases. I can imagine that today those codebases would be easier to maintain and work on due to things we've learned and developed (thanks to React, by the way), but I still strongly believe that the productivity gains from React for a team greater than like, 2 front end people on a project that needs to be maintained for longer than 6 months is worth the effort.

Book recommendations:

* Good Inside by Dr. Becky Kennedy

* How to Talk So Kids Will Listen & Listen So Kids Will Talk (The How To Talk Series) by Adele Faber and Elaine Mazlish

Good luck!

I don't know about Flutter, but my issue with these takehomes in a React world is that React is extremely basic. It is only a view renderer, and leaves up to you all difficult questions of: routing, CSS, components, data fetching, state management, even things like how files are organized and named are up to you. As a React candidate, your takehome probably touches on all of these topics, and you (rightfully) probably want to express some kind of proficiency in most/all of these areas. The more senior you are, the more likely you have opinionated ways of doing these things. But in an hour long span, you are left with two uncomfortable options:

1. Write it all yourself. Express those opinions as clearly and bug free as you can. Try to get it all in as much as you can and give up on finishing all the features in the spec. Definitely give up on the UI looking nice -- despite what anyone says, default HTML is not pretty.

2. Use OSS libraries. Are you actively up to date on OSS libraries handling these things? If you're a working React professional, you probably are not, because you're using whatever system your company uses. Do those OSS libraries properly express what you think is good code? And what does it say about you to use those OSS libraries? Do you look like someone who actually understands React and understands those tradeoffs, or do you look like the kind of person that creates the type of React app that HN is always complaining about, one with a billion dependencies?

Sorry if I sound ranty. It's not directed at you. I've just been dealing with a lot of these this week.

I'm in FE, and FE interviews can be like this so much. "Here's a takehome for something that in reality would take a week to complete but do it in an hour and don't spend more time on that!"

And I'm like.. an hour is not long enough to implement any reasonable webapp... I have no idea if other people went over or not, and it almost feels like a test of commitment (if I was serious I would take the actual 4 hours it would take and pretend I did it in 1 or something like that).

Yeah, this happened to me this week. Honestly, I wouldn't worry about it. It sucks that they don't want to see more but it could be any number of things that they isn't working out for them. This experience you have doing the takehome, it's definitely going to help you out in the future in your next interview. Just think of each interview as another opportunity to learn and grow your interviewing skills :)

But really, I think that interviewers should be gracious about takehomes. And if they're not, that gives you and indication of what kind of place it is to be.

I've seen both. In my experience it's been rarer to see a process with no coding involved, but it happens here and there.

+1 for Meow. Vim doesn't make sense to me, but Meow does.

I prefer iPad over a laptop for a number of reasons:

- My main machine is a Mac desktop. I am not looking to add another powerful machine to the mix that I'm not going to use regularly. The iPad (or even another high quality laptop) would be just used as another beautiful screen, to work or watch Netflix on.

- I have a high quality, ergonomic Bluetooth keyboard that I pair with my both my Mac and my iPad. This means my ergonomics with my iPad is better than using a laptop with it's attached keyboard.

- I'm not looking to do long work sessions on these devices, although I honestly could. It's more for one off things, for updating my org-notes, for having a quick cafe work session, etc.