Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I build software quickly

evanhahn.com

Post reply on HN
Print view View original

91–100 of 215 posts

Re: How I build software quickly

#91

Post by skeeter2020 »

anonzzzies wrote: post #76
croes wrote: post #43

Earlier quoted context omitted.

This will get worse with AI

We already see it; the combination of job-hopping & AI are a perfect storm really. From launch to failure is definitely getting fast-tracked; few months ago we had yet another hospital system that just lost data; reading the code (no tests, no peer reviews; they don't use versioning) shows clear signs of LLMs; many files that do almost the same thing, many similar function names that do almost the same thing or actua…

And let us be very clear: this happened REGULARLY pre-AI, with long-lived systems adding contractors 12, 6 or less months over 20 or more years. Now we have AI that allows even faster iterations of this with even less conceptual integrity.

The big problem: the decision makers(c-suite executives) never really understood what was happening before, so you can't expect them to see the root cause of the problem we're actively creating. This means it will not get the attention and resourcing needed - plus they'll be gone and on to the next one after taking a huge payday for slashing their R&D costs.

Re: How I build software quickly

#92

Post by tikhonj »

> For example, if you’re making a game for a 24-hour game jam, you probably don’t want to prioritize clean code. That would be a waste of time! Who really cares if your code is elegant and bug-free?

Having worked on some 24-hour game jams and similar, I've found completely the opposite. It's when you're in a real hurry that you really can't afford bad code. Writing better code will make it easier to get it right, will put less pressure on my working memory, will let me try things faster and make those last-minute changes I wanted, will make adding features towards the end easier rather than harder and, crucially, will both reduce the chance that I need to do intense debugging and make debugging I need to do easier.

Working with good code just feels lighter.

The thing that breaks 24-hour projects isn't writing code too slowly, it's writing yourself into a corner or hitting some problem that derails your work, takes hours to solve or doesn't even get resolved until after the deadline.

A game jam isn't the place to try to squish all bugs, sure, but that's a question of what you're doing, not how. I still want to write good code in that situation because it makes my life easier within the time constraints, and because, even if I'm fine with some bugs, there are still lots of bugs that render a game unpleasant or unplayable.

I'll need to fix some bugs no matter what; I'd rather fix fewer, easier bugs than more, harder bugs!

The same thing applies to longer time horizons too. When you have more time you have more slack to deal with bad code, but that doesn't mean it makes any more sense to write it!

And, of course, once you get in the right habits, writing solid quality code becomes basically free... but, even if it really did meaningfully slow you down, chances are it would still be worth doing in expectation.

Re: How I build software quickly

#93

Post by tikhonj »

kqr wrote: post #70
hobofan wrote: post #44

> For example, if you’re making a game for a 24-hour game jam, you probably don’t want to prioritize clean code. That would be a waste of time! Who really cares if your code is elegant and bug-free? Hate to be an anecdote Andy here, but as someone who has done a lot of code review at (non-game) hackathons in the past (primarily to prevent cheating), the teams that performed the best were also usually the ones with th…

These two statements do not contradict themselves. That teams have the best code quality does not mean they must have prioritised clean code.

I mean, it's pretty strong evidence that they value good code. You don't get quality by accident. (But you do get it by habit!)

But, in another sense, they didn't "prioritize" good code because it isn't really a tradeoff. They're just better.

Re: How I build software quickly

#94

Post by jimbokun »

kukkeliskuu wrote: post #22

In recent years, I have learned how to build sufficiently robust systems fast. Here are some things I have learned: * Learn one tool well. It is often better to use a tool that you know really well than something that on the surface seems to be more appropriate for the problem. For extremely large number of real-life problems, Django hits the sweet spot. Several times I have started a project thinking that maybe Djan…

This is great, but it's for a very narrow set of programming problems.

You clearly work on web applications of moderate scale. For example, Kubernetes and Redis can suddenly become almost necessities for a back end service once it reaches a certain scale.

Re: How I build software quickly

#95

Post by anonzzzies »

skeeter2020 wrote: post #91
anonzzzies wrote: post #76

Earlier quoted context omitted.

We already see it; the combination of job-hopping & AI are a perfect storm really. From launch to failure is definitely getting fast-tracked; few months ago we had yet another hospital system that just lost data; reading the code (no tests, no peer reviews; they don't use versioning) shows clear signs of LLMs; many files that do almost the same thing, many similar function names that do almost the same thing or actua…

And let us be very clear: this happened REGULARLY pre-AI, with long-lived systems adding contractors 12, 6 or less months over 20 or more years. Now we have AI that allows even faster iterations of this with even less conceptual integrity. The big problem: the decision makers(c-suite executives) never really understood what was happening before, so you can't expect them to see the root cause of the problem we're acti…

Agreed.

Re: How I build software quickly

#96

Post by skeeter2020 »

roane wrote: post #77
croes wrote: post #43

Earlier quoted context omitted.

This will get worse with AI

I wonder if the rough draft approach is a good prompt for an agent. Since it can draft more quickly, you can review more quickly & get it on the right track.

A lot of established dev practices - like this one - are effective with AI generation. Another is the super-valuable but less common product spec that spends a lot of effort and verbiage defining what is NOT included. LLMs are helped greatly with explicit guardrails and restrictions.

I fear this is different from the "code slop jello poured over a bespoke marshmallow salad of a system" problem though. Mostly for the same reasons that Brooks described that make SW inherently hard 60+ years ago. It feels like the JS framework / SPA experience but with every.single. developer. and the 10x "improvement" is just speed.

Re: How I build software quickly

#97

Post by hamdouni »

dirkc wrote: post #81
hamdouni wrote: post #39

When possible, I try to use real data for both volumetry and heterogeneity testing. It helps reveal unknowns in the problem space that synthetic data might miss.

I try to do UX design with real data too. Not sure if that is what you mean with heterogeneity?

Not quite UX-focused, but related

I meant data heterogeneity - the variety in formats, edge cases, and data quality you encounter in production. Real user data often has inconsistencies, missing fields, unexpected formats, etc. that synthetic test data tends to miss.

This helps surface integration issues and performance bottlenecks early.

Re: How I build software quickly

#98

Post by jimbokun »

physicsguy wrote: post #34
aatd86 wrote: post #29

Earlier quoted context omitted.

oh that's interesting. Is that due to missing libraries in Go? That could be a nice open source project if so.

There's an almost pathological resistance to using anything that might be described as a 'framework' in the Go community in the name of 'simplicity'. I find such a blanket opinion to be unhelpful, what's fine for writing microservices is less good for bootstrapping a whole SaaS app and I think that people get in a bit too much of an ideological tizz about it all.

In my experience frameworks (in contrast to "libraries") add complexity making your application harder to understand and debug once you get past the initial prototype.

Also, by their very nature they almost require you to write a program of a minimum size even when a simpler program would do to solve your problem.

Re: How I build software quickly

#99

Post by strken »

creshal wrote: post #46
kukkeliskuu wrote: post #22

In recent years, I have learned how to build sufficiently robust systems fast. Here are some things I have learned: * Learn one tool well. It is often better to use a tool that you know really well than something that on the surface seems to be more appropriate for the problem. For extremely large number of real-life problems, Django hits the sweet spot. Several times I have started a project thinking that maybe Djan…

> Always choose extremely boring technology. Just use python/Django/Postgres for everything. Hell, think twice before you consider postgres. Sqlite scales further than most people would expect it to, especially for local development / spinning up isolated CI instances. And for small apps it tends to be good enough for production too.

Sqlite is mostly boring but I've found that there's just slightly more risk of something going wrong because of the way it handles locking between threads. It has tended to misbehave under unexpected load and been difficult to fix in a way that Postgres hasn't.

I'm particularly thinking of workers running tasks, here. It's possible to lock up everything with write transactions or cause a spate of unhandled SQLITE_BUSY errors in cases where Postgres would just keep chugging along.

Re: How I build software quickly

#100

Post by skeeter2020 »

albertgoeswoof wrote: post #19

> Data modeling is usually important to get right, even if it takes a little longer. Making invalid states unrepresentable can prevent whole classes of bugs. Getting a database schema wrong can cause all sorts of headaches later So much this. Get the data model right before you go live, and everything is so simple, get it wrong and be prepared for constant pain balancing real data, migrations, uptime and new features…

I came of age in SW dev when we started with the (database)schema. THis doesn't seem to be common any more and I regularly see experienced devs with low to no SQL exposure. Seems they typically work at an abstraction (or 2 or 3) above the API or maybe the ORM, but would struggle to write the resultant query, let alone profile it.

I'm not convinced this was a good abstraction that really helps us be more effective.

Post reply on HN