How I Program in 2024

I think this is highly domain dependent. I currently am working on codebase that has tests for a part of it that are an incredibly useful tool at helping me refactor that particular part. Other parts are so much UI behavior that it is significantly faster to catch bugs by manual testing because the UI/workflow either changes so fast that you don’t write tests for it (knowing they’ll be useless when the workflow is redesigned in the next iteration) or so slow that that particular UI/workflow just doesn’t get touched again so refactors don’t happen to it to introduce more bugs.

I have never found tests to be universally necessary or helpful (just like types). They are a tool for a job, not a holy grail. I have also never met a codebase that had good test coverage and yet was free of bugs that aren’t then found with either manual testing or usage.

Somewhat hyperbolically and sarcastically: if you are good enough to write perfect tests for your code, just write perfect code. If you aren’t perfect at writing tests, how do you know the tests are complete, bug free, and actually useful? :)

A test will only catch an edge case you already thought of. If you thought of it anyway why just not fix the bug instead?

Tests have burned out software engineers who waste the majority of their time deriving tests that will pass anyway. And then a significant code change will render them useless, at which point they have to be rewritten from scratch.

No your program will not be more correct with more tests. Deal with it.

The focus on automated unit/integrations tests is a relatively modern thing (late 90's?). There was some pretty large and extremely reliable software shipped before that focus. Random example is that the Linux kernel didn't have much tests (I think these days there is more testing). Unix likely didn't have a lot of "tests". Compilers tended to have them. Operating systems less so. Games (e.g. I'm sure Doom) didn't tend to have tests.

You need to find a balance point.

I think we know that (some) automated tests (unit, integration, end to end) can help build quality software. We also know good tests aren't always easy to write, bad tests make for harder refactoring and flaky tests can suck a lot of time on large projects. At the same time it's always interesting to try different things and find out what works, especially for you if you're a solo developers.

When you have no tests your problems go away because you don’t see any test failures.

The flip side of this is the quote that "tests can show the presence of bugs, but never their absence". It better fits my experience here; every few months I'd find a new bug and diligently write a test for it. But then there was a new bug in a few months, discovered by someone in the first 10 minutes of using it.

I'm sure I have bugs to discover in the new version. But the data structures I chose make many of the old tests obsolete by construction. So I'm hopeful that I'm a few bugs away from something fairly stable at least for idle use.

Tests are definitely invaluable for a large team constantly making changes to a codebase. But here I'm trying to build something with a frozen feature set.

I'm puzzled by people debating tests. why such hate? They catch bugs, prevent breaking changes, and ensure API stability. I have never seen tests preventing me from refactoring anything. I guess it depends on the company and the processes :thinking:

When you have no tests your problems go away because you don’t see any test failures.

Never have I tested anything and NOT found a bug, and most things I tested I thought were already OK to ship.

It's a trade-off. Most of the business world ran on, and to some extent still runs on, Excel programs.

There are no tests there, but for the non-tech types who created these monsters, spending time on writing a test suite has a very real cost - there's less time to do the actual job they were hired for!

So, yeah, each test you write means one less piece of functionality you add. You gotta make the trade-off between "acceptably (in frequency and period) buggy" and "absolutely bullet-proof no matter what input is thrown at it".

With Excel programs, for example, if the user sees an error in the output, they fix the input data, they don't typically fix the program. It has to be a dealbreaker bug before they will dive into their code again to fix the program.

And that is acceptable to them.

Tests written for pure functions are great. Tests written for everything else may be helpful but might not be.

When you have no tests your problems go away because you don’t see any test failures.

Never have I tested anything and NOT found a bug, and most things I tested I thought were already OK to ship.

