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

41–50 of 215 posts

Re: How I build software quickly

#41

Post by ChrisMarshallNY »

pandemic_region wrote: post #32
ChrisMarshallNY wrote: post #30

I've found that a "rough draft" is pretty hard to maintain as a "draft," when you have a typical tech manager. Instead, it becomes "final ship" code. I tend to write ship code from the start, but do so, in a manner that allows a lot of flexibility. I've learned to write "ship everywhere," even my test harnesses tend to be fairly robust, ship-Quality apps. A big part of that, is very high-Quality modules. There's alwa…

Tangent, is it a Swift thing to have "* ################################################################## / comment markers ? It becomes quickly very visually dominant in the source code: > / ###################################################################################################################################### / // MARK: - PUBLIC BASE CLASS OVERRIDES - / ###############################################…

Nope. It's a "Me" thing. I write code that I want to see. I have fairly big files, and it makes it easy to scroll through, quickly. It also displays well, when compiling with docc or Jazzy.

My comment/blank line-to-code ratio is about 50/50. Most of my comments are method/function/property headerdoc/docc labels.

Here's the cloc on the middle project:

    github.com/AlDanial/cloc v 2.04  T=0.03 s (1319.9 files/s, 468842.4 lines/s)
    -------------------------------------------------------------------------------
    Language                     files          blank        comment           code
    -------------------------------------------------------------------------------
    Swift                           33           1737           4765           5220
    -------------------------------------------------------------------------------
    SUM:                            33           1737           4765           5220
    -------------------------------------------------------------------------------

Re: How I build software quickly

#42

Post by physicsguy »

GaryNumanVevo wrote: post #36
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…

I feel like Django has the largest RoI of any framework out there

I think Rails is stiff competition, it's just I prefer Python.

Re: How I build software quickly

#43

Post by croes »

anonzzzies wrote: post #2

We encounter many rough drafts (yours) in production systems. If the original devs are still there, it is usually something along the lines of: I showed the rough draft to my manager, they flagged is as done and I was assigned to another task.

This will get worse with AI

Re: How I build software quickly

#44

Post by hobofan »

> 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 the best code quality and often at least some rudimentary testing setup.

Re: How I build software quickly

#45

Post by physicsguy »

aatd86 wrote: post #40
physicsguy wrote: post #34

Earlier quoted context omitted.

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.

I don't think anyone would advise to do everything from scratch all the time. It's mostly about libraries vs opinionated frameworks. No one in their right mind would say: just use the standard library but I've seen it online. That discourse is not helping. I think people get this miscontrued on both sides. A set of reusable, composable libraries would be the right balance in Go. So not really a "framework" either. I…

It's always going to be more work with composable libraries since they don't 'flow'.

Just picking one of the examples I gave, pagination - that requires (a) query param handling (b) passing the info down into your database query (c) returning the pagination info in the response. In Django (DRF), that's all built in, you can even set the default pagination for every endpoint with a single line in your settings.py and write no more code.

In Go your equivalent would be wrangling something (either manually or using something like ShouldBindQuery in Gin) to decode the specific pagination query params and then wrangling that into your database calling code, and then wrangling the results + the pagination results info back.

Composable components therefore always leave you with more boilerplate

Re: How I build software quickly

#46

Post by creshal »

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.

Re: How I build software quickly

#47

Post by benterix »

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…

> Forget Kubernetes, Redis

While I agree with you, these two are the boring tech of 2025 for me. They work extremely reliably, they have well-defined use cases where they work perfectly and we know very well where they shouldn't be used, we know their gotchas, the interest around them seems to slowly wane. Personally, I'm a huge fan of these, just because they're very stable and they do what they are supposed to do.

Re: How I build software quickly

#48

Post by bob1029 »

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…

The gaming use case is what makes this apt advice. If you've got 24h to make a game and you're spending more than ~1h worrying about the source code cleanliness, I don't think it's gonna go well.

Systems like UE blueprints showcase how pointless the pursuit of clean anything is when contrasted with the resulting product experiences.

Re: How I build software quickly

#49

Post by Leherenn »

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.

I have had some bad experiences with Sqlite for local desktop apps with regards to memory usage, especially on MacOs. Insert and delete a few thousands rows per hour, and over a few days your memory usage has ballooned. It seems to cause a lot of fragmentation.

Re: How I build software quickly

#50

Post by dkga »

Leherenn wrote: post #49
creshal wrote: post #46

Earlier quoted context omitted.

> 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.

I have had some bad experiences with Sqlite for local desktop apps with regards to memory usage, especially on MacOs. Insert and delete a few thousands rows per hour, and over a few days your memory usage has ballooned. It seems to cause a lot of fragmentation.

Curious to hear more about your experience, since my impression from hacking around in native Apple software is that pretty much a bunch of it is based on top of sqlite3. The Photos app is a case in point I remember off the cuff.
Post reply on HN