16 ms·

Because Coding is not Working. Coding is not Planning. Coding is not Being Efficient. Coding is not Accomplishing Goals. Coding is not Saving Money. Coding is n

• sanderjd 6y ago
  Yep, the answer to this question for me is pretty much always "because I'm communicating", followed closely by "because I'm reading". Coordination and research are a bigger and more important part of my job than coding (which is also important).
• oneplane 6y ago
  It's possible the question is meant as "in the context of wanting to code and having something to code, what is impeding your desire and goal to code at the moment?".
• serial_dev 6y ago
  Good point, happened to me today. The UI requirements to my ticket didn't make sense. The changes the other dev wanted would have took us possible days. I was hesitant to start, so I asked another dev... He said something totally different, he kept referring to something the designer wanted, but it didn't make sense to me, either. I called the designer and she told me she never said that and we agreed on something else. After confirming with another dev in chat that the designer was right, I could start coding. In the end, after 20 minutes of calls/chat and around 30 minutes coding, the issue was resolved. I saved so much time (days, really) just by being a bit sceptical. I'm new on the team, so first I thought it is just me who can't follow everything, then asked around and realized that the level of miscommunication is shocking and people don't even realize that they don't understand things and act like everything is trivially simple (the team looks good, though).
  • jonpurdy 6y ago
    You are 100% correct. This is why Acceptance Criteria are a thing: so the person working on the ticket knows exactly what it means to be "Done". If they're unclear, they must be made clear (by questioning as you did). Often, unclear description or Acceptance Criteria means that the ticket hasn't been though out properly and needs to be clarified (or scrapped).
    • zikzak 6y ago
      Many of the process improvements we have made where I am over the last ten years boil down to "ok, stop, does this still make sense?" at each hand off. It helps that we make data driven decisions so the stakeholders know what they need rather than "yeah, can you make me a button that doubles or revenue?"
    • btschaegg 6y ago
      Not to dismiss your point, but I'd like to add that simply adding an "acceptance criteria" section to all tasks also isn't a solution. I've just recently encountered a ticket from a certain person that does this all the time. The problem is that their criteria still only describe the solutions they imagined themselves, which are often… very suboptimal. In the end, what you want is someone who is capable and willing to properly root cause a problem and weigh multiple possible solutions against each other. If nobody does this, no amount of superficial process will help you.
  • BurningFrog 6y ago
    Keep communicating with everyone, and you may lead this team in 6 months.
    • capableweb 6y ago
      Well, make sure that's actually wanted before jumping into assumptions. I had the misfortune of assuming people want to communicate more in order to avoid miscommunication but it turned out that the team (~5 developers in a ~15 person company) actually wanted more walls around them, minimize communication and focus on silo'd development (one frontend, one backend, one ios, one android and one infrastructure with 0 sharing of tasks even if one was behind/in front) with as little communication between devs and others in the company as possible. Only the person dedicated for communication should do the communication. I didn't agree with this so I no longer work there, but there was a few months of pain because I assumed everyone wanted to communicate but didn't have the experience/tools/processes to do so. I was wrong, which took time to discover as I assumed everyone wanted agile collaboration.
• rootlocus 6y ago
  > Because Coding is not Working Then what is it?
  • a3n 6y ago
    It's necessary but not sufficient.
    • contravariant 6y ago
      And arguably it's best when it's done as little as possible.
      • swader999 6y ago
        I write better non-trivial code when I get up and get away from the screen for a while. Go do something else to get my mind off it. Even sleep on it. Then the insights creep in. Hammering away at a hard problem usually makes a big mess. Sometimes three quarters of my time is spent understanding the requirements, negotiating the solution, researching, talking through the design.
        • leesalminen 6y ago
          Same here! Sometimes I’ve spent weeks thinking through a problem fully, talking to everyone involved (including myself) only to code whatever it was in a couple hours. It’s amazing what our brains can process subconsciously.
          • swader999 6y ago
            Related to this, I typically advocate for the daily stand-up close to mid day so that more work gets time to "sleep on it" and then a chance to add any insights that came to you during the off time. I seem to do better features and code over two work sessions than in one long continuous day.
          • username90 6y ago
• jariel 6y ago
  Coding can be all of those things if you're doing it right.
• apeace 6y ago
  I think you’re right but that doesn’t mean the questioner is naive or inexperienced. It’s a legitimate question with lots of potential interesting answers.
• ed 6y ago
  If you look at the referenced website, you'll see you're taking the question pretty seriously. To the comic author: I think your work is funny, keep it up!