I wasn't a very fast typist, I could do about 180 strokes per minute. My teacher, a tiny 80 year old lady, talked the whole time to intentionally distract her 5-6 students. It was a hilarious experience. One time, when I had an extra slow day, the monologue was about her learning to type, the teaching diploma required 300 strokes per minute, from print, hand writing and dictation. Not on such a fancy electronic type writer! We had mechanical type writers! And no correction lint! She was not the fastest in her class by far and many had band-aids around smashed fingers. Trying to read type, not listen and not burst out in laughter I think she forced me down to 80 strokes per minute. Sometimes she had me sit next to a girl doing 450 strokes per minute. Sounded like a machine gun. They would have casual conversation with eye contact. I should not have noticed it, I was suppose to be typing.

When writing code and think about those "inevitable" bugs I always think of the old lady, who had 1000 ways of saying: you only think you are trying hard enough... and: we had no correction lint....

Take a piano, there is no backspace. You are suppose to get it right without mistakes.

If you have all of those fancy tools to find bugs, test code, the ability to quickly go back and forwards, of course there will be plenty mistakes.

If they need to be there no one knows.

> Never have I tested anything and NOT found a bug, and most things I tested I thought were already OK to ship.

I have found that, in my own case, every time I’ve written a unit test, it has exposed bugs.

I don’t usually do the TDD thing, where I write failing tests first (but I do it, occasionally), so these tests are usually against code that I already think works.

That said, I generally prefer test harnesses to unit tests[0]. They still find bugs, but the workflow is less straightforward. They also cause me to do more testing, as I develop, so the bugs are fixed in situ, so to speak.

[0] https://littlegreenviper.com/testing-harness-vs-unit/

Completely agree on tests. It's much more enjoyable for me to write some automated tests (unit or integration) and be able to re-run them over and over again than it is for me to manually run some HTTP requests against the server or something. While more work up front, they stay consistent and I can feel more comfortable with my code when I release.

It's also just more fun to write code (even a test) than it is to manually run some tests over and over again, at which point I eventually get lazy and skip it for that last "simple, inconsequential" commit.

Coming from a place where we never wrote tests, I introduce way fewer bugs and feel way more confident every day, especially when I change code in an existing place. One trick is to not go overboard and to strike an 80/20 balance for tests.

I watched a video by Russ Cox that was recommended in a recent thread, Go Testing By Example:

https://www.youtube.com/watch?v=X4rxi9jStLo

There's _a lot_ of useful advice in there. But what I wanted to mention specifically is this:

One of the things he's saying is that you can sometimes test against a simpler (let's say brute force) implementation that is easier to verify than what you want to test.

There's a deeper wisdom implied in there:

The usefulness of tests is dependent on the simplicity of their implementation relative to the simplicity of the implementation of what they are testing.

Or said more strongly, tests are only useful if they are simpler than what they test. No matter how many tests are written, in the end we need to reason about code. Something being a "test", doesn't necessarily imply anything useful by itself.

This is why I think a lot of programmers are wary of:

- Splitting up functions into pieces, which don't represent a useful interface, just so the tests are easier to write.

- Testing simple/trivial functions (helpers, small queries etc.) just for coverage. The tests are not any simpler than these functions.

- Dependency inversion and mocking, especially if they introduce abstractions just in order to write those tests.

I don't think of those things in absolute terms though, one can have reasons for each. The point is to not lose the plot.

It depends a lot on what you work on and how you program. Virtually none of our software has actual coding errors, and when developers write new parts or change them, it’s always very obvious if something breaks. Partly because of how few abstractions we use, partly because of how short we keep our chains. Letting every function live in isolation and almost never being used by multiple parts of the software. Both the lack of abstractions and the lack of reuse is against a lot of principles, and it’s not exactly like we refuse to do either religiously, but the only real principle we have is YAGNI, and if you build and abstraction before you need it you’re never going to pass a code review. As far as code reuse goes, well, in the perfect world it’s sort of stupid to have a lot of duplicate code. In a world where a lot of code is written on a Thursday afternoon by people who are tired, their babies kept them awake, the meetings were horrible, management doesn’t do the right things and so on. Well, in that world it’s almost always better to duplicate code so that it doesn’t eventually become a complicated abstract mess. It shouldn’t, and I’m sure it doesn’t in some places, I’ve just never worked in such a place. I have worked with a lot of people who followed things like clean code religiously and the results were always unwieldy code where even small changes would take weeks to implement. Which is completely counterproductive to what the actual business needs. The benefit of YAGNI is that it mostly applies to tests as well, exactly because it’s basically impossible to make changes without knowing exactly what impact you’re having on the entire system.

