matthewwolfe

I use a mono repo setup with “web”, “native” and “shared” using react and react-native. All of my logic and fetching code is hook based, and that can be 100% shared. I have to make a web interface and a native interface, but they are so different it’s nice to split on the UI. I wouldn’t want to have a desktop UI that I also show in an app, it just wouldn’t look good. All in all I probably share ~70% of the code. It’s all in typescript and really nice dev experience.

Maybe I’ve not been in the react native ecosystem long enough but it seems relatively painless. Granted I’m mostly displaying data, some icons, and buttons so YMMV

It’s hard to compare v scale to aus scale and I’m definitely not very familiar, but googling says that v10 is roughly equal to 31 on the aus scale. Of course bouldering is also typically 5m tall or less, and it’s very hard to compare boulders to routes. I think the equivalent font grade is 7c+

It sounds like if your goal is V5-6, you better be bumping up that 5.11 sport climb goal! Certainly at that bouldering level 5.12 is in your future in no time.

In terms of training plan, I’m generally very loose. I’m definitely blessed to be very lightweight naturally, and I think I’ve developed some pretty strong fingers over time. That combination lends itself to crimps which is definitely my preferred style.

Board climbing like on a moonboard or kilter board are fantastic to build power, but be careful how frequently and how intensely you climb on those. My fingers tend to feel quite tweaky after a lot of board sessions.

Ultimately climbing is a game of time and consistency. Listen to your body and keep grinding at it, and you’ll definitely see progress!

Good luck to you as well!

Climb a V10 boulder outdoors!

A nice pair of hiking shoes. I’ve got la sportiva Bushidos but any decent hiking/trail running shoes will do. It’s nice to not be slipping and sliding on loose gravel and leaves anymore, as I did often when wearing more casual sneakers.

I’m also a la sportiva enthusiast. I’ve found the women’s shoes to fit even better than the men’s. I’m on my third pair of women’s solutions and they are so good. I think the women’s shoes are made for a lighter person (I weigh about 135) and they are very sensitive and easy to feel footholds with.

I think it is somewhat platform dependent. I don’t know anyone that uses Facebook except for the weird kids I went to high school with or senior citizens. People my age (20s-30s) will occasionally post major life event photos, ie wedding, baby, etc.

Instagram still seems wildly popular especially among women. My wife is definitely addicted.

YouTube will probably have the most longevity because of the breadth of topics on the platform. I can use youtube for anything tutorial/learning related, hobby related content, and also occasionally dive down a random rabbit hole.

If you actually do know html, css, and HTML properly, then looking at the bootstrap documentation is going to be your best bet. It is full of examples with code snippets and examples of what that code produces. Bootstrap is a very class based library, there isn’t a lot of complexity to it other than structuring your HTML correctly with the correct class names.

Unless you are integrating typescript into an existing codebase, having the strictest feature set is great. I’ve never felt the need to use any/unknown, except for very occasionally when working with a library that has spotty typescript support.

Absolutely worth the hype, doubly so if your backend is also written in typescript and you can share types. I would say except for very specific cases, you don’t need the complicated parts of typescript, and what you are left with is a lot of defining interfaces/records of what object are. This takes minimal effort to write but pays dividends when you can hover a variable and see the exact type, or the compiler complains about some unintentionally null or undefined value you didn’t consider.

The easiest way to keep a habit is by doing something you enjoy. Of course this can be hard in the case of eating healthy, if you would rather just eat shittier but more delicious food. But for exercise, finding an activity that you enjoy makes it so much easier to stick to it. I used to play rec soccer and enjoyed it so much, and ran multiple miles per game without even thinking about it because I was so immersed in the play.

Now I do a lot of rock climbing which is a full body exercise and some hiking to get to locations, with the added benefit of being outside in beautiful nature.

In short, find things you love doing that align with your health goals.

I think there probably are people that get nervous and absolutely blank, that is bound to happen. As an interviewer, what can you really do in those situations? Also to note that looking up documentation is perfectly fine, and I explain that as well. As for others, I think some people graduate out of writing code when they become senior, or something similar. But we make it very clear that senior/lead engineers are primarily writing code, so I don’t think it is a mismatch of expectations. Other people are genuinely overstating their skills and are no programmers. The incentive to lie is there, based on how much money a programmer can make.

Agreed, you can be absolutely horrible at math and be a fantastic programmer. I always found math easy in school but 5+ years later if someone asked me to write a quadratic function solving function I’d have no idea what that even means. Presumably with a guide I could write the code, but that’s so far removed from the type of work I do day to day

I rotate through various simple function implementations. It’s important to stick to fundamentals and not introduce anything where a specific context is required. Examples of this are

- function to reverse a string - function to sum an array of integers - function to get a deeply nested property value from an object

Since I work a lot with React and also interview people for that, I use the following to determine if people are at least somewhat familiar with react:

- take a static array of objects (first name, last name) and render a list of those objects

If people can’t write the map function, or are confused about the console warning for needing “key” that is usually a great indicator that they don’t actually know react.

What consistently surprises me is that I’ll interview people with 5-10 years of directly related experience, who will see questions like this and laugh or say it’s trivial, and then absolutely bomb. One person complained that they were senior and above these types of questions, and then spent 20 minutes trying to reverse a string.

