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.
There is a venerable pattern in academic circles of branding your research with the language of whatever hype cycle is currently active. The same research can be branded under big data, computer vision, AI, or whatever else the current trends demand.
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!
What do you want to do with coding?
What's going to give you the most leverage in the long term?
That course is going to dump you into the deep end for modern web dev. You'll probably struggle with it because it's taking on a bunch of things all at once. Some of the technology is also temporary. Will MongoDB or GraphQL still exist in 30 years? Will HTML, CSS, and JS exist in 30 years? Focus first on fundamentals that will give you a leg up.
I know professional frontend devs that still struggle with HTML because they went straight into React without learning semantic HTML first. If you can master the basics early on, then learning React and other frontend frameworks later becomes way easier.
Start with building web pages rather than web apps. You can do apps later but there's a lot more stuff going on. It's like trying to ride a unicycle while juggling flaming torches and balancing a spoon on your nose. Maybe you could sort of figure it out but it's better to split up the tasks and handle each in turn. That course is for people that already know the basics and want to try balancing on a new unicycle.
If you want ways to practice frontend, try building copycats of websites. Read the DOM, look stuff up, make lists of HTML elements or JS built-ins and memorize them. Play games to learn CSS flexbox or grid. Do whatever as long as you like it and it's teaching you the way.
There's lots of other stuff like frontend challenge sites that are good too. You'll always be "challenged" going forward for professional projects. Some might be really easy tasks, others will be hard. Get used to being resourceful and learning how to figure things out. It's an infinite game.
This style of learning isn't unique to frontend. If you wanted to be a backend dev, learning Spring Boot before design patterns, networking, etc. would probably be a bad idea. It's better to start as a beginner and embrace learning the basics. Go slow and master things step by step. Eventually it pays off.
You could also zoom out and abstract things to help with programming languages. Popular languages are pretty similar. Familiarize yourself with basic control flow syntax in one language and chances are it carries over into others. The same goes for "paradigms" like imperative, OO, and functional programming (others exist but they're more niche). Learning a paradigm is like rebuilding the thought process for your brain. If you learn different paradigms, then your thinking gets more flexible and you can approach problems differently. You might like the "aha" moments you get when things finally connect too!
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.
Ah, this missed the mark since the domain is all political/state related. I saw the mental liquidity story from today and it reminded me of an old book they published about how to think. That one has better theory based talk. This article has too many references to conflicts so it's kind of distracting from the interesting stuff.
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.
I've read your email. Thanky you very much for the offer. I relayed it. I would like to make sure it actually works when it arrives at her place. I heard the keyboards of those laptops are fine which would be a huge plus over her programming on her phone.
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!