What isn’t easy is business logic, and here I think tests are useful. Or at least they can be. Because far too often, the business doesn’t have a clue what they want up front. Even more often the business logic will change so rapidly that tests automated tests become virtually useless since you’re going to rely on acceptance tests anyway.

Like I said, I’m not religious about it. I sometimes write tests, but in my anecdotal experience things like full test-coverage is an insane waste of time over a long period.

He was basically starting over. Definitely need to delete the tests. One of the issues with enterprise development is choking the project with tests and other compliance shit as soon as people start coding. Any project should be in a workable/deployable state before you commit to tests.

As programmers we are inundated with choice and options. Our tooling and whatever the zeitgeist considers "best tooling" tends to err on the side of making $THING easier to do.

But having 1000 easy options always available introduces severe cognitive burden to pick the correct choice. That's part of the reason why we as an industry have enshrined all shorts of Best Practices and socially shame the non-adherents.

Don't get me wrong, bad architecture and horrible spaghetti code is terrible to work with. However, questioning the things that feel Obviously Correct and exploring different and austere development environments that narrow our set of available choices and tools can sincerely operate to sharpen our focus on the end goal problem at hand.

As for version control, branching encourages cutting a program into "independent features"; history encourages blind usage of potentially out-of-date functional units; collaborative work reifies typically-irrelevant organizational boundaries into the code architecture (cf Mel Conway); etc.

Version control's benefits are also common knowledge, but there are real tradeoffs at the level of "solving business problem X". It's telling that such tradeoffs are virtually invisible to us as an industry.

I think in this case, the author means coding version logic into the app itself. eg. versioned API endpoints for backwards compatibility

The author is probably experiencing mental fatigue or even burnout about programming.

If version control bothers you that much I'd say it's a good sign that you need to take a break.

Could this person be intentionally giving bad advice?

The author does not seem to have to support any professional / paying users, and wants freedom to experiment more than a guarantee of a known working version. The author also does not seem to work on large systems, or do significant teamwork (that is, not being the only principal author).

In such a situation, all these tools may not provide a lot of value. A flute player in a large orchestra playing a complex symphony needs notes and/or a conductor; a flute player playing solo against a drum machine, or, playing free jazz, does not much need notes, and would likely be even hindered by them.

I'm trying to build something small with a quickly frozen feature set. I've chosen to build on a foundation that changes infrequently. There is more background at https://akkartik.name/freewheeling.

You're absolutely right that this approach doesn't apply to most programs people build today, with large teams and constantly mutating requirements.

I do still have source control. As I say in OP, I just stopped worrying about causing merge conflicts with other forks. (And I have over 2 dozen of them now; again, see the link above for details.) So I have version control for basic use cases like backups or "what did I just change?" or getting my software on new machines. I've just stopped thinking of version control, narrowly for this program, as a way to help _understand_ and track what changed. (More details on that: https://akkartik.name/post/wart-layers) One symptom of that, just as an example of what I mean: I care less about commit message hygiene. So version control still exists, but it's lower priority in my mind as a part of "good programming practice" for the narrow context of programs like this with frozen feature sets, intended to turn into durable artifacts that last decades.

Yeah, this is not good advice for the average person, even for solo projects.

Yep, commit your code when it "works". Then I can safely go off on a hair brained experiment, knowing I can easily throw away the changes to get back to what worked.

Hmm, rarely have I thought types were a burden, rather than help, maybe I’m weird.

