Problem Solving Strategies: Small Incremental Changes

(Previous: More Than a Hobby: Programming as a Job)

Word Ladder from

For most software developers, being able to learn and adapt on the job is critical for success. Most of the tutorials and documentation I use for learning teach one small thing at a time: how to use .map in JavaScript, or how to create forms in html, or how to get data using AJAX calls, to name a few pretty standard skills.

But as a developer, I’m usually given a user-centered goal (“show our customers the relevant sections of their personal records based on which input buttons they press”) rather than a learning goal, which means putting multiple skills together in a much more complex way than tutorials usually cover. My boss is not going to be impressed with my awesome coding skills, even if I learned a lot, unless my skills make it easier for us to deliver the product that our customer wants, in the way that we promised.

It’s easy to get overwhelmed if you try to solve everything that will be involved in a development project all at once, so I find it helpful to break it down into small, doable pieces (also a good interviewing strategy, by the way).

Breaking down web development problems reminds me of a “word ladder” game that I used to play as an English teacher: given two words, can you get from one word to the other by changing only one letter at a time, where every transition word is also a word? For example: Can you change “tree” to “fled” in two moves?*

Similarly, when given a web development project that is really complex, I find it helpful to start with a working piece of code, perhaps copied from another part of the same project or from StackOverflow, then break it down into smaller, doable pieces that move me toward my specific project goal–just like changing one letter at a time in the word ladder game.

Given an existing, already-bootstrapped site of some sort, and a request like the one above (“show our customers the relevant sections of their personal records based on which input buttons they press”) , I tend to ask myself questions like:

  1. What is already in place in this project that is doing something similar? So if there is already a section of our site that is getting information from a database, how could I duplicate that section and modify the database call to get a different set of information?
  2. What steps do I need to get from what I know how to do, to my desired outcome? If I can change what information I’m getting from my project database, then I still have to worry about a lot of other intermediate steps. First, coming from the customer, how will I get the information about what data to get from the database? Do I need a series of buttons and toggle switches, or a form with input boxes, or something else? Then, given that I can get the customer input to produce the correct data from the database, how do I want to visualize it? Is there an existing template or framework built into the site that I can modify, or do I need to come up with something from scratch? I also need to consider privacy (make sure this is the right person’s information!) and edge cases/incorrect input cases (what if they misspell their name? Or ask for something that doesn’t exist?).
  3. How can I get from each step to the next one, without breaking the project? If I can just connect the dots from one step to the next, I’ll get to my goal. But sometimes each step is only visible once the previous one is solved. That’s why I like to break down tasks into what I can accomplish in a 4-6 hour block of time. Every 4-6 hours I can hopefully check off something from my list and reevaluate to see if I’m still on the right path to solving this problem, or if I need to modify my list of steps. (This is also a version of agile development, which is a way that a lot of developer teams work together).

In time, it gets easier to see the patterns connecting big problems and big solutions without taking time to deliberately plot out a path like this. But when you’re starting out, or overwhelmed, or stuck, starting from similar working code and then breaking a problem down into manageable, small increments is a good tool to have in your tool belt.

(Next: Engineering Q&A)


*My solution: tree => free => flee => fled


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s