fsebugoutzone.org:9999

       Posts by EvanHahn@bigshoulders.city
 (DIR) Post #AjX6F1YxRS3hS8i1PE by EvanHahn@bigshoulders.city
       2024-07-02T20:52:26Z
       
       0 likes, 0 repeats
       
       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/
       
 (DIR) Post #AjX6F2NeOyblzMQVQ8 by EvanHahn@bigshoulders.city
       2024-07-02T20:52:26Z
       
       0 likes, 0 repeats
       
       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
       
 (DIR) Post #AjX6F36JiuKyDtKB2e by EvanHahn@bigshoulders.city
       2024-07-02T20:52:27Z
       
       0 likes, 0 repeats
       
       Testability = modularity. See https://massimo-nazaria.github.io/testability-modularity.html
       
 (DIR) Post #AjX6F3oz2q4ASQDqfA by EvanHahn@bigshoulders.city
       2024-07-02T20:52:27Z
       
       0 likes, 1 repeats
       
       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.
       
 (DIR) Post #AjX6F5k5tzLMPpwyJs by EvanHahn@bigshoulders.city
       2024-07-02T20:52:28Z
       
       0 likes, 0 repeats
       
       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.
       
 (DIR) Post #AjX6PggxNcDBuMXF8y by EvanHahn@bigshoulders.city
       2024-07-02T20:52:28Z
       
       0 likes, 0 repeats
       
       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!)
       
 (DIR) Post #AjX6PhROaxMIEOGKWm by EvanHahn@bigshoulders.city
       2024-07-02T20:52:28Z
       
       0 likes, 0 repeats
       
       Avoid renaming identifiers. If I have a variable like photo_id, call it photo_id everywhere, even if id might make sense in context.
       
 (DIR) Post #AjX6PiDFj1dicoeY7c by EvanHahn@bigshoulders.city
       2024-07-02T20:52:28Z
       
       0 likes, 0 repeats
       
       Consider an enum instead of a boolean. They can be clearer and more extensible. See https://www.luu.io/posts/dont-use-booleans
       
 (DIR) Post #AjX6Piwd0Jw4tXsmqe by EvanHahn@bigshoulders.city
       2024-07-02T20:52:29Z
       
       0 likes, 0 repeats
       
       “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/
       
 (DIR) Post #AjX6PjdAS9xn1Tml9c by EvanHahn@bigshoulders.city
       2024-07-02T20:52:29Z
       
       0 likes, 0 repeats
       
       HTTP status codes aren’t worth fussing over. There&#39;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.
       
 (DIR) Post #AjX6PkF6B8Iwv7X3HE by EvanHahn@bigshoulders.city
       2024-07-02T20:52:29Z
       
       0 likes, 0 repeats
       
       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.
       
 (DIR) Post #AjX6Pkm4CYfyZMxNfE by EvanHahn@bigshoulders.city
       2024-07-02T20:52:30Z
       
       0 likes, 0 repeats
       
       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!)
       
 (DIR) Post #AjX6PlK6A1tkGusYi0 by EvanHahn@bigshoulders.city
       2024-07-02T20:52:30Z
       
       0 likes, 0 repeats
       
       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/
       
 (DIR) Post #AjX6Plq0FPQ1rro2RE by EvanHahn@bigshoulders.city
       2024-07-02T20:52:30Z
       
       0 likes, 0 repeats
       
       Simple opinions tend to be wrong. For example, some people say things like, “PHP sucks!”…but PHP powers most of the internet, and modern PHP has a bunch of great features. People who are dogmatic about process, like TDD, tend to be right in some situations but wrong in others. I usually like working with programmers who use nuance and understand tradeoffs, and I try to be that programmer myself.
       
 (DIR) Post #AjX6PmXFec0u202Zqi by EvanHahn@bigshoulders.city
       2024-07-02T20:52:31Z
       
       0 likes, 0 repeats
       
       Everything is more complicated than you expect. I need to be careful not to trivialize someone’s work, because it’s probably a lot harder than I think. Building a prototype is a lot easier than building something production-grade.
       
 (DIR) Post #AjX6PnD595TS7jbz3A by EvanHahn@bigshoulders.city
       2024-07-02T20:52:31Z
       
       0 likes, 0 repeats
       
       The most important problems are non-technical. “Real world” issues tend to be the most important. Am I building something that helps people, or hurts them? Is my team healthy?
       
 (DIR) Post #AjX6PnrqhW5GAAgXaq by EvanHahn@bigshoulders.city
       2024-07-02T20:52:31Z
       
       0 likes, 0 repeats
       
       Typing new code tends to be the easiest part of the job. Bigger challenges: reading code, prioritization, communication, team dynamics, etc.
       
 (DIR) Post #AjX6PoaW1RoSOhaDDM by EvanHahn@bigshoulders.city
       2024-07-02T20:52:31Z
       
       0 likes, 0 repeats
       
       Making useless stuff can be a great way to learn new things. Not everything needs to be productive, but sometimes it can be anyway! For example, I spent a bunch of time writing a custom PNG encoder for a side project. I never thought it’d be useful. But then a few months later, I needed to write some code to detect animated PNG data for work, and it was trivial to write because I knew exactly how to do it.
       
 (DIR) Post #AjX6PpIpMhG4c8JbHc by EvanHahn@bigshoulders.city
       2024-07-02T20:52:32Z
       
       0 likes, 0 repeats
       
       It matters who I build for. Humanity is in trouble. An incomplete list of problems: climate change; war; authoritarianism; genocide; poverty; inequality; surveillance. I shouldn’t waste my time building software for people who are hurting people. I shouldn’t waste my time building software to make the boss rich, even if I’m the boss. There are a lot of jobs where I can use my skills to help people…I should work there if I can!
       
 (DIR) Post #AjX6Pq2ubM7av3sP7A by EvanHahn@bigshoulders.city
       2024-07-02T20:52:32Z
       
       0 likes, 0 repeats
       
       I wonder if I’ll still believe these things next year, or in ten…but that’s what I believe as of July 2024.