dava96

I've been toying with the idea of learning zig and weirdly enough I was looking at this guys book. I don't have any experience with low level languages. The closest I've gotten is Go.

I was debating between C and Zig, but I still don't really know what I want to choose. Feels like C is probably the right choice given the languages age and it could technically be more useful (not that I'd be looking for a job doing C work).

For those that know both, what would you pick?

Out of interest, what have you been doing with them?

This is really cool man. I like this on going trend of resurrecting old tech with AI and this is yet another avenue to explore.

I'd be interested in seeing some older flag ship mobile devices

Yeah it is really, never thought about it like that!

Even a slopped up ADR would probably be more useful than direct access to chats.

I agree that we should be using these tools to work out more optimal solutions.

We need to go slow before we can go fast.

On one hand, I like the idea of being 100% responsible for reviewing my own code because it allows me to get changes in quicker.

The way we've been working is that we own a feature end-to-end rather than just a slice of it. So I understand my work, and other people understand theirs. In that context, not having code reviews makes some sense.

But part of me already misses what code reviews used to bring: learning opportunities. I can no longer rely on someone more senior than me to give me feedback, challenge my decisions, or help develop a shared understanding of the codebase.

«I can say to Claude "hey, bring me up to speed on this thing they've been building - how does it work, where is it at, and what still needs to be done?"»

I think there's an opportunity to solve this differently. If you could see your teammates' conversations with their agents, you could actually follow the decisions they made and understand why. Although I appreciate that's a bit "big brother".

«What I'm recommending instead is to still build a very strong foundation in engineering fundamentals, because that's where I think we as humans offer the most value right now.»

Whilst I partly agree with this, how do you actually do it in practice?

How can you possibly know what good looks like without writing good code yourself and experiencing the consequences of bad code?

I've been thinking of this as a privileged point of view, particularly from engineers who've spent more of their careers working pre-AI than post-AI.

You've had the benefit of years of experience developing the judgment needed to distinguish good engineering from bad engineering. You can now use AI effectively precisely because you've built that foundation.

But how are newer engineers supposed to develop that same judgment, especially if their workplace operates like yours?

But it's valuable to experiment with these instincts.

I wonder if the issues I was having trying to download my ebooks from them is related to "vibe coding".

It was pretty frustrating not being able to download the things I'd paid for.

Learn the notes on the E string, then the concept of an octave and how to find them.

If you play the open E string, the octave for this is on the D string 2nd fret.

The easiest way I found was to think of the notes on each of the strings are a repeated pattern starting in different positions.

Start with the whole notes (no sharps or flats)

EFGABCD ABCDEFG

Once you've got them down you can learn the sharps/flats