3 ms·

Don't be afraid to show your thoughts when asked to. The best developers are those that can express their thoughts clearly at any stage throughout their process

• InfinityByTen 4mo ago
  One of my professors in undergrad said: the most dangerous mathematicians are the ones that begin the proof with "Consider a case ...". He said that these mathematicians are the ones who don't share anything about how they got the case and they end up projecting this sort of "magician aura". I don't know how accurate that assessment it, but I think it captures something that never sat well with me. In my life, I've never liked people who deliberately polish up their articulation to the level that it obfuscates how they arrived at that understanding (whether it's academics or engineers). They might not do it for attention and they might not be doing it knowingly. IMO, they are taking away the opportunity of learning from the people they are talking to. For me the conversation is one sided. I'm there to listen, but rarely can I ask questions, give feedback or grow from where they have possibly reached.
  • ozim 4mo ago
    Ugh, let's take a step back and make a distinction: I don't need your fluff. No one cares how you arrived writing another crud line to save an object to database or sent yet another AJAX call. If you wrote some genuine great compression algorithm that's a different take on compression, I would like to see step by step reasoning and eventual dead ends.
    • InfinityByTen 4mo ago
      I shared my thoughts in the context of someone saying that one should be able to share your line of thinking when asked to. Whether "when one asked to" applies to keystroke by keystroke blockhained versioning isn't my point of discussion. I get it, that the overall discussion is about DeltaDB. I'd say interesting concept to toy with. I'd pay more attention to "micro commits" as the idea more than the keylogger.
    • hinkley 4mo ago
      I think a good argument ad absurdum for this is to look at how some recipe sites give the entire genealogical history of the author and an anecdote about how their gammy met Theodore Roosevelt and he stole her pen. Three pages later I discover I need to go to the grocery store because the recipe requires sour cream. And the store is closed so I need a different recipe. Don't fucking do that. Do something way less than halfway to that line.
      • jimbokun 4mo ago
        Agree on the software case. Disagree about the recipes. Food writing is its own genre where the recipe is one part of a larger story. Can often include travel stories as well. Maybe not your thing. But definitely has its place.
        • hinkley 4mo ago
          Can we agree that this flavor of recipe writing should not be applied to software? That's the point I was going for (hence the ad absurdum header)
      • deleted 4mo ago
        [deleted]
    • 8note 4mo ago
      why this particular object though? why didn't you add these three other parameters to it? how does this default value make sense when unset? mostly things that end up not-in-the-commit that 3 years from now people are gonna wonder about is really handy to know
      • jimbokun 4mo ago
        I strongly doubt that.
  • jcgrillo 4mo ago
    OTOH polishing up the presentation can really improve the experience of a first-time reader of the work (e.g. your code reviewers). If the polishing is done with good intent and proficiency you can make something that was very convoluted and difficult to arrive at digestible with far less effort. It also aids your own understanding: "If we can reduce it to the freshman level that means we really understand it" (or similar I didn't look up the exact quote, attributed to Feynman). If you're polishing something up to make it understandable that's totally different than polishing it up to make yourself seem smart, right?
    • InfinityByTen 4mo ago
      Oh, I *love* those kind of people who take the time to _simplify_ and draw meaningful insights from their first draft. They take the time to ensure that they are not just putting out thoughts for the heck of it. They have gone through a learning journey and they are letting you step on it. They might even make the effort to actually articulate their intuition: "it seemed like a good idea to toy with this, because such and such usually have some connection". Maybe this is the mathematician's lament rejigged. And I have held it for probably 20 years of my life. I try to do things differently when I write, but I have to say there are enough people who find it sub-standard. It's too imprecise or ambiguous or not clear enough for their taste. They aren't wrong. But I'm not done learning and I start building my thoughts as I go along.
  • ablob 4mo ago
    I personally stumble upon many topics where I only care about the what. In that case all the theory is just a distraction I'm just wading through to get to the point. If it's optional, then looking into the how and why is certainly nice, but it should be part of an appendix or a commentary and not interspersed within the proof unless an uncommented version exists.
  • hinkley 4mo ago
    "So I was thinking about #####'s Law this morning, and I realized that #######'s Theorem might apply if we do this and ignore that. Then I went up a blind alley and stopped for coffee and realized I was overcomplicating it, we don't care about negative or imaginary solutions." They don't need to know I was brushing my teeth and thinking of bacon and an argument I had with my spouse right before I thought that though. Or how rude the customer in front of me was to the new barista who was just trying her best.
    • rdedev 4mo ago
      The example I had was of Ramanujam. "It was revealed to me in a dream"
      • hinkley 4mo ago
        I love that man, and I hate that man. For many of the reasons already listed in this thread. He is smarter than Feynman, but also dumber than Feynman.
• hinkley 4mo ago
  Nobody needs to know quite how messy the process of making the sausage is though. There are steps that provide information, even about how the bugs got in there. But not every thought needs to be expressed.
  • aeonik 4mo ago
    Disagree. This how people best learn from each other. It's also nice to audit your own thought process objectively. It makes one vulnerable though, that's for sure. Psychologically I mean.
    • hinkley 4mo ago
      Whether you realize it or not, you're insisting all the neurodivergent people at your job unmask themselves, and fuck that noise.
      • aeonik 4mo ago
        I'm nuerodivergent, I dream of a world where not only can they unmask, but that normal folk will see the intricate chaotic beauty behind it. Probably a pipe dream though. But for sure I don't want to force it on people. Don't use the feature if you don't want to, I'm all about freedom of choice. Just saying the upside to it.
        • hinkley 4mo ago
          So I want to be clear that I'm not destroying other people's ability to learn from me. I just don't tell the entire story in the code, but I'm open about it if you talk to me. It's not a long conversation to figure me out. If it was I'd consider that a failure to do my job properly. I know I'm done with a module when people add features to it the way I would have done so. That sounds like a non-statement, but I bet if you watch your projects closely, you'll see that's often not the case and sometimes it's laughably bad. It goes along with Knuth's thing about code meant to be read by humans and incidentally by computers, and also Kernighan's Law. My code eventually just says exactly what it does. And I don't use the same noun to mean three different things in three different places. Why? Because then I can take my name off of the bus number list and pick something else up. This module that I wrote is Steve's baby now, and that one is David's. In fact taking it over is how David got promoted.
• MaulingMonkey 4mo ago
  I don't want the private API key I temporarily hardcoded in my public history. Nor do I want the drag of worrying about so much as sneezing in the general vicinity of a secret in my editor window, when I already self review before commit. I don't want the unkind rant about a coworker's design as I attempt to figure out what they were smoking when they made the thing I'm trying to use, needlessly offending them. For starters, once it clicks, it might all make sense, and have turned out to be my mistake. For another, even if a rant is warranted, a pass for "tact", or at least limiting the blame to the blame that is warranted, is proper. I don't want to drag a coworker through my chain of confusion until I've made an appropriate amount of effort to unconfuse myself first. To do otherwise is likely to bring us both to confusion, possibly in different ways, possibly including confusion about what we're confused about, which is just a mess and dead weight. There's a time and place to explain and teach, and a time and place to expose my own confusion and ask for help, but neither is step 1. Even if the API is undocumented and confusing, even if you're expected to ask for help as step 1, there's value in a fresh set of eyes getting a feel for exactly how the API is confusing before that, thus informing directions for potential improvement (be that API changes or improved documentation.)
  • gmueckl 4mo ago
    I'm not advocating committing secrets to version control. But you can learn to phrase your WTFs about your colleague's code politely and constructively. I would even argue that this an absolutely basic skill for professionals. It typically leads to faster and better answers whenever a discussion arises. Even if confusion seems to spread in a discussion, I would expect the person who realizes this first to call that out and and to reset the conversation. There is nothing magic or onerous about this.
    • palata 4mo ago
      > But you can learn to phrase your WTFs about your colleague's code politely and constructively. I see a fundamental difference between thoughts and whatever words I pronounce. You're saying "you should share your thoughts", and I disagree. My thoughts are mine. Whenever I want to share something with the world, I phrase it and share the result of that process.