• Activity
  • Votes
  • Comments
  • New
  • All activity
  • Showing only topics with the tag "quality". Back to normal view
    1. I've taken the leap from reddit

      Firstly, I'd like to dismiss any claims of pandering or fishing here. I need to say this and I need to write it out. I was a reddit user for 8 years. I thought it was 5 but another commenter...

      Firstly, I'd like to dismiss any claims of pandering or fishing here. I need to say this and I need to write it out.

      I was a reddit user for 8 years. I thought it was 5 but another commenter reminded me what it was. It put me into a bit of a reflective mood. I thought about some of the more meaningful insightful interactions I've had, and some of the more bitterly memorable ones where I was at best annoyed but more recently feeling attacked, shot down, rudely treated. It was profound as a sensitive human being to receive these things, to be made to feel through text, written for you by someone else. These weren't friends, people you held at arms length as you got to know them, they were complete strangers. And these people could be brutal. Make you feel so small. And yet I am a grown man, this environment I spent easily 30% of my waking time on for the best part of a decade was interacting with people and how much I enjoyed it. It was more than a website it was a place that I called home during bouts of depression, social drought and personal hardships. I found myself seeking help and for the most part finding it.

      I have learned something valuable that I want to share here and I had to learn it the hard way, through hypocrisy, through mistakes, through mis-spoken words and harsh tongue thrashings both ways. I have realised for the first time that the people reading these things, the people writing them, the sentiments involved and the content/context is important. They are real, they are human, they feel, they are like me.

      We are seeking some assembly, some community, some lectern from which to state our case. My whole life I looked for togetherness online and thought I found it in the early days of reddit. That is gone now. Even intelligent well thought out research style posts cannot culminate properly, they do not ascend, the public discourse is dead. I see now first hand the destruction of community the facebook exec spoke about. Our actual confident, open, readily invited opinionated perspectives are being replaced by circle jerks and shallow agree/disagree type statements. Upvotes have become likes. Now I see how it is broken.

      Someone saw me having a meltdown and invited me here. I was told it was invite only, and that it was made by someone who had the same feelings as me. I don't want to be surrounded by likeminded people, thats not what I joined reddit for. I joined because open and honest perspectives based on experience were readily available; academics, workers, parents, billionaires, could just shoot-the-shit they didn't need to cite sources or write something popular. But upvotes were reserved for contributors, not jesters or people ridiculing/attacking/berating others. The reddit bandwagon has become savagely toxic in many respects. It is (sorry was) frustrating.

      So here I am. Fresh off the boats as a reddit refugee. I hope than I can find my place here and contribute to the discussions, help build the site, build something that hopefully cannot be corrupted by growth, investors and advertisers.

      We discussed in the hundred or comments attached to my meltdown that the lowering average age of the site population and possible the general dumbing down of internet users happening the past 10 years was largely responsible. I can imagine previously mentioned factors also drove it over the cliff. What is the current hope for Tildes future? I read the announcement post and it mentioned that a baseline level of activity will ensure that topics cycle regularly and user engagement is high enough to stimulate people coming back. Or that is at least what I think the baseline is for.

      I hope this topic starts a discussion and doesn't get moderated away. But the lack of real debate, insight, coupled with a responsive and welcoming attitude is something the whole internet is missing right now, this is where we could make a positive change to the current online environment.

      40 votes
    2. I have a friend with a secret.

      hey you, reading the text sample on the homepage. open this. read the whole thing. god i remember why i write when im drunk. i'm back #bishop babyyyyyyyyyy i've got a little friend with an even...

      hey you, reading the text sample on the homepage. open this. read the whole thing.

      god i remember why i write when im drunk. i'm back
      #bishop babyyyyyyyyyy

      i've got a little friend
      with an even smaller secret
      she entrusted it in me
      and i don't know if i can keep it.
      i've got a little friend
      who told me a little secret
      it's the best i've ever heard
      my god i wish i could relive it


      she asked me
      do you trust me?
      as rain poured down on the window

      .

      i replied honey
      would you hurt me?
      'course not, i didn't think so.

      .

      and we laid back
      here it fades black
      a few things i can't tell you.

      .

      you'd be angry
      try to stop me
      don't wanna know what things came to

      .

      but we laid there
      sipping night air
      as the rain fell, room was candlelit

      .

      she felt a little-bittle afraid.
      are you okay?
      i promise you i can handle it.

      .

      she laid back, she said alright
      i hope that you're right
      don't wanna send you scrambling

      .

      then she got close,
      told me a secret
      my god i felt outstanding


      i've got a little friend
      with an even smaller secret
      she entrusted it in me
      and i don't know if i can keep it.
      i've got a little friend
      who told me a little secret
      it's the best i've ever heard
      my god i wish i could relive it

      (oh my god)

      i've got a little friend
      with an even smaller secret
      she trusted me with it, by-
      god i can barely believe it
      i've got a little friend
      with an itty-bitty secret
      god i never knew that
      i would come to need it


      then she made me promise
      that i wouldn't go and spread
      the word about my findings

      .

      said she'd be upset with me
      and told me all these nasty things
      about what she would do to me

      .

      i gotta tan baby with
      a little white secret
      ......can you believe it

      ....
      ....
      ..my god i can't believe it

      .

      .

      WHISPERS IN THE DARK

      WERE NEVER MEANT TO BE A PLAYGROUND

      NOW YOU WENT AND GOT IT BAD

      WENT POKEMON AND WHITED OUT

      YOU GOT A GOOD FRIEND

      SHE GAVE YOU A SECRET

      I'VE NEVER MET SOMEBODY WEAKER

      HOW THE HELL COULDN'T YOU KEEP IT


      i've got a little friend
      with an even smaller secret
      she entrusted it in me
      and i don't know if i can keep it.
      i've got a little friend
      who told me a little secret
      it's the best i've ever heard
      my god i wish i could relive it

      .

      i dont know why i even try to write sober lmao.i cant wait to move to a legal state and just stay crossfaded 24/7.

      imagine the shit i'll come up with.

      making my own music. putting my heart in the lyivs, actually being able to record.

      you lot might actually be able to hear one of these "peoms" put to music

      14 votes
    3. Reflections on past lessons regarding code quality.

      Preface Over the last couple of years, I've had the opportunity to learn from the mistakes of my predecessors and put those lessons into practice. Among those lessons, three have stood out to me...

      Preface

      Over the last couple of years, I've had the opportunity to learn from the mistakes of my predecessors and put those lessons into practice. Among those lessons, three have stood out to me in particular:

      1. Consistency is king.
      2. Try not to be too clever for your own good.
      3. Good code takes time.

      I know that there are a lot of new and aspiring programmers here (and I'm admittedly far from being a guru myself), so I thought it would be good to touch on these three lessons, what they mean, and why they're so important.


      Consistency is King

      This is something that I had drilled into my head over nearly two years working on the code base at my previous job. Not by my fellow programmers (who did not exist), nor by my boss, but by the code itself.

      Consistency can mean a number of things, but there are two primary points that matter:

      1. Syntactic consistency.
      2. Architectural consistency.

      Syntactic consistency concerns standards in what your code looks like. For example, the choice between snake_case or camelCase or PascalCase for naming; function parameter order; or even something as benign as what kind of indentation and how much of it you use.

      Architectural consistency concerns standards in how you structure your code. Making sure that you either use public class properties or getter and setter methods; using multiple booleans or using bitmasks; using or not using objects for encapsulating data to be passed around; validating data within the primary object or relegating that responsibility to a validator class; and other seemingly minor decisions about how you handle certain behavior make a big difference.

      The code base I maintained had no such consistency. You could never remember whether the method you needed to call was named using snake_case or camelCase and had to perform several searches just to find it. Worse still, some methods defined to handle Ajax calls were prefixed with ajax while many weren't. Argument ordering seemed to be determined by a coin flip, and indentation seemed to vary between 2-space, 3-space, 4-space, and even 5-space indentation depending on what mood my predecessor was in at the time. You often could not tell where a function's body began and where it ended. Writing code was an exercise both in problem solving and in deciphering ancient religious texts.

      Architecturally it was no better. There was no standardization in how data was validated or sanitized, how class members were accessed or modified, how functionality was inherited, whether the functionality was encapsulated in an object method or in a function, or which objects were responsible for which behavior.

      That lack of consistency makes introducing or modifying a small feature, a task which should ordinarily be a breeze, an engineering feat of its own. Often you end up implementing that feature, after dancing around the tangled mess of spaghetti, only to find that the functionality that you implemented already existed somewhere else in the code base but was hiding out in a deep, dark corner that you never even knew was there until you had to fix some other broken feature months later and happened to stumble across it.

      Consistency means predictability, and predictability means discoverability and, more importantly, easier changes and higher confidence in those changes.


      Cleverness is a Fallacy

      In any given project, it can be tempting to do something that saves you extra lines of code, or saves on CPU cycles, or just looks awesome and does something nobody would have thought of before. As human beings and especially as craftsmen, we like to leave our mark and take pride in breaking the status quo by taking a novel and interesting approach to a problem. It can make us feel fulfilled in our work, that we've done something unique, a trademark of sorts.

      The problem with that is that it directly conflicts with the aforementioned consistency and predictability. What ends up being an engineering wonder to you ends up being an engineering nightmare to someone else. While you're enjoying the houses you build with wall studs arranged in the shape of a spider's web, the home remodelers who come along later aren't even sure if they can change part of the structure without causing the entire wall to collapse, and they're not even sure which walls are load-bearing and which aren't, so they're basically playing Jenga while blindfolded.

      The code base I maintained had a few such gems, with what looked like load-bearing walls but were actually made of papier-mâché and were only decorative in nature, and the occasional spider's web wall studs. One spider's web comes to mind in particular. It's been a while since I've worked on that piece of code, so I can't recall what exactly it did, but two query-constructing pieces of logic had overlapping query structure with the difference being the operators and data. Rather than being smart and allowing those two constructs to be different, however, my predecessor decided to be clever and the query construction was abstracted into a separate method so that the same general query structure could be used in other places (note: it never was, and was only ever used in those two instances). It was abstracted so that all original context was lost and no comments existed to explain any of it. On top of that, the method was being called from the most critical piece of the system which, unfortunately, was already a convoluted mess and desperately required a rewrite and thus required me to understand what the hell that method was even doing (incidentally, I fell in love with whiteboards as a result).

      When you feel like you're being clever, you should always stop what you're doing and make sure that what you're doing isn't actually a really terrible idea. Cleverness doesn't exist. Knowledge and intelligence do. Write intelligent code, not clever code.


      Good Code Takes Time

      Bad code more often than not is the result of impatience. We don't like to plan out the solution before we get to writing code. We like to use variables like x and temp in order to quickly achieve functional correctness of our code because stopping to think about how to name them is just additional overhead getting in the way. We don't like to scrap our bad work if we can salvage it in some way instead, because then we have to start from scratch and that's daunting. We continually work against ourselves and gradually increase our mental overhead because we try to decrease our mental overhead. As a result we find ourselves too exhausted by the end of our initial implementations to concern ourselves with fixing obvious problems. Obviously bad but functional code is preferable because we just want the task to be done and over with.

      The more you get exposed to bad code and the more you try to avoid pushing that hell onto yourself and your successors, the more you realize that you need to spend less time coding and more time researching and planning. Whereas you may have been spending upwards of 50% of your time coding previously, suddenly you find yourself spending as little as 10% of your time writing any code at all.

      Professionals from just about any field can tell you that you can either do something right or you can do it twice. You might recognize this most easily in the age-old piece of woodworking wisdom, "measure twice, cut once". The same is true of code, and doing something right means planning how to do it right in the first place before you've even started on the job.


      Putting into Practice

      I've been fortunate over the last couple of months to be able to start on a brand new project and architect it in a way that I see fit. Changes which would ordinarily take days or weeks in the old code base now take me half a day at most, and a matter of minutes at best. I remember where to find a piece of code that I need because I'm consistent and predictable about where I place things; I don't struggle to tell where something begins and where it ends because I'm consistent about structure; I don't continually hate myself when I need to make changes to my code because I don't do anything wildly out of the ordinary; and most importantly, I take my time to figure out what it is that I need to do and how I want to do it before I've written a single line of code.

      When I needed to add a web portal interface for uploading a media asset to associate with a database object, the initial implementation took me a week, due to the need for planning, adding the interface, and supporting and debugging the asset management. When I needed to extended that interface to allow for uploading the same kinds of assets for a completely different object type, it took me only half an hour, with most of that time being dedicated toward updating a Vue.js component to accept configuration via props rather than working for only the single hard-coded object type. If I need to add a case for any additional object type, it will take me only five minutes.

      That initial week of work for the web interface provided me with cost savings that would not have been feasible otherwise, and that initial week of work would have taken as many as three weeks had I not structured the API to be as consistent as it is now. Every initial lag in implementation is offset heavily by the long-term cost savings of writing good code.


      Technical Debt

      Technical debt is the cost of your code over time. The messier and worse your code gets, the more it costs you to try to change, and those costs only build up. Even good code can accumulate technical debt if the needs for your software have changed and its current architecture isn't compatible with those changes.

      No project is without technical debt. Even my own code, that I've been painstakingly working on for the last couple of months, has technical debt. Odds are a programmer far more experienced than I am will come along and want to scrap everything I've done, and will do a far better job rewriting it.

      That's okay, though. In fact, a certain amount of technical debt is good. If we try to never write any bad code whatsoever, then we could never possibly get to writing any code at all, because there are far too many unknowns for a new project.

      What's important is knowing when to pay down on that technical debt, which could mean anything from paying it up front (i.e. through planning ahead of time) to paying it down when it starts to get too expensive (e.g. refactoring a complicated section of code when changes become sufficiently difficult). That's not something you can learn through a StackOverflow post or a college lecture, and certainly not from some unknown stranger on some relatively unknown website in a long, informal blog-like post.


      Final Thoughts

      I'm far from being a great programmer. There's a lot that I don't know and I still have quite a bit to learn. I love programming, though, and more than that I enjoy sharing the lessons I've learned with others. Especially the ones that I wish I'd learned back in college.

      Please feel free to share your own experiences, learned lessons, and (if you have it) feedback here. I'd love to read up on some other thoughts on this subject!

      21 votes
    4. Moderators of Reddit, tell us about your experiences in fostering quality discussion and content (or failures to do so)

      Since the moderator community here is quite large, I figure we would have quite alot of interesting perspectives over here in Tildes. Feel free to chip in even if you're not a moderator, or god...

      Since the moderator community here is quite large, I figure we would have quite alot of interesting perspectives over here in Tildes. Feel free to chip in even if you're not a moderator, or god forbid, moderate such subs as T_D. Having a range of perspectives is, as always, the most valuable aspect of any discussion.

      Here are some baseline questions to get you started:-

      • Did your subreddit take strict measures to maintain quality ala r/AskHistorians, or was it a karmic free-for-all like r/aww?

      • Do you think the model was an appropriate fit for your sub? Was it successful?

      • What were the challenges faced in trying to maintain a certain quality standard (or not maintaining one at all)?

      • Will any of the lessons learnt on Reddit be applicable here in Tildes?

      29 votes
    5. How often do you go to write a comment or a post online, and after a bit of time spent writing you decide that it is crap and just delete it? Is this a good thing?

      I do this a lot. I did it just now. I wrote about five paragraphs on a topic, deleted it and started over, wrote about five more and did the same thing. Got frustrated. Some thoughts that went...

      I do this a lot. I did it just now. I wrote about five paragraphs on a topic, deleted it and started over, wrote about five more and did the same thing. Got frustrated. Some thoughts that went through my mind:

      • "this is not concise at all. It's disorganized and needs to be re-done"

      • "this is going to trigger an emotional response and that will filter how they read it, so I'll be less likely to get interesting responses"

      • "maybe I should just do this as a journal entry and keep it private"

      • "these thoughts are worth something, and even if they aren't super cogent, maybe they can be a starting point for a collaborative thinking process"

      • "that's dumb, nobody cares about my ramblings anyway. everyone has thoughts like this, mine aren't more important"

      • etc.

      So what usually ends up happening in instances like this is I just don't post. Other times, I get wrapped up in trying to make a post super-high quality and it comes across as over-produced... and if I've somehow triggered an emotional response then that aspect becomes an avenue for attack.

      Does anyone else experience something comparable to this? Is it a good thing for helping to maintain quality content and discussions? If not, what are strategies to improve situations like these?

      25 votes