bzalasky

One thing that might not be apparent to non-chess players is that an experienced human (particularly a GM or Super-GM) with an engine can often beat the same engine or another engine that lacks human assistance. There are some positions, particularly in closed games where this can become more of a factor. It'll be interesting to see if a similar logic plays out in other fields. I imagine that some companies may be quick to automate away roles to save money, however, if you follow what we've learned about chess, there's likely an opportunity to make a bet (start a company) on AI-assistance outperforming full AI automation in some domains.

I get that it might treat people differently. This is what works for me, otherwise I wouldn’t be able to take it at all.

Make sure to eat food before you take it, and start with 2.5g twice a day instead of 5g all at once to go easy on your stomach. The food helps slow down how quickly the creatine moves through your system. This prevents too much water from being pulled into your GI tract, avoiding undesirable symptoms (use your imagination).

Had the exact same thought after reading the abstract… FWIW, delve only appears in the abstract. Having not read the rest of the paper yet, I might give the authors the benefit of the doubt that they used an LLM to summarize their findings for the abstract, but didn't abuse an LLM in writing the entire paper.

Forgot to add the link for the Strange Loop archives… https://www.thestrangeloop.com/2021/sessions.html

You could explore the archived content from the Strange Loop conference (or another conference of your choice). Topics run the gamut of what's interesting and trending in "languages, libraries, tools, and techniques." Another approach that might help you find jumping off points for topics would be to review how we got here with a book like Ideas that Created the Future: https://mitpress.mit.edu/books/ideas-created-future. If you're primarily interested in opinionated lists of new libraries and stacks, Thoughtworks' Technology Radar https://www.thoughtworks.com/radar is a nice compilation that's updated on a somewhat regular basis.

