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!
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...
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.
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.
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?
Honestly, hire a personal trainer to help you stay on track. Keep with it for at least 6 months. I started this back in December and it has been great!
Left to my own devices I would have done one or two sessions and then quit. Now I do two strength sessions per week and long walks one or two days per week. It's not a lot but I can feel the change. I might stick with it for 12 months but it costs a decent amount.
My trainer drives out to where I live and we do exercises using body weight and basic equipment (dumbbells and boxes). It also helps since I can make note of the exercises and copy the routine once I kick into my own training. They can give you lots of useful tips for how to build muscle and stick with it too!
I was treating it more like a course in how to stay in shape for the rest of my life. I'll probably do strength training and walks from here on out until I die of old age. (early 30s btw)
This is a great idea! With everything on the internet trending towards instant gratification, it's counter intuitive for some of the most rewarding things to be slow. Building new relationships with people in your community takes time but it can be one of the nicest things when it goes well. Strengthening friendships usually feels worth it too.
Yeah, the world goes through cycles of sucking. It's not all one problem. It's just a bunch of problems piling on at the same time over the last few years. Most of it boils down to economics.
You can still be yourself and make the world a better place for others. Just because some people have problems doesn't mean you have to emulate their bad behavior. The golden rule still applies and lots of people are still looking out for each other. If you run into problems, get involved with your community to try to solve them.
Instead of focusing on all of the external problems around you, focus on how you're processing them. It's okay to get therapy if it seems like overload. It's also okay to just not do anything for a weekend so you can de-stress and relax.
Try tuning out from all of the noise for a little bit. There's probably some internet/news withdrawal at first but after you stop worrying about everything, it's easier to see what's directly affecting you.
Prioritize fun stuff like finding a good book and making some tea. Go hang out with friends and have an adventure. Be unproductive for a while. Do weird things. Take an art class or find a community group. Life is happier when you're in a positive community and having fun. Most people are still good.
There are some market inefficiencies that have been documented but they seem rare. The post earnings announcement drift (PEAD)[0] is a thing that exists but shouldn't if markets were totally efficient. That gets used for gains pretty consistently but not 100% of the time. Euan Sinclair had a book where he mentioned a return of 9-27% when traded on annually.[1]
Some of the big players have moves like that which work well given the right market conditions. My guess is that they have many, many patterns like that to trade on or models which are right more often than not. I don't know anything though since I'm a 101 retail investor... Positional options trading and volatility stuff makes my brain hurt :(
Have you seen strategies like that before? It's really interesting to dig into but seems to require a lot of knowledge to know how to trade on.
Since we're all speculating, I would guess that ocean acidification could be at play here. The arctic regions are carbon sinks so they experience acidification earlier than other parts of the ocean. When the CO2 is absorbed into the ocean it causes the pH level to decrease, making the waters more acidic. This inhibits CaCO3 (calcium carbonate) formation found in many ocean species like crabs.
If there's a rapid die off of this magnitude there aren't many other problems which would match this level of impact. It could be something else environmental like the water temperature but it doesn't seem like an anthropogenic problem. Similar problems have happened already for other species like oysters.[0]
I was an intern with NOAA in a fisheries lab studying ocean acidification back in college in 2011. There was a large die off in oyster farms the year before which wiped out a good size of their production. The issue then was that the farms were cycling the water in directly from the ocean into the tanks without adjusting the pH. As the pH in the ocean water dropped, it killed off all of the oysters in the farms all at once. They had to do a quick about face to treat the water to regain the catch.
Ocean acidification seemed like a problem that would get worse and worse over time. The estimate back then was that it would take roughly 50 years for the CO2 in the air to equilibrate with the CO2 in the ocean. Since we won't stop emitting any time soon it's going to get a lot more acidic.
I'm a decade behind on the status but back then it seemed like there were a lot of unknowns around the problem too. I'm not sure if more has come to light on the impacts it might have for ecology or the biochemistry of different species. It was a complex problem so predicting the outcome seemed extremely difficult. Hopefully more is known but if not surprises like this would likely crop up. For shellfish, once it goes under a certain pH threshold for a species the young will be unable to form shells which can cause them to die en mass in a short time period.
It doesn't seem like a problem that we can engineer our way out of. The best we can do is probably to monitor and perform science experiments to see some of it coming. Then try to mitigate the damage.
It seems like NOAA would have been able to call out the calcification problem for the snow crab in advance though since there have been issues with other crab species.[1] They probably would have detected the pH change in the waters too so this might not be the cause. Either way it's an interesting subject to learn about.
> The resulting idea is excellent but it's technically hard. I've put all the resources of my company and myself into getting it made.
I'm with you and want you to crush it! Playing devil's advocate for a minute, there might be some issues with the current state of things.
Parts that will make it hard to get in (and could put the company health at risk):
- the company is default dead right now with no revenue stream[0]
- employees were hired so the burn rate already started with no product
- currently locked into doing a big launch
- the majority of the focus is on software development
- it's harder to do significant product changes since you already have a team of employees coding the technical solution
- there are no customers on board yet
Sorry if any of those parts are off base from the actual details. From what you posted it sounded like there was positive user feedback but no customers/revenue.
Before focusing on a development team you also need to know that your product is something users love. Don't get emotionally invested in creating the "right" thing off the bat. Learn how to talk to different users frequently and set up development cycles to know that you're building something people need. It's better to not be attached emotionally and learn how to iterate quickly then to start a big development push early on.
The more you invest into building an initial idea, the more locked in you are on that solution. If you have any way to prototype a $500k solution manually or with a cheap automation that doesn't scale, do that first. Your goal is to know that you're solving the right problems.
An early launch should be able to solve something to prove viability but be easy to build. The faster the future product build times are, the more chances you have to iterate and measure your solutions with UX research. Getting user feedback early and often helps de-risk your product build cycles. With only one big launch, it puts most of the risk into things going well with the initial product build. It will also miss out on early growth opportunities that you can have with customers. They won't be able to give input as the parts are built and they'll have less connection to the early product if they weren't part of shaping it.
Actions also speak louder than words. Many people are nice when talking to you because people like to help each other. Get people to pay for your product. Any promise without money is worthless.
For a pre-seed stage bootstrap your best investors are your customers. They'll give you money without taking equity and help you prove out the product market fit. That gives you leverage later when talking to investors because you'll have a nice picture of how the company has been solving real problems, acquiring new customers, growing revenue, etc. Any prospective investors should be worried about missing the chance to grow with you.
I think these line up with problems 1, 2, and 3 from the startup lessons essay.[1]
Having prior experience with a bootstrapped company is great and they'll probably be neutral or positive on re-applying. They'll also like that you've talked extensively with users before building the product. I don't know much about launching SAAS businesses so that initial build hurdle could just be part of the process. My bad if that was overly critical. Building something in front of users can be extra nice though.
YC put out the online startup school for free.[2] If you're only looking for advice, that may be more bang for the buck. It's a different story if you want to take funding and use YC as an on-ramp for that.
Either way, it sounds exciting. Sorry if this post sounded all negative. I was trying to give advice from where I think YC would be coming from. Things can go well without those call outs. I'm just a random internet person. I hope it ends up being successful!
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!