The Chesterton’s fence analogy says that you need to be careful to change things if you don’t understand why things are the way they are, because there may be good reasons you haven’t considered yet. This is broadly good advice in many different contexts, including programming where it can be easy to “fix” some weird code only to discover there was a reason for the weirdness later on when things break. This is Chesterson’s middle finger: # List all commit body content (but not the subject line) % git log --no-merges --format=format:'%b' | sed '/^$/d' | wc -l 295 That’s 295 lines of commit text over the last 13 years. In total. The commit subjects are usually just “fix page A” – even for huge changes – and are pointless. If I manually remove some dependabot, “revert commit”, and “fix typo” commit bodies it’s just 167 lines. That’s about one line a month. There is no other documentation. There are barely any comments in the code. This is Chesterson’s middle finger: “Yes, we did all these weird things and we’re not telling anyone why. Haha fuck you.” This is not the first time I’ve seen a less-than-useful commit log, but it is the first time I’m hired after everyone else left. There is no one to ask. In theory there was a three week handover period from the previous developer, but that was just as communicative as the commit log. Never have I sympathized more with Jack Bauer’s methods to extract information and I regret not employing some of them. There are unfinished refactors. There are left-overs from removed features. There are features that were added but never linked/used but are still in the code. There are features no one seems to be using. Overall it seems to suffer quite badly from Chesterton’s gap (“There isn’t a fence yet? Lets build fences!” without asking if a fence is actually needed). Everything is just a big fat middle finger. Writing well is hard. Writing something vaguely passable is not. By and large there are three questions to answer: “What are you changing?”, “why are you changing it?”, and “why is this a good solution?” Sometimes “Implement new feature X” is enough, although it’s rare there is nothing more to say – most of the time there is something to say about how/why it’s added as it is. If you’re fixing a bug, refactoring or changing things, or making some other substantial change then it’s very rare there isn’t at least a paragraph or two to comment on the “what’s changing, why change it, and why is this good?” questions. Writing this is not an optional extra; it’s part of the job. If you’re not doing it then you’re not doing your job as a software developer. It doesn’t need to be eloquent. It doesn’t need to be perfect English. It doesn’t need to be a comprehensive essay on the nature of reality. It’s okay to forget something (although better if you don’t). It just needs … something. Any half-way serious attempt will be infinitely better than nothing at all. If you do nothing at all then you’re just giving everyone after you the finger. Other Programming posts22 Feb 2021 Go is not an easy language 7 Jan 2019 Testing isn’t everything 16 Nov 2024 Against best practices 29 Nov 2020 Stupid light software 22 Mar 2019 Easy means easy to debug 10 Dec 2020 Bitmasks for nicer APIs 25 Nov 2020 An API is a user interface 25 Apr 2020 Storing files in .git 5 Dec 2019 Good comments read well and are to the point 4 Sep 2016 YAML: probably not so great after all 7 Oct 2019 On being the right size 7 Feb 2016 The downsides of JSON for config filesOther Workplace posts 18 Feb 2021 Downsides of working remotely
I had a real business conversation over email. Turns out the other side was an AI agent. I kept talking.
Police go directly for the circuit breaker panel to avoid being filmed This post will be in English, because there apparently is a lot of interest in what happened to me yesterday. I'm a libertarian danish privacy activist and former police officer and I have been doing https://t.co/jvs0BJJeBu
Hello world I'm studying statistics and Cs, I have take cs50x, cs50p. Currently take linear algebra and calc 3 (multivariable) to start andrew ML courses, my question is do I need alot to get job in ml I was think maybe should take goggle data analytics to get quick job and let ml journey takes it's time but I don't like that I like math and want studying math but I need money can someone give me advice how get job and still be in path to ml submitted by /u/DevilNeverCryy [link] [Kommentare]
Hey r/robotics, Wanted to share my latest budget mobile robot build. The goal was to keep it under $250, so instead of buying an expensive LiDAR setup or dedicated depth cameras, I rigged up 4 cheap smartphones to stream video data. I’m running the streams through Depth Anything v3 (DA3) to estimate the depth maps, and honestly, for a "poor man's LiDAR," it’s going incredibly strong. The issue I'm running into: Since DA3 outputs relative/monocular depth maps, I’m struggling with absolute scale calibration. Right now, the robot thinks walls are further away than they actually are. It knows where the obstacles are, but the metric distance is skewed because DA3 doesn't have real-world depth data. I want to fix this by adding a hardware sensor to act as a "ground truth" anchor to correct and scale the DA3 depth data in real-time. Has anyone here tried using a ToF (Time-of-Flight) sensor or an Ultrasonic sensor to handle this kind of depth correction? Would a single-point distance reading be enough to dynamically scale the relative map, or is there a better way to do it? If anyone is curious about the hardware or wants to check out the setup, I put the specs and documentation here and the chassis CAD files here. Looking forward to hearing your thoughts on how to fix the depth scaling! submitted by /u/ganacbicnio [link] [Kommentare]