The Flawless Typography Checklist (https://www.typewolf.com/checklist) from Typewolf is a great resource that has served me well on multiple projects. It covers the following:

- Punctuation & Type

- Body Text

- Legibility & Readability

- Layout & Hierarchy

- Typeface Selection & Pairing

- Design & Branding

The Typewolf site itself is pretty cool as well, but skews towards print/graphic/marketing site design that isn't always applicable to applications, though there are some exceptions.

Are you familiar with Zapier (https://zapier.com/) or IFTT (https://ifttt.com/)? These are the two solutions that came to mind for me after reading your question, though there may be a few other options out there in this space.

Take a look at the Boxes and Composition articles on Every Layout:

- https://every-layout.dev/rudiments/boxes/

- https://every-layout.dev/rudiments/composition/

These articles do a good job of presenting one perspective on a big picture of web layout. The paid content is worth the price if you agree with the overall approach they outline in the Rudiments section.

The primary reason I'd reach for the Jamstack over WordPress is security. A static website (relying on a headless CMS or a build/deploy process for content) is much more shelf stable than WordPress if the project isn't updated on a monthly basis. A lot of people have built successful businesses and sites with WordPress and continue to do so (this is what I got my start in consulting ten years ago). That said, WordPress provides a bigger surface area for vulnerabilities with the 3rd party plugin ecosystem and database connection compared to static sites. If you're familiar with it, and prepared to keep it up to date, it may be a good option for you. Otherwise, I'd go with the Jamstack (assuming it can handle whatever your use case is).

Yeah, definitely looking forward to some DLC content. Did you try it on Supernova difficulty? I beat it pretty easily on the Hard setting, but had to completely change my playing style to get anywhere on Supernova. Went from going in guns blazing to a stealth run.

For me, The Outer Worlds was right there with Witcher 3 as one of the best games this generation. It really does feel like Fallout, but perhaps somewhat less open world when you're actually on a planet b/c of map boundaries and enemies too dangerous for your level to keep you on track. The diverging story lines and open space travel (once you get the requisite navkey to be able to land) compensate for that somewhat.

There’s room for improvement. I’d start with the typography. While it’s not cheap, Typewolf’s Flawless Typography Checklist is an incredible tool for sprucing up designs (https://www.typewolf.com/checklist). Once you’ve refreshed the typography, take a look at these design tips from Steve Schoger (https://twitter.com/i/events/994601867987619840). His book, Refactoring UI is also a solid reference.

I wouldn't pick Stylus for a new project, but you can use it with a linter like Stylint (https://github.com/SimenB/stylint) to enforce stricter conventions. Totally agree with you on the importance of consistency for maintainability (where it can be applied automatically with tools).

In the JavaScript UI library React, useEffect is a hook (recent addition to the library) that allows you to perform side effects in function components. https://reactjs.org/docs/hooks-effect.html

Hopefully, users have been considered in the product requirements, but yes, I wholeheartedly agree.

The answer to whether a single-page app is appropriate for a given project needs to consider product requirements, team structure and available resources.

Libraries like React are awesome for breaking down complex (or even not so complex) UIs into story sized chunks that can be tackled by different engineers or even different teams. This is one of the biggest reasons to consider using them, IMO.

Even in the case of relatively unremarkable CRUD application, if the backend is split across multiple services and teams it may be entirely reasonable to choose to build a SPA frontend with a dedicated team.

On the other hand, if you're building a Rails app with a small team, and most engineers are working full-stack out of necessity, a SPA may not be appropriate.

As companies grow, I've found roles tend to become more specialized. Your decision to build a Rails web app early on could be considered legacy cruft (by some) down the road because it can be difficult to break down and deliver a feature across the full stack if you're not accustomed to building web apps that way.

There are tradeoffs to all of these approaches (including the hybrid approach). Ultimately, you need to do what's what right for your product and team(s), and make your technology choices intentional.

I haven't actually tried it yet, but https://www.notion.so/ caught my eye recently. As far as Confluence goes, I also have problems with search, and missing notifications for comment threads.

This is essentially the process that Things 3 (I’m not affiliated in any way) for MacOS/iOS uses. It separates adding new tasks (for your inbox) from the step of organizing and scheduling them. So if you think of something you need to do, you can use a keyboard shortcut to pull up a prompt quick add it (from whatever app you’re using) and carry on with whatever else you’re working on.

Here's the gist of it as I read it... the current list is a topic you want to learn, and as you're working on it, everything that you don't understand is added to the current list. As you check off the subtopics (and their subtopics), you'll have the requisite knowledge to understand the topic you wanted to learn in the first place. The pending list is stuff that will become the first item at the top of your next current list.

Engineers shouldn't be reporting to product managers. I'm not sure what's going on in your team, but it sounds like there may be some wider organizational dysfunction.

Forget notecards, what you need is a well configured linter. There's no reason to save style issues for code review when they can be caught with static analysis. Having encountered this team issue previously, linting made it a non-issue. Pre-commit hooks and CI are two options for enforcing code style.

Small correction on the chart, React has actually been open sourced for ~5 years, React Native is ~3 years old.

As far as how fast frontend technologies are changing, in my ~10 year career, I've only had to use jQuery (~2008-present), Backbone (~2012-present) and React (2015-present) professionally. These libraries weren't swapped out on a whim, and I still use all 3 in different projects on a weekly basis. While I've dabbled with most of the others, I haven't selected them or encountered them professionally.

To some extent, I think library churn can be attributed to keeping things interesting when the problems you're solving are less interesting.

Most frontend engineers could probably benefit from rolling their own SPA library (not for production use, but to learn how the different pieces come together). There's probably room for a few more "From Scratch" tutorials in this space akin to Destroy All Software's series of screencasts. Working through something like this would make it clear that the differences between the libraries above are smaller than it might otherwise seem.

Are you familiar with Spacemacs? As a Vim user, you can be productive on day one because it lets you emulate Vim (via Evil). Spacemacs also comes with batteries included and makes it easy to move past editor configuration to whatever you're trying to get done. If you want more customization, Spacemacs is still Emacs, and can be extended as you wish.

http://spacemacs.org/

This compilation breaks it down by year – but misses most of 2017. https://medium.com/startup-grind/most-recommended-medium-sto...

Honestly, you need both. Here's a comment on code review I wrote year ago or so that seems relevant:

Code reviews shouldn't dwell on style issues that can be handled by linting. To the extent that you can automate some of the review process, and prevent sloppy commits from being merged in by having them fail CI, you'll eliminate part of the problem. Another thing that helps is reducing the semantic distance between what a commit message says a commit does, and what it actually does. This is pretty easy to enforce relative to more subjective aspects of coding. The last thing that can make a big difference is not getting hung up on wanting to rewrite a commit as you would have written it, but focusing on improving understanding and clarity for whoever will inherit the code next. If there are serious issues with the architecture and patterns the code is using, CR can be too late in the process to address them effectively (depends on the scale involved). I'd try to collaborate with other engineers earlier in the process to help set them on the right path [1].

As for unit tests, make sure to isolate the unit (generally a class or function), and test its interface. Tests that are coupled to the implementation aren't as useful. Investing in writing unit tests now will increase your velocity in the long run. You'll be able to take on more technical debt in the short term with better terms, so to speak, since you'll have a robust test suite to refactor against. Obviously, this doesn't mean you should write bad code, but this will give you the option of considering performance and reusability tradeoffs if you need to hustle a feature out the door.

[1]: https://news.ycombinator.com/item?id=11257835

Perhaps creating niche visual DSLs is a more viable approach to developing visual programming environments than to focus on creating a general purpose programming environment.

It'd be interesting to see if there are any existing solutions in other domains.

While I can appreciate your perspective, there are plenty of hard problems on the frontend. Many of them might fall outside the confines of the label frontend (into graphics programming or linear algebra), just like Google scale falls well outside what I'd call backend if we're sticking to a simple dichotomy.

Here are a few harder problems that I can think of:

- Draw a non-linear gradient along an arc with SVG

- Implement a constraint solver in JS

- Convert a CgBI image into a standard PNG with the browser File API

A good portion of the work I do on the frontend is transforming and composing data, and wrangling that data together from a multitude of different services. This honestly isn't that different from the work that I've done on the backend of the stack.

I'm not trying to discount how hard problems can be when they're distributed, just trying to point out that you can do interesting things in both domains.

To someone who isn't a "coder" it may be difficult to tell the difference between someone cranking out landing pages with HTML and CSS, and someone building the checkout flow for a different part of the same app. If you were uninitiated and saw both colleagues working with text editors (with fancy syntax highlighting) and the command line, you'd probably call them both coders. Superficially, the work looks similar. The semantic change you've noticed could possibly be attributed to the tremendous increase in web development in the last decade.

The $40M is for Pebble's assets and intellectual property. They're hiring the engineers on the side. Sometimes acquisitions are done this way so the acquiring company can avoid the outstanding liabilities/debts of the company being acquired.