Ask HN: What are the best programming tricks you know?

I am biased toward over-planning. I have found your approach to work best for work I expect to take several days. In that case, actually putting together a lucidchart / draw.io diagram about what service will get refactored where is a huge help. It also keeps data flowing uni-directionally (yes, compiler will prevent circular dependencies, but there are ways to make code dirty without ever hitting that).

On the other hand, this diagramming does take hours and some people do fine with it. I can also do ok without it, but find it to generally be worth it, especially because I get interrupted all the time, so it's good to have a clear picture of the end goal.

I am on the opposite extreme, I get so wound up designing stuff that I never write any code. I basically force myself to write something even it's imperfect and messy because it can be easily changed. And writing the code helps me understand the problem.

As with all things, moderation is good here.

I guess this really depends on how complicated the problem really is and can you really know everything before you code.

I have very limited memory, so I often write out pseudocode/notes about some properties to help my reasoning. For some problems, I will write scripts to try out some idea, verify my assumptions, while thinking about the problem.

As I have aged, I have done this more and more.

I take inspiration from the famous pianist, Glenn Gould. He would study a piece of music for weeks or more. Taking all kinds of notes, truly studying and understand each measure, etc.. He did all of this without touching a piano.

Once he was satisfied, then he'd play the piece.

OTOH, I find that writing some prototype code is one of the best ways to understand the problem and solution before starting to write the real program.

If you’re worried about lacking the discipline to throw away the prototype, do it in another language.

Hear hear! The generalization of this is figuring out how to prioritize multiple problems. Deciding which problems to solve in what order, and how much time to spend on each, is a difficult and important and never solved problem. But it’s quite valuable to practice and budget your time. This might sound different from understating the problem before coding, but it’s really almost the same thing, taking time to think about the approach carefully before diving in, making sure the requirements will be met, etc. Prioritizing multiple problems is very similar to planning the steps of solving a single problem. Maybe the main difference with the higher level prioritizing is that prioritizing has to be revisited periodically and/or continuously. Working in a software company, this is what the best PMs do really well, they figure out which features and bugs to work on that make the most difference, and they understand when to listen to the programmers and let them refactor things without making public-facing progress, and also when not to.

how do you go about doing this? sometimes you dont know what will go wrong until you try it out and get feedback

iterate, prototype, patch, refine

yep, I use them as a blueprint for what I'm going to write...

I write comments and create lists for what should happen.

As I go through the list, I take the line and place it above the code.

Besides helping me go through things, it also helps anyone that comes in months after to work on it.

Yep, I write comments to figure out what I'm doing, and then the code writes itself. It's gotten to the point where it's hard to code without writing the comment first, and usually the comment gets rewritten multiple times before I write a single line of code (thus saving me rewriting dozens of lines of code multiple times.)

I don't like to do this, I like having an editor setup to highlight the open parent that matches the one you are closing. Then I can confirm that my structure matches my intention.

Wow. Does this have a name?

How do you recover control of the server, if remote?

*Groans*

...OK, after having a bit of a poke around I would respectfully ask for a demonstration/citation of this insanity.

My own experience is that systems that panic get rather warm, which I blindly assumed was because the kernel had entered an infinite loop. This turns out to be the case: https://github.com/torvalds/linux/blob/cbe232ab07ab7a1c7743c...

There are references to interacting with kgdb, booting a crash kernel, and delaying before reboot above the highlighted spot in the previous link. This suggests that panicking is very much a "everything is torn to shreds and never comes back again" event.

Annoyingly I can't SIGKILL, -TERM, or -SEGV `init` easily (PID 1 is special-cased by the kernel), and don't remember exactly how to fire up my kernel initramfs test harness, so I can't properly test this easily at the moment. Am very curious though.

Can’t shell the computer if I break the OS ;)

Uh huh. And when the web server process crashes, how do you restart it?

What? How?

    GET https://example.com/users?postprocess=result.sort("signup-date").reverse

    GET https://example.com/users?sort=signup-date&order=descending

Would you please provide an example or direct towards some explanation? I can't seem to grasp what you mean exactly.

    const playTwinkleTwinkleLittleStar = (piano) => {
      piano.play('c');
      piano.play('c');
      piano.play('g');
      piano.play('g');
      piano.play('a');
      piano.play('a');
      piano.play('g');
    };

    const playItTwicePiano = (piano) => {
      return {
        play: (note) => {
          piano.play(note);
          piano.play(note);
        },
      };
    };

    playTwinkleTwinkleLittleStar(playItTwicePiano(piano));

    const twinkleTwinkleLittleStar = () => {
      return [ 'c', 'c', 'g', 'g', 'a', 'a', 'g' ]; 
    };

    const playItTwice = (sequence) => {
      const xs = [];


      for (const x of sequence) {
        xs.push(x);
        xs.push(x);
      }

      return xs;
    };

    it('should start with c', () => {
      const xs = twinkleTwinkleLittleStar();

      assert(xs[0] === 'c');
    });

