Sam Morgan is a developer working across the full stack. He's passionate about Software Craftsmanship and education. He works as a coach at Makers Academy in London.

  1. Watch out for the Obvious Answer

    Sometimes problems have obvious solutions. But great innovation requires you to solve things in non-obvious ways: so, you should be careful with obvious solutions, because they rarely lead to effective innovation.

  2. Novice TDD: Race to Green

    'Red, Green, Refactor': that's a helpful mantra for writing your code test-first. But how long should you spend on each stage, and how can you effectively separate each stage from the other? The answer: Make it Work, then Make it Good.

  3. Fitbit is failing on its mission

    Fitbit's mission is to "To empower and inspire you to live a healthier, more active life: designing products and experiences that fit seamlessly into your life so you can achieve your health and fitness goals, whatever they may be." By ignoring multiple requests from the trans community to improve product inclusivity, they are failing their customers and failing on their mission.

  4. Learning to Learn I: the Ready Position

    This post is about a learning Ready Position: a state of mind required for the adoption of new practices. A Ready Position is indispensable, especially when learning new behaviours that are either opposed to current behaviour, or refinements of existing behaviours.

  5. How to be a better ally

    This is a post about how to be a better ally in support of oppressed groups. It uses feminism as the main example.

  6. Thinking about Tim Hunt

    This post comes in pretty late, but it's one that needed some long mulling and even longer feedback. Here are my thoughts on overcoming cultural sexism, wrapped up in an analysis of Tim Hunt's resignation from University College London.

  7. Shovels make me sad

    Ruby's shovel operator is for mutating stuff, right? Except it isn't. The idea that << is an alias for concat() has outstripped its purpose as a bitwise operator, leading to confusion.

  8. TDD is a mindset

    Something I'm very keen on telling students is that Test-Driven Development is not just about initializing RSpec and making sure you've got great coverage. TDD is a mindset that should guide how you articulate and communicate problem spaces, without jumping to solutions too fast.

  9. Testing HTML

    There's no clear route as to how to provide testing hooks in your HTML. Here are my three suggestions for how to mark up HTML for easy testability, in the absence of a component-based framework.

  10. The Team is the thing

    When I asked one of my colleagues what was more important under pressure - the team or shipping the product - he unhesitatingly answered 'the team'. Despite the enormous stresses working as an engineer places on timely delivery, that's a lesson I don't ever want to forget.

  11. Lessons from the CSS coalface

    CSS can be really hard: it's not naturally object-oriented, and it's built for a bygone era of type-only websites. Here are some tips (from a talk I gave at Makers Academy in London) to help intermediate front-end developers avoid spaghetti-ing their CSS on larger projects.

  12. Don't overstretch

    I'm learning the hard way how to avoid overstretching. When you take sole ownership of a project, it's very easy to run ahead and implement a bunch of great stuff - but it's rarely a good idea.

  13. Self-guided learning II: The Knowledge Dimension

    In the previous article, we looked at what Bloom's Taxonomy was and where it is used. We began to look at ways a solid grounding in the taxonomy can help learners to scaffold their own learning (by knowing, given any specific topic, where they are in the taxonomy, and by providing a route to higher levels of proficiency), and how educators and curriculum developers use the taxonomy to craft learning objectives.

  14. Self-guided learning I: Introducing Bloom

    This is a series of articles aimed at both students and educators. In three parts, we look at how Bloom's Taxonomy (1956, revised 2001) can be applied to everyday learning.

  15. Software design up-front: how much?

    A common mistake that people make when trying to design something completely foolproof was to underestimate the ingenuity of complete fools. (Douglas Adams) When starting the process of building software, how much effort should be expended at the beginning? Your answer to this will determine the responsiveness, flexibility, and resource requirements for the duration of the whole project.

  16. What's a Class Structure?

    In Object-Oriented Design, a Class is an entity that holds data (known as the Class state) and ways of manipulating or communicating that data (known as the Class behaviour). A Class Structure is an arrangement of classes that efficiently models the Domain Model.