Ask HN: What are you working on (August 2024)?

Ideas:

- A "vibe shift" has occurred at work. Separately, my own thoughts have been more unkind/uncharitable towards others. Recently I realized that the two are connected. Isn't it funny how the vibe-shift trickled down to affect my own mindset without me even noticing?

- I think that Google is going to fall apart soon. Before they do, they'll cut money-losing boondoggles like, oh, Google Maps, Google Books, Google Groups... Who will step in to save all that data? And what does a post-Google world look like in general, anyways?

- AI is incapable of the kind of impact that is being promised. But we are still going to have a period of ~2 years until corporations realize it (it sounds like AI companies will run out of cash at that point). Until then, we're going to have a lot of layoffs because Mike-the-MBA thinks AI can do people's jobs. What should normal people do? Sit tight and sit out the game for 2 years until things stabilize?

- All of the above is part of a crisis of meaning that people - and esp. tech workers - are having. There's an enormous opportunity for Government jobs to become prestigious again. It used to be a mark of pride to work for the Government. You don't need to burn out and become a woodworker to "do real things": your local city government has plenty of "real things" for you to do in a real community.

I don’t have a personal calendar and my work calendar ends at 5. I think your market is a lot smaller than you think. The kind of people who ask friends to book time on their calendar are considered freaks anywhere outside of tech hubs

I've been working on https://65words.com by myself for 6 months.

65 Words is an anonymous challenge to write 65+ words daily in the language you're learning.

The real focus isn't just on improving your writing but on having the opportunity to think about how you'd express something without the pressure of the moment.

There's no hidden science behind choosing 65 words. I found it’s achievable even on a very busy day.

The goal is to help learners practice daily and build confidence through consistent effort.

When you say "by hand" do you mean with a pen and paper rather than typing it out? If so, can you say something more about why?

I’m writing a series on how to understand golang if you’re an experienced TypeScript developer.

I’ve worked with several teams now who wanted to adopt Go for the backend, but the team’s only extensive type system experience is in TypeScript. They tended to hit very similar pitfalls and want to coerce the type system to behave like what they’re familiar with, and inevitably they wound up with inflexible and error-prone architecture.

They also failed to accomplish any kind of holistic, 30,000ft view architecture because implementations were too often sent off the rails by not understanding the language deeply enough. That was often in part due to type system confusion inherent to how Go implements certain data structures (particularly slices), which leads to the sprawling repetitive Go code people dislike so much.

I did all of this too, so I feel like my insight and experience would be valuable to share. I actually wrote 90% of it last year and felt like a goof, like, ahhh what am I doing obviously everyone else figured out Go faster than I did and this writing is just telling people how incompetent I am. Haha. But then I worked on another project and the situation was exactly the same. I actually used my draft content to help the team understand how I see the problem, and how to get past the mental traps that they were in.

Fundamentally it comes down to “learn the type system/language properly”, but it’s not quite so blatant or unhelpful. One of the problems with TypeScript methodologies is that they’re so ridiculously flexible, but go is not at all in the same ways, yet they have just enough superficially in common to trick you into thinking otherwise.

So, my series essentially elucidates the similarities, differences, and what’s totally absent in Go from the bottom to the top. It’s interesting because they really are remarkably similar in some ways, which is precisely why it can trip newcomers up. Knowing why that’s a trap makes you a far, far better Go developer. Along the way it also reveals details about TypeScript that some people might not be fully aware of (at least several in the team I shared the drafts with said so), which could be helpful.

I mostly need to muster the courage to hit publish now. My confidence has taken a beating in the last year or so!