I also recommend this! I usually use the error handling of the language of choice for that purpose and implement the entire functionality returning errors/throwing Exceptions for the not implemented parts, and asserting upon in on unit tests to implement each pending functionality. I write the description on the assert message itself.

Edit: example

     use Psr\Http\Message\ResponseInterface;
    use Psr\Http\Message\ServerRequestInterface;

    class TransferHandler extends BaseHandler {

      public function __construct(Generator $faker, DataStorage $storage) {
       parent::__construct($faker, $storage);
      }

      public function handle(ServerRequestInterface $http_request): ResponseInterface {
       $resource_token = $http_request->getHeader('X-Resource-Token')[0];
       $account_id = $this->storage->account_id_by_resource_token[$resource_token];
       if (empty($account_id)) {
        return $this->responseInvalidResourceToken($http_request);
       }

       throw new \Exception('WIP -> store transaction data here for subsequent query, also issue notification');
      }
     }

With the following test:

public function testTransfer() { $juno = JunoAPISimulator::initialize($this->faker); $repo = AccountCreationRepoResolver::resolve();

     $account_id = $this->createAccountAndGetId(
      $this->merchant,
      fn(DigitalAccountRequestOperator $op) => $op->withProvider(DigitalAccountProviderSelector::JUNO())
     );

     try {
      Executor::execute(new IssueTransferByBankDetails(
       $account_id->toHex(),
       "BRL 12.42",
       $_ispb = '21018182',
       $_agencyNumber = '0001',
       $_accountNumber = '10000368021',
       $_accountType = 'CHECKING',
      ));
      $this->fail('should have thrown exception');
     } catch (\Throwable $e) {
      $this->assertEquals('WIP -> store transaction data here for subsequent query, also issue notification', $e->getPrevious()->getMessage());
     }
  }

Somehow reminds me of monad...

btw defunctionalization usually means converting higher order functions into statically known function calls

So much this, really helps breakup complex tasks. Some examples off the top of my head:

If you have a function handling user sign up it often needs to build and write to multiple db tables. Split this into two functions a pure one that outputs the entities, and a second which takes these and handles writing them to a db inside a transaction. First the code is super simple to read, but more importantly it's easy to unit test since you don't need to mock anything, just make a list of input combinations paired with a list of expected outputs. Spend more time testing your business logic, less time verifying that postgres is working.

Transforming HTML into a pdf is trivial if you first iterate over the html and output a list of instructions that then get fed into a writer function one at a time, similar to how 3d printer instructions work.

Anytime I've done analysis work on a state that gets updated by a complex series of events it's always been worthwhile to build a discrete handler for each event type, then feed the events into it like a woodchipper. Complex problem solved with simple functions and a case statement.

+100

