greenyouse

That approach sounds similar to the Idris programming language with Type Driven Development. It starts by planning out the program structure with types and function signatures. Then the function implementation (aka holes) can be filled in after the function signatures and types are set.

I feel like this is a great approach for LLM assisted programming because things like types, function signatures, pre/post conditions, etc. give more clarity and guidance to the LLM. The more constraints that the LLM has to operate under, the less likely it is to get off track and be inconsistent.

I've taken a shot at doing some little projects for fun with this style of programming in TypeScript and it works pretty well. The programs are written in layers with the domain design, types, schema, and function contracts being figured out first (optionally with some LLM help). Then the function implementations can be figured out towards the end.

It might be fun to try Effect-TS for ADTs + contracts + compile time type validation. It seems like that locks down a lot of the details so it might be good for LLMs. It's fun to play around with different techniques and see what works!

It feel silly to say that AI is curing cancer. Normally a phrase like that would sinal the apex of the hype cycle but I guess it actually has some meat in this situation. Using AI more like statistical inference to screen for medical conditions or predict treatment could be helpful. I remember Jeremy Howard from fast.ai did that with deep learning to detect things in medical images. Seems like a good thing for CERN to do as long as it works.

Here's a fun project that you could try. Use TTS to transcribe books but make the transcriptions feel more realistic. Give each character in the book a unique voice. Leading characters should have voices based on their personalities. Use quote extraction and character attributtion to tie characters to lines. Try to do convey the human qualities with EmotionML, SSML, or some kind of semantic analysis.

The best would be a TTS system at the level of OpenAI's but with voice selection like GCP TTS so you can get quality and a range of voices.

Copyright would probably spike any monetization effort but you could try. It would be nice to have an open source tool for this though! :)

That would depend on the culture of your team and larger workplace. Healthy teams should be checking in frequently to talk about ideas, reviewing big things, scoping upcoming work, etc. If there's time reserved for deeply technical but loosely structured discussion like that, then everybody takes turns being that person. In that env someone could "specialize" in it and help inspire others to do great work.

It's the team that creates that kind of opportunity for feedback though. If the team has dysfunctions like rejecting deeper discussion or not working beyond jira tickets or checking out at meetings, etc. then it's not going to work. Someone that's good at that kind of supporting discussion will feel push back when fostering those discussions so it will fall off over time.

The teams that do the best work and are the most fun to be on can host those types of discussions though, even remotely. It's worth experiencing if you haven't!

Polymer powered a few other things at Google too. Look at the DOM for YouTube, that dev team started with Polymer for Web Components and talked about how they built an internal library of custom HTML for the site. Doing that shared library approach seemed like a good way to scale out development across teams. It seems like it's still alive and well over there. (also used at ING, Comcast, Vercel, and others)

I still have hope that frontend will eventually turn back to web components now that HTML templates, Custom Elements, Shadow DOM, and ES Modules are fully adopted. One of the problems is that this stack is foreign even to professional web devs that hail from React land. It's weird because it's native browser tech adopted by the W3C and painstakingly built into the browsers. Maybe it picks up after someone rewrites the react-dom internals to support web components and adds a new tooling layer over it?

It's not bad tech and web components are built into the platform of the web now so they're not really going anywhere...

Wallaby.js is a no-brainer tool for writing frontend unit tests. I see a lot of people at work struggle with unit testing. For the productivity boost it gives, it's easily worth the cost.

Shows some helpful ways to reason about open problems with incomplete information.

Pair with ChatGPT 4 to set up the project design.

I try to give as much context as possible. Stating goals and risks of the project. The more info you give it, the better it does at helping you. Around 500 words for an initial prompt gets good results.

Break down the project into parts and take on the most risky/uncertain part first.

As you work through the design, continue to refine the ChatGPT conversation by giving it more info. Keeping around 200 words is good. New articles can be summarized to get it up to speed on post 2021 info. Blog posts can also be chunked out and passed through to give it more info about the problem.

When the plan seems good enough, code through the steps to create the solution. Keeping things realistic and making some slow but steady progress is better than hammering it all out in a day. Discipline over passion.

I used it for a recent project and it completely exceeded my expectations. Not trying to hook onto the current AI bandwagon, it just brought me to solutions I would have never gotten to on my own.

Hey would she want a laptop for free? I have a 2007 macbook with lubuntu that works great. I used to use it for trips and it's a total workhorse.

The computer architecture is funky so it makes installing some distros a pain in the butt.

It was something like a 64-bit EFI bootloader for a 32-bit OS. The combo just doesn't work without compiling your own kernel. It's pretty uncommon. No biggie for someone that does C++ or embedded systems though.

Anyway, I'll shoot you an email with some pics and you can let me know what you think.

Part of it probably comes down to company culture. Working at a place full of people that are engaged and fixing/reporting/debating things is healthy. It's a good environment for people to learn and grow so you can move ahead in your career long-term. Being stuck somewhere where everyone is coasting is demoralizing. You'll most likely plateau in skill since you won't take on hard problems and need to constantly learn new things. You can learn stuff outside of work but it's also nice to have a life and not feel like you're working the mines.

Work is supposed to be fun too. Some people get a rush from working on hard problems. There's at least some joy when you debug a heisenbug for a day or two and finally solve it or take on an impossible project and succeed. Having a team that you gel with where everyone is high flow state makes you look forward to doing work things too.

When you look at it economically as a 8 hours in $$$ out, you're looking at the short-term and discounting your long-term personal growth. If you aren't growing in your job, leave and find a place where you can build your skills and work on things that you find enjoyable.

There are probably some software jobs that would be fun to do. Why not go for a fun job doing something you love if you're currently stuck?