> I chose this words because I don't think good code is nearly as expensive with coding agents as it was without them.
Still navigating this territory, but I think a lot of people are getting caught up on the idea that producing code is simply a matter of typing it at the keyboard.
One of the benefits of something like Claude Code isn't just the code it produces, but the ability to quickly try out ideas, get some feedback, AND THEN write the good code.
> than the more aesthetically pleasing
Agreed. What even is "good" code? So much of the bad code I write isn't necessarily that it's ugly, it's bad because it misses the mark. Because I made too many assumptions and didn't take the time to actual learn the domain. If I can eek out even a few more hours a week to actually build worthwhile solutions because I was able to focus a bit more, it's a win to me. My users in particular have a really difficult time imagining features without actually seeing them. They have a hard to articulating what's wrong/right without something tangible in front of them. It would be hard to argue that having the ability to quickly prototype and demo features to people is a bad thing.
This was the single worthwhile point behind “agile” development: getting new code in front of users as quickly as possible to know whether or not you’re building the right thing.
With agile that meant delivering something to evaluate every two weeks instead of 6 months or a year. Now with AIs maybe it should be a new version every day? Are current processes outside of writing the code capable of supporting that cadence? Do users even want to try new versions that often?
One thing people don't realize with regard to smart thermometers is that they're a goldmine to people who break into houses.
A 51 straight weeks of 70 degree temperate followed by a week > 70 might imply they're on vacation. People who turn down the heat/ac and turn it back on when they come home from work is also a pattern pretty apparent by that info.
> A 51 straight weeks of 70 degree temperate followed by a week > 70 might imply they're on vacation. People who turn down the heat/ac and turn it back on when they come home from work is also a pattern pretty apparent by that info.
> No projects, unless it's only you working on it, only yourself as the client, and is so rigid in it's scope, it's frankly useless, will have this mythical base.
This is naive. I've been building an EMR in the healthcare space for 5 years now as part of an actual provider. We've incrementally released small chunks when they're ready. The codebase I've built is the most consistent codebase I've ever been a part of.
It's bureaucracy AND government process AND constantly changing priorities and regulations and requirements from insurance providers all wrapped up into one. And as such, we have to take our time.
Go and tell the clinicians currently using it that it's not useful. I'm sure they won't agree.
> Perfectly architected code vs code that does the thing have no real world difference
This just flat out isn't true. Just because YOU haven't experience it (and I think you're quite frankly telling on yourself with this) doesn't mean it doesn't exist at all.
> Because you yourself had to choose between time/opportunity vs your ideals and you chose wrong.
Like I said above, you're telling on yourself. I'm not saying I've never been in this situation, but I am saying that it's not the only way to build software.
Lesson learned. Yes you are right. I am indeed a junior, I made that comment when I was tired honestly with a rushed project. There's no delete button, otherwise I'd have deleted it when I cooled off. Thank you for giving me hope that good code is still being made.
> Thank you for giving me hope that good code is still being made.
So I've been on both sides, and it's why I responded. While you are absolutely correct that those situations do exist, I just wanted to point out it's not always that way. And I felt exactly as you did about software in general until I finally found a place or two that wasn't just a cash printing machine.
And it's pretty awesome. I've come to realize burnout is less about the amount of hours you put in and more about what you're doing during those hours.
It's tough, especially in the beginning. Push through it. Get some experience that allows you to be a bit more selective in what you choose, and fingers-crossed you'll find yourself in the same spot. One common denominator in all of the good jobs I've had was that the leadership in those companies (3 of them) were all tech-focused. Could be a coincidence, but it's a pattern I've seen.
Also anecdotally, I've had a handful of software development positions throughout the years (never at a position with more than 200-300 person company) and have yet to be laid off due to money. I've yet to be laid off at all, but that's irrelevant.
I truly believe that these new tools will actually hurt the bigger companies and conversely help smaller ones. I'm in healthcare. The big players in the EMR space are Epic and Cerner. They are one-size-fits-all behemoths that hospitals have to work against than with. What if, instead of having to reach out to the big players, the economics of having a software developer or 2 on staff make it such that you could build custom-tailored, bespoke software to work "with" your company and not against?
> What if, instead of having to reach out to the big players, the economics of having a software developer or 2 on staff make it such that you could build custom-tailored, bespoke software to work "with" your company and not against?
The behemoths exist especially, but not exclusively, in that space because regulations (correctly) are steep. In the case of hospital systems you're talking both the management and protection of both employee and patient data. That's not to say of course that the behemoth's are particularly good at that, it's merely that if the hospital rolls it's own solution, as you suggest, they then take on the liability should that system go wrong. On the other side, if Epic has a data breach, every hospital shrugs it's shoulders. It isn't their problem. And, even more fundamentally, if Epic as a product sucks ass... well. The employees didn't choose it, neither did the patients, leadership did.
You see these relationships (or lack thereof) all over the place in our modern world, where the people doing the work with these absurdly terrible tools are not given any decision-making power with regard to which tools to use. Hell, at my workplace, we actually have some in that leadership asks if we're happy with our various HR softwares and things, but fundamentally, they all pretty much suck and we're currently sitting at the least shitty one we could find, which is far from a solid fit for our smaller company. But it's the best we can do because none of these suites are designed to be good for people to use, they're designed to check a set of legal and feature checkboxes for the companies they sell to.
Honestly I don't know how you fix this, short of barring B2B SAAS as an entire industry. Time was, when you wanted to run a sales company, you had to run your own solution to keeping track of internal data. Salesforce didn't exist. You had rows upon rows of file cabinets, if there was a fire data was a lost, if a disgruntled worker stole your sales list and sold it to a competitor, that was it's own issue to deal with. Now crooks can crack the locks off of NetSuite and steal your whole fucking business without even knowing where the hell your HQ even is or caring for that matter, and our business universe if you will is bifurcated all to hell as a result. Companies are engaged in constant games of "pin the legal responsibility on someone else" because to compete, they need internet and software based sales and data management systems, but building those systems is a pain in the ass, and then you're responsible if they go wrong.
Aren't they still going to need to reach out to the big players because of the regulatory environment? And for good reason, as it happens. We don't need hospitals handing over the public's health data to the cheapest person they can find to prompt it all into Claude.
You can be a small player and still deliver immense value in health care I work at a firm in a niche with about 30 employees. We follow all regulations and go above and beyond them in regards to security.
Absolutely. I'm in the same boat (a bit bigger with around 200).
It's crazy the underlying business has succeeded despite being boxed in by the software they're currently using. And at least in my niche, you only have a few options. Each with their own unique quirks.
Instead, EMR's could position themselves as more of a "data provider" where you build bespoke software on top of the underlying storage. And to that end, having the abiliy to pump out small, focused apps can be really beneficial.
Just anecdotally, my experience was the total opposite. I didn't work in the health care industry long though and I think you're probably right in general. But you might also find there's a lot of variation between small companies too and a lot of failures for every success I suppose.
> Aren't they still going to need to reach out to the big players because of the regulatory environment?
First, saying "We can now build software faster" doesn't imply that "we" won't eventually include professionals. There is nothing stopping someone from building up an app and having people come in to polish it up.
Second, "regulatory environment" doesn't actually mean somethin because every part of the industry has different regulations and requirements. There are different standards for what big hospitals can use and the software requirements than there are for home care software. So trying to wave this "you can't because of regulations" wand doesn't make sense if you're actually in the business.
Third, I was speaking more to the small-medium sized agency.
Fourth,
> We don't need hospitals handing over the public's health data to the cheapest person they can find to prompt it all into Claude.
Means absolutely nothing since you don't need to feed health data into a Claude instance to build healthcare apps. It sounds like you aren't in the field or familiar with it.
And lastly, if you're a Microsoft customer with a BAA, then you're already covered by HIPAA. Again, not something you would know if you weren't in the industry, but now you do.
What if, instead of having to reach out to the big players, the economics of having a software developer or 2 on staff make it such that you could build custom-tailored, bespoke software to work "with" your company and not against?
Because the hospitals those practices want to associate with say "we're on Epic and expect you to be as well"?
Wife in healthcare management...overhear this conversation once or twice a week.
Also the nurses in the floor learn the system and many are not great at adapting to different interfaces. Travel nurses who come in and only worked with GE or Cerner and now having to use Epic causes all kinds of issues.
Also from what I’ve seen is big city hospitals use a mix of all three. Which I believe actually creates an opening as it shows a willingness to use different walled gardens.
However I think there are a lot of opportunities to just build on top of these systems rather than wholesale replace. Because they’re one size fits all and the people who work on them haven’t a single designer bone in their body the interfaces are terribly clunky and slow. Macros exist but seemingly no one is aware of them. It’s rife to build better interfaces tied into macros behind the scenes.
> What if, instead of having to reach out to the big players, the economics of having a software developer or 2 on staff make it such that you could build custom-tailored, bespoke software to work "with" your company and not against?
It's probably risk and liability and not development costs that keep things from moving in house. Not things AI is great at mitigating.
That's not actually true. It might be for the bigger companies, but certainly not the smaller ones.
And "risk" in this industry could mean any number of different things. We, as a medium-sized provider, have a BAA with Microsoft for HIPAA. That means that I can utilize information I've gotten from my EMR and build line-of-business apps that bridge the gaps between other systems they may have to work in. In fact, our Microsoft tenant has a much higher level of security than the underlying EMR.
I'm quite literally living what I spoke about above. The reason why I was brought in was because teh current CEO has a very tech-focused mindset, otherwise agencies usually can't afford a full-time software developer. Now, those economics are changing.
Also, I haven't heard of an agency that didn't want custom reports built because they found the default ones unsuitable. So even something like the ability to mainline Power BI reports would be compelling.
Hospitals are huge liability sinks. Doctors are constantly sued for killing, injuring, or traumatizing patients, because it's impossible to consistently save everyone.
Which is why they don't food liability when they can. Is it worth saving $100,000 a year if it allows the lawyer to say "if they had used industry standard software would the medical error have happened?"
The research hospital in my neighborhood has a whole biomedical engineering dept and regularly tries out new medical technology on me.
They consistently try non-standard approaches if they feel like it can improve the standard of care since their commercialization team can make more money. They can also iterate faster and deliver better outcomes.
I'm guessing either EHR software is uncompetitive or nobody has tried it yet. Or it's just because I live in Toronto and we have a really good healthcare system.
Improved EHRs would improve medicine by making doctors more productive. Increases the amount of time they can spend billing instead of on administrative overhead. More billing is more money.
I don't think this is bureaucratic maliciousness to kill innovative EHRs. My guess is it's a really hard and boring problem to solve due to the integration work which makes it hard to break the network effects.
> Most engineers (including me) spent months grinding LeetCode at least twice in their career, studying system design, and passing grueling 6-round interviews to prove they are the “top 1%.”
Really grateful that the opportunities I've been given weren't predicated on knowing things completely irrelevant to my job. I have spent exactly zero time solving LeetCode problems in my career (beyond algorithm stuff in college).
As a Clojure developer I have the opposite experience. The more they ignore my open source work, the more they never call up any of my references, the more they give me useless test jobs and assignments unrelated to the actual work, the more it's a signal of a place with poor engineering culture and generally also not that great salaries.
However the places that actually do read my open source work, do contact my references, and where the interview has had no tech assignments of any kind other than a simple discussion about a variety of topics, perhaps just going over some of my OSS projects, the higher the salary has been.
This is in Northern Europe though, your mileage may vary.
Still navigating this territory, but I think a lot of people are getting caught up on the idea that producing code is simply a matter of typing it at the keyboard.
One of the benefits of something like Claude Code isn't just the code it produces, but the ability to quickly try out ideas, get some feedback, AND THEN write the good code.
> than the more aesthetically pleasing
Agreed. What even is "good" code? So much of the bad code I write isn't necessarily that it's ugly, it's bad because it misses the mark. Because I made too many assumptions and didn't take the time to actual learn the domain. If I can eek out even a few more hours a week to actually build worthwhile solutions because I was able to focus a bit more, it's a win to me. My users in particular have a really difficult time imagining features without actually seeing them. They have a hard to articulating what's wrong/right without something tangible in front of them. It would be hard to argue that having the ability to quickly prototype and demo features to people is a bad thing.
reply