I first heard of this in the great Functional Core, Imperative Shell [1] screencast of Destroy All Software. It allows you to easily unit test your functional core (as they're just pure functions).

[1] https://www.destroyallsoftware.com/screencasts/catalog/funct...

Yeah I love this pattern. I'm using it for the data loading for my search engine. Instead of having the code that processes website data insert the data into the database and index directly, it essentially writes a program to a file, which is interpreted later to actually create the desired effects.

Means I can just grab some random subset of the search engine index, copy it over to my workstation, and load it up over there. It's also amazing for testing and inspection.

I'll add this: If you have to deal with state (e.g.: say you write something akin to `git checkout` that should rearrange the file system): Combine this strategy with the question of "can I roll this step back?".

I.e. for a checkout:

- Make a temporary folder on the target disk (rollback: delete it)

- Create new files for those you have to change (rollback: delete them)

- Fill these files with their target content

- Move old files away into the temp folder

- Move new files into place

- If everything worked, delete the leftovers (the only thing that can't be rolled back)

Your disk fills up during checkout? Roll back!

You're on Windows and some file is blocked by another process? Roll back!

…etc. :)

Can you give an example of this?

Great book indeed. By Henry S. Warren, ISBN 0-321-84268-5.

Another classic book, a bit less down to the metal than Hacker's Delight (which deals with bit fiddling a lot):

Programming Pearls by Jon Bentley.

KISS = Keep It Simply Stupid

Great advice! I call that the "Mad Dash" - just try to get something working in a quick and dirty fashion. I often don't understand the problem until I work on the solution.

Interesting how seemingly-at-odds this is from another highly upvoted trick: the one that begins "Understand the problem and solution before coding." Hard to find that balance sometimes between "just dive right in" and perfectionism.

Can you elaborate? This in the context of a message-passing architecture? Or do you mean as callbacks?

Can you give an example?

   function foo() : void {
      doBar();
      if (...) {
       doBaz(12);
      }
   }

   function fooEffects(): Effects[] {
     results = [ { type: 'bar' }]
     if (....) {
       results.push({ type: 'baz', value: 12 })
     }
     return result
   }

   function executeEffects(effects: Effects) {
     if (effects.type === 'bar') {
       ....
     }
     if (effects.type === 'baz') {
       ...
     }   
   }

This is often called defunctionalisation

What you are really saying is that people should develop influencing skills. OP starts by asking about programming tricks, but then mentions career, so it's hard to discern whether they just want some trivia. A programmer learning any soft skill will pay off exponentially in work and their personal life. The payoffs will be much bigger than any technical skill once two years into a career.

We were working on an accelerator board for a graphics system. It had a memory for textures to map onto shapes. The way the microcode was written, it wanted the texture memory to be "rectangular" - you would move the same distance in the source memory and the destination memory to start the next row.

Well, that meant that we had to manage the texture memory as 2D regions, rather than as a 1D linear space. We spent two days thinking about creating a malloc for rectangular blocks. Then we went back and told the microcode people to fix the microcode. I think it was a one-line change for them.

So, yeah. Sometimes it's massively easier to push back on a stupid requirement than it is to implement it.

>do it in more situations than you think you need and always earlier than you think you need.

I can't even count how many this I should just apply that. It's an obvious thing but it takes time to getting used to clearly formulating your problems. Search engines are so sofisticated nowadays that you don't even necessarily need to know what you're looking for and it just pops up. I think of it as a sort of hive mind thing, internet became a natural extension of our brains.

> Get really good at googling

Those moments when you are sitting there trying to figure out how to explain in search engine friendly terms the problem you have.

Being able to use search engines is a definite skill that certainly cannot be understated. Once upon a time we'd have shelves of $100 books to pore over, and that would take time in itself. Being able to use the correct terminology and the correct search engine logic will help in delivering software faster.

@vasco Any tips/resources you would like to share on how to get better at googling?

Reminds me of this quote by Brian W. Kernighan

>Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it

> Write code that is obvious, clearly readable by future programmers maintaining the code

I agree, with the caveat that does not mean low-level/unabstracted/verbose code. Whilst each line of such code might be "obvious" on its own, the big-picture behaviour and inter-dependencies can be difficult to follow across multiple pages.

As an extreme example, machine code is completely "obvious" (e.g. "increment register RAX"), whilst being notoriously hard to follow (often requiring disassemblers, etc.)

> Write code that is obvious, clearly readable by future programmers maintaining the code.

This is something I've come to realise more and more strongly as time's gone by. The code that I write isn't for me, it's for everyone coming after me. Including future-me. Gotta look after future-me.

> Honestly most of the clever things you're about to do, the compiler is already going to do for you, but better and without the bugs you'll introduce when you do it wrong.

I don't think this is actually the case, it's fairly easy to outsmart most compilers. A more honest argument is that it, in most cases, is a bad trade to make the code 3% faster by making it 10x more difficult to read.

Sometimes it is worth that effort, but that's the exception and you need to be able to motivate why it actually makes a difference. Show me a benchmark that demonstrates this is actually much faster (as a whole, not just the method), and then we can talk. "Clever" is in most cases another word for premature optimization.

There are so many things that can be called a "clever trick" that it makes no sense to say that you should not use clever tricks.

Like, one thing that can be called a clever trick is to align the code vertically to make it easier to edit using vertical selections and macros in a text editor. That can actually make the code more readable and maintainable.

Hansen's Second Law: Clever is the opposite of maintainable

There is nothing that will stop a code review quicker than "I discovered a clever way to..." A dozen engineers are going to have to try to reverse engineer your cleverness in order to safely make any change to your code, so you'd better make double-sure that the performance you're buying with your cleverness is worth the total maintenance cost going forward.

There are some times it's worth it (the Fast InvSqrt hack and many others), but most of the time, it's just tickling our intellectual curiosity for our own benefit, and that's a bad trade.

I don't disagree, but it is best if you know the problem already. And it won't change too substantially, in which case you have to rework the code and the tests.

That’s not correct: Equal value isn’t an issue. Having both variables point to the same memory is.

> The biggest problem is when your two values are equal: they'll get zeroed out and good luck tracking that down!

  (a,b) = (5,5)
  a = a ^ b   # a = 0, b = 5
  b = a ^ b   # a = 0, b = 5
  a = a ^ b   # a = 5, b = 5

Hmm?

As I understand it (... haven't tested recently) you're right that it's not usually a win on modern architectures, and the compiler could do it wherever there's enough register pressure that it might actually help (if anywhere). It's still neat, but I don't think there's any reason to be writing it unless you are on a particularly constrained system with a limited compiler.

I assume you're being downvoted for your slightly incorrect caveat.

That's a massive game-changer, I agree. I really like the approach described by my former colleague: https://softwarephilosopher.com/2022/03/07/personal-worklog/ but I haven't manage to fully implement it

Isn't that just a function?

Can you expand on your first trick? What is the problem being solved and what is a practical use case? I'm not sure I follow.

Yeah I heard of people grepping their history file. Ctrl+R is so much faster.

Most of the time I know the starting characters of the command I want, so I use up/down arrow instead of Ctrl+r. You'll need this in `.inputrc`

    # use up and down arrow to match search history based on typed starting text
    "\e[A": history-search-backward
    "\e[B": history-search-forward

And for the rest of us :)

https://readline.kablamo.org/vi.html

Generic Utility Types are beautiful!! https://www.typescriptlang.org/docs/handbook/utility-types.h...

I miss working with TS, it's just so much superior to old JS.