Step 1. Make a temp email Step 2. Get book download Step 3. Move on with your life instead of complaining

You laugh at that coding assignment for a senior position but you'd be surprised how many "senior" people interview that would struggle with that and be unable to complete it.

Since you are already a seasoned developer you can cut through a lot of the blog posts and courses that are aimed at junior developers. The two main resources I find myself reaching for are the Mozilla JS docs, and the React docs. React team is currently working on a new version of the docs, googling “React docs beta” should get you what you want.

As for things to learn, async/await and promises are probably the most complicated, but Mozilla will no doubt have documentation covering all of that.

For React, prefer small contained functional components, avoid classes and inheritance, and learn what hooks are and how they work.

For Typescript, avoid using any or unknown everywhere, avoid the urge to make very complex types, and generally stick to interfaces with minimal inheritance and you’ll be fine.

As you are jumping to an existing codebase follow the conventions of that codebase. Avoid the classic blunder of jumping into a new codebase and making massive changes.

Good luck!

There is not a rule that is preventing you from writing websites with JS, HTML, and CSS or even just HTML and CSS with no JS at all. Like everything else in the world, right or wrong, people have preferences for different things. Some people prefer your approach. Some feel more productive with Vue/React/Angular/etc. Some people even like writing web apps with Rust.

I personally like using React and Typescript because I feel really productive with it. I’ve built out open source libraries that I use in my own projects to prevent massive bundle sizes. That works for me. Do what works best for you :)

I’ve tried out storybook 7 recently and it does seem a bit better, but I do agree with you that storybook is less than ideal. I see storybook in the same way I see a complex webpack config, I have no idea how it works and once it is finally set up I don’t touch it. I would love to see something as easy as Jest to install with a simple interface for writing and testing react code.

I think storybook tries to do too much, and I’d like to see a really dead simple interface with Vite or similar where I can easily prototype and test stuff based on *.stories.tsx or similar.

I don’t need all the stupid addons, just give me a dev server with navigation and routing built in, and an easy way to hide the whole interface to simulate a normal web page.

Not really answering your question, but after one of the boosters I had ~1 month of abnormal heartbeat and was hospitalized. My chest also felt uneasy, somewhat painful, and I could feel my heart double beating irregularly. Best answer I got was that the vaccine caused inflammation in my heart which caused that issue. Luckily it has since cleared up but I occasionally feel weird feeling in my chest. Could also be stress/anxiety

I don’t see it as SPAs fading, but just the natural progression of this style of making apps/websites. People moved from a heavy server to a heavy client, and in the process realized that shipping your entire website in one bundle at first load is not very performant. Now the tooling has caught up to the point where SPAs can be split on natural boundaries so that the individual page loads are smaller.

I don’t see this as a fundamental change. Writing the actual code still feels the same more or less. It’s more the tooling that has changed what the output looks like.

Copilot is trained on public repos. Id imagine if Microsoft doesn’t want you to use their code, that code would be in a private repo. There’s nothing stopping me from using code in a public repo, regardless of the license.

The best thing you can do is write OSS and not care who uses it or for what purpose. The more people writing truly free and open software the better. In my mind that is the ultimate end goal of OSS.

I think the comparison being made is why restrict yourself to a rail line when you can buy a huge bus with a driver and private chef and have them drive you anywhere you want.

I will never understand why people push code to public repos and then complain when someone or something uses that code. Code that you want to keep private or make money off of should be private. Only publish stuff to the public that you want other people to see and learn from. All the complaints about attribution… who cares.

I use React at work for all our projects. We have yet to run into a situation where react has failed us. I’m sure many people can say the same about the other options. That is a clear indication that it doesn’t really matter which you pick. It should be based on team familiarity and then just comes down to personal preference.

Personally I think React/Vue/angular are the safe bets, in that order due to popularity

Awhile ago (year+) I was trying to set up a project for free that hand a frontend/backend and database. I landed on Vercel with NextJS and MongoDB’s Atlas, for no other reason than I am familiar with Next and like writing typescript/react, and wanted to not spend any money. It’s been easy to push to master and deploy, and never seems to have any issues. All in all I can see Vercel being great for small/one person teams. Id definitely pay the $12 to not do any dev ops if I was running a business on it.

I’ve found that pull request size solves a lot of the issues that people have with code reviews and quality. When people see a very large pull request, there is a tendency to skim and then slap on an Approval. Keeping pull requests small typically leads to a more thorough review because it’s much easier to parse the changes and build a mental model. This usually leads to better feedback. This also helps prevent less experienced devs from going crazy down the rabbit hole and making a huge code change. Small and steady is best, and fostering a culture where people are often asking each other questions and collaborating is key.

My favorite approach is Zustand, which is a simplistic object with data and functions to update that data, combined with react-query for doing a lot of the data fetching. Zustand is super simple and based around hooks, and I find that with a data fetching library that handles caching, I have a lot less “global” state than in the past. IMO for even relatively complex apps, having a ton of global state is not great, and breaking things down into specific contexts that are each separate hooks is great. I think Redux’s Toolkit or whatever it’s called works similarly.

Wow a lot of those Todo MVC codebases are very out of date