• bobthechef 6y ago
  Indeed. It's like asking "why aren't you nailing pieces of wood together?" or "why aren't you moving your right bicep?".
• username90 6y ago
  > I am getting paid to get things done in a good manner. If I wanted to have a house built for me, I would not expect to pay somebody and immediately have them start laying bricks without them looking at the land, taking soil samples, sketching up drafts of what the house should look like within the constraints available, and then plan the foundation of which to start building. In the software world most of those would be accomplished by coding though. You code up prototypes, show them to people, ask questions, test performance, test the different dependencies etc. Making a big design up front as you suggest instead of just coding prototypes is naive and wastes time. It is a good way to look productive to management though, I give you that.
  • throwaway789394 6y ago
    Don’t code a prototype!! All your credibility is lost. Get feedback from stakeholders using a mock-up. Iterate on a sketch. Use that to design features, design schemas, break work down and plan deliverables. For the love of god, step away from the IDE
  • sanderjd 6y ago
    I dunno, if one of my team members was constantly coding up non viable prototypes instead of communicating with people, writing up proposed solutions and alternatives, and seeking a bit of consensus first, that would strike me as a much worse waste of time.
    • z92 6y ago
      Prototyping takes less time than writing up the requirement in paper. And customers can give more accurate feedback watching the prototype than reading the docs. It rarely happens that once a prototype is written, the developer finds out it was all a wastage and the customer wanted something quite different. Think of the prototype as a Photoshop mock, but interactive like the real application.
      • slumpt_ 6y ago
        You aren’t writing up UX requirements. You’re writing system designs. If you’ve never had to write down and get feedback on a system design that is entirely okay, but as you work on projects of increasing complexity and scope, it becomes more and more important to plan before you write. The prototypes you’re describing are primarily useful for UX iteration, not system design.
• 29athrowaway 6y ago
  > Because Coding is not Working. Implementation is work. It's a phase in the SDLC. > Coding is not Accomplishing Goals. If the goal of a particular task is defined as a code deliverable, then coding will help you accomplish that goal.
  • lazyasciiart 6y ago
    I think the OP could be better expressed as "coding is not the only kind of Work".
• tailspin2019 6y ago
  > There are many reasons why not doing X is right, including social/mental recovery and prevention of burnout. You suggested the question seems naive, but you’ve also listed plenty of good answers to “why aren’t you coding?” I’m not sure you can attribute naivety to a simple question like this, and I don’t think it’s necessary. It’s just a question. It’s prompted some interesting responses in this thread.
  • avindroth 6y ago
    Interesting how judgment is assumed in this question. A question like “why aren’t you living in Istanbul” feels very neutral, whereas OP’s question can feel like a moral suggestion. Seems unfair to presuppose such things, though especially in a caustic way
    • PeterisP 6y ago
      I'd definitely also treat a question “why aren’t you living in Istanbul” as non-neutral with an implied assertion that in the absence of any specific argument it the natural choice would be to live in Istanbul; it's pretty much the nature of any question in the form "why aren't you doing X".
    • tailspin2019 6y ago
      Agreed. And I’m fascinated by some of the responses to this question, including the post I was responding to. It’s really interesting. I come with my own bias, I’d like to code more, and arguably need to, but don’t always manage the non-coding side of my work in the most optimal way. Really interesting to read everyone’s thoughts.
• chiefalchemist 6y ago
  Solid. Mind if I sum it up? Coding is a means, not an ends. Working hard is easy. Working smart is hard.
  • svatwork 6y ago
    I think you got that backwards. Working hard can become very cumbersome and/or annoying to deal with from a team perspective if you don't align with your team/customers/stakeholders/etc.
• CodeGlitch 6y ago
  Look up "tracer bullets" in the Pragmatic Programmer. Basically you create an end-to-end working system that capture just enough functionality to work, then you show the user and use their feedback to adjust your "aim" for the next version. Rinse and repeat. I've tried this and worked pretty well.
• alkis 6y ago
  This is a bad analogy. Coding is closer to writing a book than building a house. The faster you start hacking prototypes the better. As long as you are ready to throw virtually all of it away. Most of you assumptions during planning are wrong anyway so there is little point in planning too much. The worst thing that happened to coding is business culture with design docs, architecture docs, whatever docs all coming before a prototype is written. This is how you end up with "enterprise grade" garbage. The best way to create a good code base is to write it inside out a few times over. Documents ain't gonna help you.