Conversation

Notices

1. Embed this notice
   Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:43 JST Evan Hahn

   in reply to

   The “lone developer” problem: when a single programmer builds something, it’s often hard for others to maintain later. This seems to affect everyone, myself included. See https://evanhahn.com/the-lone-developer-problem/

   • Embed this notice
     Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:44 JST Evan Hahn

     in reply to

     Tweaking my setup has limited benefits. It’s really fun to customize my dotfiles, pick the perfect editor, and tweak my dev setup. But I don’t think it’s a huge time saver. There are some great tools that have helped, and tinkering can be a great way to learn about how things work. But choosing the right colorscheme isn’t usually productive, and I haven’t observed a correlation between “good programmer” and “cares a lot about their editor”. (…it’s still fun, though, and I do it a lot!)

   • Embed this notice
     Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:45 JST Evan Hahn

     in reply to

     Try using the tools I already have before reaching for new ones. Instead of installing a fancy Zsh package, see if I can set $PROMPT and be happy. Instead of installing a dependency, see if the standard library has something similar.

   • Embed this notice
     Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:46 JST Evan Hahn

     in reply to

     HTTP status codes aren’t worth fussing over. There's usually an obvious choice. Some distinctions are useful, but others are not. If it takes more than a minute to pick the status code, I worry.

   • Embed this notice
     Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:48 JST Evan Hahn

     in reply to

     “Learn X in Y minutes” is a great resource for quickly learning the basics of programming languages (and a few other things). See https://learnxinyminutes.com/

   • Embed this notice
     Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:49 JST Evan Hahn

     in reply to

     Consider an enum instead of a boolean. They can be clearer and more extensible. See https://www.luu.io/posts/dont-use-booleans

   • Embed this notice
     Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:50 JST Evan Hahn

     in reply to

     Avoid renaming identifiers. If I have a variable like photo_id, call it photo_id everywhere, even if id might make sense in context.

   • Embed this notice
     Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:51 JST Evan Hahn

     in reply to

     Use the positive version of a variable. Variables like use_widget are better than skip_widget because they help avoid confusing double-negatives. (I’ve seen this confusion cause a significant security bug!)

   • Embed this notice
     Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:52 JST Evan Hahn

     in reply to

     There are lots of ways to document my code. Some ideas: explicit documentation; good names for functions and variables; breaking up code sections into named functions; comments; log messages.

   • Embed this notice
     Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:53 JST Evan Hahn

     in reply to

     The functional programming people can be quite smug, but they’re often right. It’s harder to do a good job with object-oriented programming, and easier to do a good job with functions that operate on immutable data.

   • Embed this notice
     Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:54 JST Evan Hahn

     in reply to

     Testability = modularity. See https://massimo-nazaria.github.io/testability-modularity.html

   • Embed this notice
     Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:55 JST Evan Hahn

     in reply to

     Make invalid states unrepresentable. If I can design my data/types to prevent invalid states, that eliminates a large source of bugs. A little pain with the type system or database schema is usually worth it. See https://kevinmahoney.co.uk/articles/my-principles-for-building-software/#make-invalid-states-unrepresentable

   • Embed this notice
     Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:56 JST Evan Hahn

     in reply to

     The distinction between “simple” and “easy” is important. Simple is the opposite of complex. Easy is something else; it’s familiar. Understanding this distinction has helped me develop simpler software (though I still have a ways to go on this front). See https://www.infoq.com/presentations/Simple-Made-Easy/

   • Embed this notice
     Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:57 JST Evan Hahn

     in reply to

     When presented with a difficult task, I ask myself: “what if I didn’t do this at all?”. Most of the time, this is a stupid question, and I have to do the thing. But ~5% of the time, I realize that I can completely skip some work.

   • Embed this notice
     Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:58 JST Evan Hahn

     in reply to

     If I’m banging my head against a problem without making progress, I should take a break.

   • Embed this notice
     Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:59 JST Evan Hahn

     in reply to

     Do a “spike”. Sometimes, I try implementing a feature in the smallest possible amount of time, with awful code, horrible hacks, and lots of TODOs. Once I have something working, I clean it up. I’ve found this to be a useful way to see where the challenges lie, and a pretty good way to build things quickly. See https://ntietz.com/blog/throw-away-your-first-draft/

   • Embed this notice
     Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:45:00 JST Evan Hahn

     in reply to

     Different approaches for different tasks, teams, and projects. For example, it would be irresponsible to build a pacemaker with no automated tests; people could get hurt! But it would also be wrong to stress about automated tests during a weekend game jam. “Good code” means different things in different contexts, and I need to tailor my approach to the problem at hand.

   • Embed this notice
     Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:45:01 JST Evan Hahn

     My programming beliefs as of July 2024: 🧵