Software engineers spend a lot of time "in a code environment" for various reasons (along with time writing design documents etc, of course). How much attention do you pay do how you spend this time? Do you think and act the same way when diagnosing a problem as when fixing it? How about when you're writing a prototype vs when you're writing a production feature? Does hobby coding feel like professional coding? In this talk, Jon will reflect on how he thinks when coding – not as a directive for you to do the same thing, but as an example of how you might think about coding, encouraging you to reflect on your own practices. What works really well? Which practices are "nice to have" and which ones are crucial, leading to real problems if you ignore them? Expect to have more questions than answers by the end of the session - but questions that you'll need to ask yourself and your team.

2. Warning: purely speculative!
• I basically don’t know cognitive stuff
• Felienne Hermans does know about all of this:
https://www.manning.com/books/the-programmers-brain
• Somewhat different focus from this talk, but a wonderful
book
• Disclaimer: I wrote the foreword, and I’m a huge fan of
Felienne’s talk “Programming Is Writing Is Programming”
• And no, I don’t follow every idea verbatim all the time

3. Context matters
• Mostly described in terms of collaborative work (open
source or commercial)
• “Just for fun projects” can still benefit
• Some artifacts are different (e.g. commit directly instead
of PR)
• Discipline is harder!
• “Explore” mode may be all you need to scratch the itch

4. Disclaimer: we’re all different!
• This talk isn’t “how you should think when coding”
• It describes how I think I think, and encourages you to reflect too.
• It works for me. At least, it seems to.
• Think about how you think. Or at least how you think you
think.
• Neurodiversity is real. Don’t impose your thought process on
others.

5. The big idea: different modes
• Learn
• Explore
• Understand
• Fix
• Enhance
• Clean up

6. Lots of non-coding tasks too!
• Design docs (writing and reviewing)
• Code review
• Release chores
• Meetings
• … out of scope for this talk

7. What constitutes a “mode”?
• Goal
• Best practices
• Thought processes (this might be too grand a title…)
• Artifacts

8. Why bother thinking about modes at all?
• Clean commits
• Avoiding distractions
• Keep a queue of other tasks to avoid too much context
switching within a task
• Explore different kinds of context switching…
• Sense of achievement
• Communication of what you’re doing

9. Learn mode (1)
• Goal: investigate a new protocol, language feature etc
• “Best practices”
• Start very simple and go slow
• Use an environment you’re comfortable in (console apps
for me)
• Easy to get overwhelmed: keep notes on extra bits to
learn about
• Find good resources (ideally official ones) – bookmark
them!

10. Learn mode (2)
• Thought processes
• What is this resource trying to teach me?
• What do I want to learn about?
• Will I miss out if I skip some “irrelevant” fundamentals?
• How can I check I’ve understood this?
• Artifacts
• “Throw-away” code (but keep it!)
• Maybe notes
• Bookmarks

11. Explore mode (1)
• Note: unsure quite how different this is from “learn”
• Goal: spiking code to explore different avenues (or perhaps
reverse engineering etc)
• Best practices
• Frequent validation where possible
• Keep everything so you can come back to it
• If an approach doesn’t work, keep a note of why
• Don’t worry about “production code” quality – but do think about
naming, comments etc.
• Write tests if and only if they help with the goal

12. Explore mode (2)
• Thought processes
• What might the production code eventually look like?
• What are the big bits of architecture?
• How quickly can I get to something that’s clunky but
useful?
• Artifacts
• Lots of grungy code you don’t want anyone else to see
• Some of which works, some of which doesn’t
• Copious informal notes

13. Understand mode (1)
• Goal: dive deeply into the existing behaviour of a system
• Common contexts: fixing a bug, working in a new code base
• Best practices
• Very careful note-taking (lots of copy paste of output)
• Sometimes interactive debugging
• Sometimes writing tests
• Sometimes transferring code to a simpler context

14. Understand mode (2)
• Thought processes
• As few assumptions as possible
• Trying to gain confidence: situation X always fails, situation Y
always works etc
• Isolation: reduce to minimal example in easy-to-work-with context
• Artifacts
• Notes document
• (Sometimes) Concise bug report or repro on another bug report
• (Sometimes) New tests to help describe the flow

15. Fix mode (1)
• Goal: fix a single defect
• Best practices
• Write a failing test first (result of “understand” step)
• Don’t fix other bugs!
• Thought processes
• Minimal change… without introducing new issues
• Actively look for other issues in the same area
• Fine line between “this is the same” and “nope, file new bug”

16. Fix mode (2)
• Artifacts
• (Ideal) Pull request fixing bug (with a test)
• (Sometimes) Design doc with options for how to fix
• (Sometimes) New bugs reported
• Variant: fixed in same PR, but different commits

17. Enhance mode (1)
• Goal: implement a single feature / piece of string
• Best practices
• Consider timing of refactoring (see later…)
• Even one feature can have multiple commits
• Try to avoid TODOs (but life is short…)
• Tests
• Fit and finish: copyright, comments, formatting etc

18. Enhance mode (2)
• Thought process:
• Have I explored enough?
• Do I know what I’m building?
• Will I know when I’m done (for now)?
• What’s the quality bar, and testing bar?
• Artifacts:
• Single PR (per repo) with high-quality code
• Up-to-date requirements doc with any changes

19. Clean up mode (1)
• Goal: Make the code a more pleasant environment in which
to work
• Best practices:
• Don’t fix bugs
• Don’t implement features
• Consider multiple commits, e.g. one for formatting, one
for actual refactoring
• “Thought-free” vs “Requires thought” changes
• “Thought” is both implementing and reviewing

20. Clean up mode (2)
• Thought process:
• What have I noticed before and been tempted to change
then-and-there?
• If I see an issue in one place, where else might it crop up?
• Pattern matching and the rule of three
• Artifacts:
• Cleaner codebase 

21. Questions? Comments?
Discussion? Feedback?