pjacotg

I posted this link and found out about it on episide 121 of a podcast called Happy Path Programming, which Bruce Eckel hosts. I was aware that he had started and subsequently abandoned writing the book, so was excited to hear he had used Claude to clean up all of his old material for the book.

Signals and Threads, The Pragmatic Engineer, Maintainable, Book Overflow, Happy Path Programming

I'm busy reading a book [0] by Keith Devlin about the correspondence between Pascal and Fermat. It's called the unfinished game and has been really good so far. It goes through the letters and provides some context around them. [0] https://www.goodreads.com/en/book/show/4443547-the-unfinishe...

I second this. I joined a second hand Lego Whatsapp group a while ago and that's made it far more affordable.

My key takeaway from the book is the importance of conceptual integrity and how hard this is to achieve the bigger the team. I think this is just as true today as it ever has been before.

On the human readability concern, we use protobuf converted to text format. It looks JSON like so very readable and comes with all the other benefits of protobuf.

I was going to mention Peter Naurs paper as well. It's fundamentally changed the way I think about software. The projects I've seen that are in the most trouble are those where the current devs haven't had the opportunity to work closely with developers that understood the codebase well.

Have a look at a site called neetcode. They offer collections of leetcode problems that are representative of what you'd see in an interview. They have tutorial videos for each problem, which should help you get back up to speed with these sort of problems.

Completely agree. Beyond being of interest in its own right, "There exists" is a prerequisite for further work in finding a practical approach to find the path.

In regards to a career as a quant, the top firms may focus on "young geniuses" but there will be plenty of places where your profile would be just fine. It's a broad industry!

That sounds interesting. Do you have a link?

There's a book on financial calculus by Rennie and Baxter [0] that gave me very good intuition on the ideas behind option pricing. It starts with the binomial model and moves on to using stochastic calculus. If you get into the topic you'll want to read more in depth books, but this may be a good place to start.

[0] https://www.goodreads.com/book/show/307698.Financial_Calculu...

Not the op, but I started using parquet instead of CSV because the types of the columns are preserved. At one point I was caching data to CSV but when you load the CSV again the types of certain columns like datetimes had to be set again.

I guess you'll need to decide whether this is a big enough issue to warrant the new dependencies.

This book [0] has some really nice ideas in it. I have a 6 year old and 2 year old and I'm also on the look out for ways to develop a love of mathematics.

I've found mathematical inspired art projects to be quite effective. For example we'll cut tangram shapes out of card, make tangram animals, stick them on the wall and draw eyes on them and so on. You'll find lots of ideas if you search for math art projects for kids.

[0] https://www.goodreads.com/book/show/12689040-math-from-three...

I actually got some useful ideas on previous hackernews threads on fatherhood and parenting. There were usually one or two ideas that resonated with me. I suspect the points that resonate will be different for each of us. Here's one of the older threads with a lot of responses: https://news.ycombinator.com/item?id=31976803

In my last few projects I've made it possible to record inputs and outputs of applications and persist the data to disk. I've written tests that use the recorded inputs and compare the results to the recorded outputs. This meant we could record tests rather than writing them. We also record the results of testing sessions with end users and convert the results into tests.

There's a series of database moocs from Stanford that look good [0]. I'd start off by learning about the relational model as a foundation and after that exploring non relational DB's like TimescaleDB.

[0] https://online.stanford.edu/courses/soe-ydatabases0005-datab...

There's a book called Longitude by Dava Sobel which is about how the problem of determining longitude was solved. The Galiilean moons approach is discussed in the book.

I'm busy reading the book so this article caught my eye. It's been really good so far.

Nice! I've worked with a few similar real world payoff languages. This paper discusses one of them: https://www.infoq.com/presentations/haskell-barclays/

You could try the Stanford database moocs [0], they're on EdX as well. This will focus more on the relational model, SQL and database fundamentals. These are the fundamentals you need to understand so you can structure your tables and design a schema.

[0] https://online.stanford.edu/courses/soe-ydatabases0005-datab...

There's a 99% visible episode [1] on this very issue. Worth a listen!

[1] https://99percentinvisible.org/episode/sound-and-health-hosp...

If you want to display analytics on a dashboard I would generate materialized views from your underlying data first and then display that. Try and precalculate as much as possible to avoid having to do it on your front end.

There's a popular math book called Infinite Powers by Steven Strogatz which is about the story of calculus. It's really good and may help bring the subject to life as opposed to rote learning problems.

I used it for exactly this in my previous role. I automated a lot of tasks and built tools for my previous team. Most of them weren't Python programmers so I used gooey to create simple GUI's on top of my scripts. It worked really well.

I work in banking and I've noticed an uptick in Python where a decade ago it would have been VBA. Still plenty of VBA around but Python is in the mix as well.

Completely agree. I've always thought that Excel/VBA shows you where all the short comings are with your in house systems.

I recently listened to an interview with Leslie Lamport where he said you should write a description of your program in prose before writing any code. So not exactly programming on paper, but part of the process of thinking about what you're going to do can be captured on paper.

He has a saying I like, "If you think without writing you only think you're thinking"

I recently read this book review [0] where a mathematical proof was described as a dialogue between two semi-adversarial but collaborative actors, the Prover and the Skeptic, who together aim to aquire mathematical insight.

I thought it was an interesting perspective.

[0] https://jdh.hamkins.org/book-review-catarina-dutilh-novaes-t...

Good point on the benefits of reading bad code. One of the best developers I've worked with said he'd become a good developer by refactoring a lot of bad code.

I'd add to that and say shorting is typically selling a share that you don't own. Which means you need to borrow it from a broker for a fee. There's a securities lending market which revolves around borrowing and lending shares for these reasons.