GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE
  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Conversation

Notices

  1. Embed this notice
    Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:43 JST Evan Hahn 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/

    In conversation about a year ago from bigshoulders.city permalink

    Attachments

    1. Domain not in remote thumbnail source whitelist: evanhahn.com
      The lone developer problem
      If a single programmer builds something, it can be hard for others to maintain later.
    • Embed this notice
      Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:44 JST Evan Hahn 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!)

      In conversation about a year ago permalink
    • Embed this notice
      Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:45 JST Evan Hahn 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.

      In conversation about a year ago permalink
    • Embed this notice
      Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:46 JST Evan Hahn 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.

      In conversation about a year ago permalink
    • Embed this notice
      Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:48 JST Evan Hahn 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/

      In conversation about a year ago permalink

      Attachments

      1. No result found on File_thumbnail lookup.
        Learn X in Y Minutes: Scenic Programming Language Tours
    • Embed this notice
      Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:49 JST Evan Hahn 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

      In conversation about a year ago permalink

      Attachments

      1. No result found on File_thumbnail lookup.
        Don’t use booleans | LUU.IO
    • Embed this notice
      Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:50 JST Evan Hahn 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.

      In conversation about a year ago permalink
    • Embed this notice
      Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:51 JST Evan Hahn 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!)

      In conversation about a year ago permalink
    • Embed this notice
      Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:52 JST Evan Hahn 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.

      In conversation about a year ago permalink
    • Embed this notice
      Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:53 JST Evan Hahn 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.

      In conversation about a year ago permalink
    • Embed this notice
      Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:54 JST Evan Hahn Evan Hahn
      in reply to

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

      In conversation about a year ago permalink

      Attachments

      1. No result found on File_thumbnail lookup.
        Testability = Modularity
        from Massimo Nazaria
        This article shows how modularity and testability are strongly related by explaining how testability issues imply modularity issues.
    • Embed this notice
      Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:55 JST Evan Hahn 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

      In conversation about a year ago permalink

      Attachments

      1. Domain not in remote thumbnail source whitelist: kevinmahoney.co.uk
        My Principles for Building Software
        from Kevin Mahoney
        These are my personal principles for building software.
    • Embed this notice
      Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:56 JST Evan Hahn 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/

      In conversation about a year ago permalink

      Attachments

      1. Domain not in remote thumbnail source whitelist: res.infoq.com
        Simple Made Easy
        Rich Hickey emphasizes simplicity’s virtues over easiness’, showing that while many choose easiness they may end up with complexity, and the better way is to choose easiness along the simplicity path.
    • Embed this notice
      Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:57 JST Evan Hahn 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.

      In conversation about a year ago permalink
    • Embed this notice
      Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:58 JST Evan Hahn Evan Hahn
      in reply to

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

      In conversation about a year ago permalink
    • Embed this notice
      Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:44:59 JST Evan Hahn 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/

      In conversation about a year ago permalink

      Attachments

      1. No result found on File_thumbnail lookup.
        Throw away your first draft of your code | nicole@web
    • Embed this notice
      Evan Hahn (evanhahn@bigshoulders.city)'s status on Wednesday, 03-Jul-2024 06:45:00 JST Evan Hahn 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.

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

      My programming beliefs as of July 2024: 🧵

      In conversation about a year ago permalink

Feeds

  • Activity Streams
  • RSS 2.0
  • Atom
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.