Maybe I spend effort in making sure my types are useful and easy to work with, but one previous TypeScript I got to a state where _all_ of my database queries were automatically typed, and all of my requests and responses too, so both input output were guaranteed to be correct bg the compiler, so any bugs or errors that were left were business logic.

It was incredibly liberating - like pairing with someone who was junior but very pedantic. I ended up writing almost no unit test and only having integration level tests, cause the job of those test was mostly covered by types.

And writing the code itself was such a pleasure - you get immediate feedback if your program is correct _as you type it_. The most bizarre consequence of all this to me was writing a program for almost 2 hours, hundreds of lines of code, and then executing it and having it do exactly what you wanted on the first compile. That was both scary but exciting!

One can get over-constrained with types for sure, where you’re sending more time “fighting the types” rather than writing your code. But this is all just learning, once you understand how the typesystem works it all becomes easy to work with.

It was the same story with tests - once I started testing everything- it wasn’t easy to adopt my code to be testable, took effort, but then I learned how to make code pure, move state to the edges, manage dependencies etc, and all of those are useful practices in their own right, regardless if you write the tests or not.

Same with types - schema design and invariants, state machines, edge cases in type conversion and how to lock and manage external dependencies. Sets, unions etc - it became the way I reason about code with of without types and my code is better for it.

I also assume that types would make AI generated code much better _and more reliable_ because of the additional information and structure that it provides, so I recon they are here ti stay.

The very next dot point is agreeing with you: "The ideal quantity to use these tools is tiny, much more miniscule than any of us is trained to think".

And I agree tbh. The TS community has turned me off static typing for life. It's just wall to wall bikeshedding from the least productive people I've ever had the displeasure of working with.

I quite like Lisp 'cause I can do silly things like:

  (defun sum-triplet? (list)
    (declare (type List list))
    (and (= (length list) 3)
         (destructuring-bind (a b c)
             list
           (and (numberp a)
                (numberp b)
                (numberp c)
                (= (+ a b) c)))))

  (deftype Sum-Triplet ()
    '(and List
          (satisfies sum-triplet?)))

I keep trying to figure out the joke.

On the one hand this may be an article from a developer experimenting with different tools and techniques to advance themselves in life.

On the other hand it may just be the author wanted to gaslight ppl into a debate xD

What you should learn, is knowing when shell is the right tool for the job.

There was a saying that technology usually has inertia, if it was used for 30 years, and is used actively now, it will probably still be in use 30 years in the future.

I learned vim by necessity after shying away from this weird old tech for years, when I was forced to work on a solaris server where there was no other way to edit the code at all. It was pain and suffering for a few hours - we really wanted to fix something that day as I was working on a machine that we were “not allowed to ssh into” been driven to a different city in order to sit in front of it.

But after that day I’ve been using vim almost every day. It is not my daily driver, always felt more productive in TextMate, SublimeText and now VS Code, but it is still incredibly useful.

Any remote server I ssh into there is no question what I can or cannot do - can easily edit everything I want to. And I use it for various quick edit tasks in the shell.

Now learning shells wasn’t so dramatic for me but same rules apply, I don’t feel uncomfortable anywhere - that pod that is misbehaving in your cluster - well just ssh into it and poke around! You need to tie a few commands together as there isn’t something that does _exactly_ what your company needs - just whip up a quick bash script! - zero dependencies and can be deployed anywhere - your mac, the server the ci is running on, even windows machines!

So general rule is - if it was used for 50 years and is used now, it is probably worth learning.

I won't comment on which shell to learn, but you'll end up spending a lot of time in it, so learning your chosen shell well will pay off dividends for the rest of your life.

Yes and no.

Shell scripting is incredibly powerful and omnipresent. So you want to know the basics about pipes, loops and the like.

But the language itself is broken by design (error handling is a mess; whitespaces create headaches daily; sub-shells can be a pain; ...). So, creating reliable scripts can be a challenge, and you do not want to become an expert on how to write large programs with the shell. Other languages, e.g. Python, are much better at this.

