uuid:
  - value: 53afa754-c4c0-4a31-81ed-5ed4fa9aab77
langcode:
  - value: en
type:
  - target_id: daily_email
    target_type: node_type
    target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7
revision_timestamp:
  - value: '2025-05-11T09:00:51+00:00'
revision_uid:
  - target_type: user
    target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
revision_log: {  }
status:
  - value: true
uid:
  - target_type: user
    target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
title:
  - value: |
      Plan, then code
created:
  - value: '2022-11-25T00:00:00+00:00'
changed:
  - value: '2025-05-11T09:00:51+00:00'
promote:
  - value: false
sticky:
  - value: false
default_langcode:
  - value: true
revision_translation_affected:
  - value: true
path:
  - alias: /daily/2022/11/25/plan-then-code
    langcode: en
body:
  - value: |
      <p>Recently I <a href="https://twitter.com/OneJKMolina/status/1303047499238776832">saw this tweet</a> in a screenshot on a LinkedIn post.</p>

      <p>The post was about improving business writing, but the original tweet was about software engineering.</p>

      <p>For me, the main sentence within the tweet is, "Resist the urge to do something before having a plan." - or as the LinkedIn post said, "Resist the urge to start typing before having a plan.".</p>

      <p>This is something that I've focused on a lot over the last few years, always asking, "What problem are we trying to solve?" and using flow charts and ADRs or technical design documents to come up with a plan before starting to write any code.</p>

      <p>Doing this makes me think of and answer as much as possible upfront - what we need, how things should work, the required steps, and what edge cases and pitfalls there might be. I'll usually have two or three solutions I'll consider and document, as well as which I decided to use and why.</p>

      <p>Once I've planned the solution, coding is usually very fast and straightforward, as most or all questions should already have been answered. I don't need to stop and answer questions whilst writing the code, and the code should be cleaner as I'm coding to the plan rather than figuring it out as I go.</p>

              
    format: full_html
    processed: |
      <p>Recently I <a href="https://twitter.com/OneJKMolina/status/1303047499238776832">saw this tweet</a> in a screenshot on a LinkedIn post.</p>

      <p>The post was about improving business writing, but the original tweet was about software engineering.</p>

      <p>For me, the main sentence within the tweet is, "Resist the urge to do something before having a plan." - or as the LinkedIn post said, "Resist the urge to start typing before having a plan.".</p>

      <p>This is something that I've focused on a lot over the last few years, always asking, "What problem are we trying to solve?" and using flow charts and ADRs or technical design documents to come up with a plan before starting to write any code.</p>

      <p>Doing this makes me think of and answer as much as possible upfront - what we need, how things should work, the required steps, and what edge cases and pitfalls there might be. I'll usually have two or three solutions I'll consider and document, as well as which I decided to use and why.</p>

      <p>Once I've planned the solution, coding is usually very fast and straightforward, as most or all questions should already have been answered. I don't need to stop and answer questions whilst writing the code, and the code should be cleaner as I'm coding to the plan rather than figuring it out as I go.</p>

              
    summary: null
field_daily_email_cta: {  }