> Context switching is a skill that gets easier the more you practice it, just like any other.
Totally agree with this!!
I learned this when I started off as a junior dev. We had some shitty machines and the project compiled for like almost 10mins. Most of the people just read the news and stuff and for some reason I started reading Clean code from Bob Martin (probabbly someone sent me a pdf of it or something). I remember reading it all in a few weeks using those breaks. Then I just kept the habit for almost a year (until we got some better workstations).
>The new way: The entire premise of AI coding tools is to automate the thinking, not just the typing.
That’s the promise, but not the reality :)
Try this: pick a random startup idea from the internet, something that would normally take 3–6 months to build without AI. Now go all in with AI. Don’t worry about enjoyment; just try to get it done.
You’ll notice pretty quickly that it doesn’t get you very far.
Some things go faster, until you hit a wall (and you will hit it). Then you either have to redo parts or step back and actually understand what the AI built so far, so you can move forward where it can’t.
>I was thinking of all the classic exploratory learning blog posts. Things that sounded fun. Writing a toy database to understand how they work, implementing a small Redis clone. Now that feels stupid. Like I'd be wasting time on details the AI is supposed to handle.
It was "stupid" then - better alternatives already existed, but you do it to learn.
> Am I alone in this?
absolutly not
but understand it is just a tool, not a replacement, use it and you will soon find the joy again, it is there
That's not my experience. Over christmas I re wrote a restaurant POS application from laravel to vue/wrangler using bolt + chatgpt. My exact steps:
1) I took my db schema and got chatGPT to convert it to typescript types and stub data.
2) Uploaded these types to bolt and asked it one by one to create vue components to display this data(Catalog screen, Payment Dialogs, Tables page etc) and to use fetcher functions that return stub data.
3) Finally I asked it replace stub data with supabase.rpc calls, and create postgres functions to serve this data.
While I had most of the app done in a few days, testing, styling and adding bug fixing took a month.
Some minor stuff was done manually by me: Receipt printer integration integration because bolt wasn't good at epson xml or related libraries that time.
Finally we released early feb and we received extremely good feedback from our customers.
However now I'm using claude and even higher percentage of code is generated by it now. Our feature velocity is also great. After launch we have added following features in 6m
1) Split Table Payments
2) Payment Terminal Integration
3) Visual Floor plan viewer
4) Mobile POS for waiters without tablet
5) Reports, Dashboard, Import/Export
6) Loyalty programs with many different types of programs
7) Self-service Webshop with realtime group ordering
8) Improved tax handling
9) Multicourse orders("La'suite")
10) Many other smaller features
This would be very hard to achieve without AI for most one-person engineering teams. Although tbf not impossible.
> The new way: The entire premise of AI coding tools is to automate the thinking, not just the typing. You're supposed to describe a problem and get a solution without understanding the details. That's the labor-saving promise.
I think here the OP introduces a strawman since as many people have pointed out, the labour saving happens in automating menial tasks and no one sane should give up "understanding the details".
> >I was thinking of all the classic exploratory learning blog posts. Things that sounded fun. Writing a toy database to understand how they work, implementing a small Redis clone. Now that feels stupid. Like I'd be wasting time on details the AI is supposed to handle.
On the contrary. Reading ToyDB[1] source code helped me understand MVCC and Isolation levels. That's knowledge that's valuable for a systems architect since at the end LLMs are just fancy word generators.
This perfectly aligns with my experience.
Every large project I have worked on showed a clear correlation between the ease of setup and running and the number of problems on the project, like bugs and missed deadlines.
Totally agree. I work in LLM training software and I believe progress in the field is actually much slower than it should be because of the excruciatingly long feedback loops involved in development. The software stacks are deep and abstract and much of the testing involves full integration tests that take a long time to spin up.
Interesting. What aspects of the development workflow/cycle have the most room for improvement (i.e. is there ranking of the "height" of the "hanging fruit" throughout the process)? What sort of software tooling would help?
> Ani Biome uses machine learning models to provide personalized solutions for enhancing gut microbiome function and addressing inflammation, a prevalent factor in age-related chronic ailments.
> It's wild to me that Teams is so fucking horrible that many businesses who effectively get it for free as part of other dealings still choose to pay for Slack.
I don't agree.
For many years now I use Linux.
I pay for Slack because some of my clients use it and it is convenient.
For some other clients I need to use Teams.
I like Teams better. I never had issues with them. Slack I reinstall every 2-3 months because it breaks in some weird way; last time yesterday when I uploaded a 'big file' (csv of a few mb), not only did it crash but restarting it didn't help. Teams work good for chating, for the calendar, and for video calls. I have a lot better experience with Teams for video calls than Google Meet.
I want to avoid the ms ecosystem so much that I use teams vs other tools as a litmus test.
If I am not desperate for work I tell contracting firms "no teams meetings" in writing when we setting up new contracts. Often, this is isn't a problem and they setup a zoom, webex, or even a plain phone call. Frequently, they try to setup calls on teams and usually about 15m before I remind them that I won't do teams and either they tell me to install teams and send me a windows download link (which does me no good) or the frantically struggle to do anything else. When I explain that I won't install ms software and I will skip their offer for it their mind is blown and and I refer them back to the email they saw, responded to, and agreed to. Then I avoid working for someone who ignored me and would likely ignore me again over more serious matters.
I should probably have more filters like this but avoiding this and the C# work closet to me has saved me a lot of long term pain.
Avoiding C#? That's quite an unfortunate way of looking at the situation if it leads you to missing out on one of the best programming languages of today.
I strongly despise C#, and I say that with about 5 real years of experience with it. I have been on teams delivering real products with it.
It is like Java but married to microsoft while philanders as it pleases. And when I say that out loud some putz always responds "but Mono!" and then the thing I need is inevitably not supported on Mono. When it is working it is stuck on windows server and needing a reboot for some half-assed update microsoft is pushing. With Java I can have all that on a Linux but at least pick which major vendor bends me over! Maybe C# works in Unity, but that is its fan scattering mess.
In C, C++, or Rust I am not beholden to one company and can actually control the hardware to do my bidding. I can go into the compilers to find bugs and the creators are responsive when I make bug reports. Often these are more expressive and have tinier code as well. Isn't C# supposed to be faster to develop in these old crusty systems languages? Why that never the case on real teams I am on?
If performance isn't what I need but rather short development cycles there is Lua, Python, BASH, or my personal favorite Ruby. All of these allow hacking together stuff so much faster, and when I have needed they it offer more control of the garbage collector or other runtime features so I often get better performance out of them.
Then there are the shops using C#. I don't know why, and I see no obvious mechanism that causes this but the culture in C# shops are invariably terrible. I have done 16 contracts in the past 22 years and the least stressful most productive shops are always the nix using professionals or JavaScript slinging kids fresh from college.
The overly corporate C# shops always seem stuck in bad ways, pushing some non-agile scrum, lacking any critical thinking, and are often overtly hostile. These are the shops that buy whatever consultant are selling and force it on me without ever consulting me. I have seen one fist-fight break out in the office and it was in a C# shop. Somehow those backend Unix greybeard wizards are always able to talk through their differences with the 22 year blue haired kid who wants progressive typing on the TypeScript interface that is fed by that wizard's service, and they often do it while discussing technical merit instead of political posturing.
At last C# contract I started I left after 2 weeks (and I am not counting that towards my 16), because the lead developer was preposterously racist and felt comfortable opening up to me about that in that short a time period. I had a lot of self reflection about why he felt comfortable dumping his race war crap on me, and I have no clue why.
C# is not as fast as the slow languages but productive languages. C# is not productive as fast but low productivity languages. And every other thing I mentioned doesn't even have a wiff of vendor lock-in. I am good without C# and the cultures that somehow arise around it.
(and the pay sucks I easily get double doing anything* else)
Mono as a runtime hasn't been relevant in almost a decade now (since the advent of .NET Core). "I can go into the compilers to find bugs" -> yeah, that's what Roslyn is. C# lets you control GC, marshalling, safety, calling convention, inlining, etc. for very fast hand-rolled managed or unmanaged code if you need it.
Mono is alive and well in https://github.com/dotnet/runtime/tree/main/src/mono. It serves Android, iOS, WASM and s390x targets, maybe some other too. It is generally much slower than CoreCLR, but besides supporting more platforms, has features that CoreCLR lacks like IL interpreter (technically, CoreCLR has one too but it has been broken for years and is never used).
Ideally, iOS's Mono usage will be eventually replaced with NativeAOT, but for now it's still being worked on, not in the least in iOS-targeting GUI frameworks like MAUI to provide better NAOT compatibility. In addition, NativeAOT's linker/trimmer is based on Mono.Linker and Mono.Cecil, so the project became part of .NET as was intended.
But you are right in a way, because the above is often confused with a separate, outdated Mono distribution that some people incorrectly keep insisting on installing on their Linux systems.
Yes, I wanted to mention WASM but honestly even talking about it is doing more of a disservice to modern .NET than not given the preconceptions about Mono.
Which decade did these events transpire in? 00s? It also sounds like the issues had little to do with the language and a lot with specific positions and market...
I fail to recognize the language you are talking about, but perhaps the fondness of Ruby is a subtle hint of warped perception of reality?
Ruby is just a bad technology - very slow, brittle, extremely messy the moment a codebase becomes larger than trivial, not ideal package management, unproductive. It was made work by many great engineers that would have either had more success with a different technology or would have spent less effort in achieving their goals with it. Pick C# or Kotlin with ASP.NET Core or Ktor and be faster at shipping both the initial prototype and then managing the product after years of growth, while enjoying 10x difference in server resources utilization.
But frankly your sentiment on C# is so unhinged that I don't even know where to start.
There are many companies that employ C# alongside other languages, or C# and F# exclusively, that have teams using Macs with VS Code or Rider. Whichever language/platform you had experience with has little to do with what .NET is for 8 years already, and its unproductive to insist on outdated perception.
They must have improved something because last time I tried, it had the sound quality of a 90s phone box on Linux because they copied over the Skype code which never worked.
I remember one of my interviews that went well in the end. In the middle of the interview, they mentioned using Java and building web apps. At the time, I was a C++ developer with no web development experience.
I said: "I never did web development," and their response was, "You do know how to write source code, don't you?"
I said: "Of course I do, but..."
They cut me off with: "You will pick it up, don't worry about it."
I have seen a C++ dev. almost brought to tears when trying to fix a CSS issue at a previous job. Then he broke into tears of laughter when I showed him `yarn build:dev` and the tailwind config. and package.json files :D.
Better to laugh about it than cry about it, eh :].
If it's going to be broken, have a shot battery, or be useless in 2 years it doesn't matter which of those happens, I am not willing to spend >$200 initially and then a monthly fee on it.
If I needed to track my kids' locations, I'd give them each an Airtag. $20ish and free tracking. I mind much less if they destroy/lose a $20 thing with a replaceable battery.
Serious question: I am looking at the measurements of speed on the landing page between Zed and the other editors, and they don't seem drastic. Do you actually feel the difference when typing?
Compared with VSCode, absolutely. VSCode has a range of responsiveness from "good enough" to "oh right, this is Electron". Zed is both faster and more consistent. Sure, we're talking 10s of milliseconds, but it's surprisingly noticeable. Can't speak for other editors.
I'm becoming a true convert, though I occasionally must drop down to a termianl for advanced vim features. That's high praise coming from me, as I have a high bar for adopting new tools.
Agree with the "hanging" and general responsiveness issues with VS Code, but typing (when VS Code is not taking a nap)? No way. Pure typing is not distinguishable.
No. However, VS Code sometimes freezes shortly. Maybe some GC stuff going on. But when both VS Code and Zed have finished starting (Zed of course faster) and you start typing, you don't feel a difference (unless you're on a very slow computer I guess). At least I don't. Same with Neovim.
I don't get this. There are so many things that Zed does better than VS Code, but typing latency is the least noticeable and interesting.
looks like DW-5000C - not so good, but "yuck" is a bit too much, no?