My favorite site in this context is https://shellhaters.org. It has a list of links to the POSIX standard so that you can easily look up functionality that is part of it (and should be present on all POSIX-compliant operating systems).

If you know everything on https://learnxinyminutes.com/docs/bash/ you most likely know more than you need.

Not using source control and removing tests resulting in a better program is quite fascinating.

Can you clarify what is exactly fascinating here? They seem to be writing simple programs, used only by themselves. In these scenarios of course you don't *have* to use good eng practices.

It's also a shame that Kartik explicitly states his goals and his problem domain, yet folks react as if he'd been making comments about their goals and their problem domain.

Disagree on VC, even for solo project and no multiple version branching. Human make mistakes, knowing what you change in the last 3 weeks for >100k LOC project are godsend. It helps to find and fix issues. The better feature is branching out, because you can do what you want while still having a way to go back to previous stable.

As for automated tests? That's fine.

imo taking the time to learn enough git to setup an ignore file, then run be able to run git init; git add -A, git commit -a -m "before I changed the foo function to use bar" and then go back to older revisions is well worth it. you don't have to master it, but just having a commit message and a version to get back to has saved my bacon more times than I can remember, nevermind more advanced operations.

The person who wrote both the original and new versions isn't qualified to say one is better than the other?

There is adverse selection at play. The top/world-class programmers are too busy to write blogs.

Tech is a relatively immature industry. And a lot of time and effort and money in it is devoted to non-critical products.

I'm not directing this at the OP, because they have actually thought about it even if I disagree with them, but there are a lot of people working in tech and in software who do not care about product quality at all. They're paid a lot of money and exclusively focus on shipping ASAP, quality be damned, so they keep their metrics looking good and the $$$ flowing. Add in the industries tendency for very short term tenure at jobs and you end up in a situation where people think what they're doing is "optimal" simply because it keeps them getting $$$ --- product quality is just secondary. Their "craftsmanship" is their job-hopping. (I don't have a problem with job-hopping if the products and code are still good --- they usually aren't.)

They usually don't need to care about a bridge lasting 6 decades, but then they're writing critical software for infrastructure or airplanes and, unfortunately, they can actively resist a lot of the hard learned lessons people had to make in those industries because they just want to move fast (and leave after ~2 years).

The culture isn't there yet.

It's my failure as a writer, because this is not one of those articles.

OP is about how I thought I had the answers in the past but was wrong, and how I have new answers and am still wrong in ways I will find out about. So what beggars belief for me is anyone reading it and thinking I'm offering any sort of advice for others in all situations. What here gives you a sense it's at all related to professional environments? My first bullet was, "building for others is hard so don't even try." If you have ideas for what I can reword to make it even clearer, definitely let me know.

This philosophy does not scale beyond one person and said person having recent, intimate, memory of all decisions encoded in source code (current or historical). Furthermore, given intimate implementation knowledge, verifying any change by definition must be performed manually.

As a one-man programming team, you are correct. And quite frankly, I shudder to think of not programming with a test suite or version control, even though I work alone!

Docs, tests, and version control reduce what I have to remember about the code context. Yes, I have to remember the details of the code in front of me, but if I document it, test it, and check it in with a good commit message describing the why and how and whatever, then I can discard that code from my memory and move on to the next thing.

This philosophy does not scale beyond one person ... having recent, intimate, memory of all decisions encoded in source code

Some time ago on HN, I ran across a tale of someone who never merged code unless they'd written it all that day. If they got to the end of the day without something mergeable, well, that just meant they didn't understand the problem well enough to express it in under a day, and they tried afresh the following morning.

Anyone else remember this, or am I confusing sites/anecdotes again?

Seems to intersect with my experience. The best guys I've worked with had test...to some extend...especially in places that did some work you could easily get wrong by not thinking about a small edge case. Yet, none of them had or pursued 100% coverage as they were all clearly aware of that there is no actual benefit in that number, but that it can also mean harm by heavily slowing down dev speed and tying down your feature set because you're too lazy to always port some useless tests.

Our field is burdened by complexity. Some people cannot function properly without illuding themself they can tame it. So they cling to rules, best practices, tools hoping that adopting them to the letter will protect them from the uncertainties of our job.

I've seen the opposite too, devs not only not writing any test, but not trying to run a single line of the code they wrote. Reason being I cannot test all the edge cases so I won't test it at all. QA will open a bug. And somehow getting praised by management for being faster than others to ship changes.

I've always been a programmer. Because it was good enough for Dijkstra.

Looks fine to me. TLS 1.3 with a cert from Let's Encrypt.

I do have SSL. It's just optional and it seems the submitter chose http.

Plus there's so many good reasons to have tests in a single person project

* Hotwiring if statements with "true ||" to go straight to the feature you're building takes time, and you're gonna have to tear it down later. Just build a test and run it, that way you get to keep it for regression testing

* If you're shipping something big, or slow, (which can just mean 'I use qt' sometimes) and launching the app/building the app takes ages, just make a test. A single test loads quicker and runs quicker

* If you're debugging and reproducing the bug takes 45 seconds, just write a test. It automates away the most boring part of the job, keeps your flow going, allows you to check the status of the bug as often as you want without having to think about if it's worth it or not, and, same as #1, you get to keep the test for regression testing

I favorited your comment, thank you: https://news.ycombinator.com/favorites?id=akkartik&comments=...

I think a major source of the problem is academia. I’m an external examiner for CS students in Denmark, and they are basically still taught the OOP and onion architecture way of building abstractions up front. Which is basically one of the worst mantras in software development. What is even worse is that they are taught these things to a religious degree.

What is weird to me is that there is has been a lot of good progression in how professionals write software over the years. As you state, abstractions aren’t inherently bad for everything. I can’t imagine not having some sort of base class containing “updated”, “updated_by” and so on for classic data which ends up in a SQL db. But in general I’ll almost never write an abstraction unless I’m absolutely forced to do so. Yet in academia they are still teaching the exact same curriculum that I was taught 25 years ago.

It’s so weird to sit there and grade their ability to build these wild abstractions in their fancy UML and then implement them in code. Knowing that like 90% of them are never going to see a single UML diagram ever again. At least if they work in my little area of the world. It is what it is though.

The only reason I started to _actually_ use git was magit. I wish there were command line level "porcelains" for everything. A standard '--help=ui' output and 'dialog' style interface and it could be automatic.

It's not so much being overwhelmed by the complexity, it's just that there's a limit to the amount of active muscle memory I can utilize, and I have to make the cut somewhere.

I really appreciate[1] the concrete example. Worth more than my opinion in OP and everybody's opinions in this thread put together.

[1] https://news.ycombinator.com/favorites?id=akkartik&comments=...

Thank you so much, you made my day.

1. It's only a modicum of assurance.

2. There are many ways to get a modicum of assurance. Types, tests, formal methods, cleanroom software engineering, NASA's IV&V, many others that I'm sure I'm forgetting.

So there are many ways to "know if your shit works" and none of them support turning off one's brain entirely (for the part beyond the "modicum"). What I did here is to explore some of the other approaches that I have long neglected.

Me too!

https://github.com/akkartik/mu

https://github.com/akkartik/mu1

https://akkartik.name/post/tracing-tests

If you are writing tests but have no users then you are wasting your time and money.

If you have users but are not writing tests, then your users are your tests and you are wasting their time and money.

However, they should be thrown away immediately after proving your coded logic matches business requirements as they are slow and lose value and become tech debt quickly.

Can you expand on why integration tests should be thrown away once validated? Isn't the idea that when you make a change later, these tests will ensure you haven't introduced a regression?

The important task for you, now that llms write code, is to know the theory very well and have list of things to try out. The good thing about coding is we have very fast and tight feedback loop. You should be in a position to cross-question llm responses and that is possible only when you know your stuff.

https://x.com/jdnoc/status/1791145173524545874