Quick, useful programming learnings?

From a Quora question: What can I learn right now in just 10 minutes that could be useful for the rest of my programming career?

This was an excellent answer that focuses on planning for code vs. jumping right in. I learned this working with my son on his Scratch game. When it had a bug, I had to steer him back to the storyboard, then back to diagnosing the problem.

Answer by Jeff Darcy:

That programming is about solving problems, not writing code.  Here are the four basic tasks that an individual programmer must perform.

  1. Define the problem (requirements and constraints).
  2. Define the solution (algorithms and data structures).
  3. Express the solution in code.
  4. Prove and/or test correctness.

A lot of people get really good at #3 because it’s by far the easiest, but never master the other parts and as a result remain mediocre programmers at best.  Often a good programmer can solve a problem without writing any code at all, by using their knowledge and experience to avoid a problem or find solutions that don’t require new code.  In a team, an experienced programmer can often contribute most by helping people with the other non-coding tasks, including a vast array of tasks and skills that don’t even come into play for an individual working alone (and were thus left off the list for the sake of brevity).

Once you’re proficient in using the tools of your trade, further expertise comes from understanding a particular problem domain other than programming.  It might be something serious like physics or medicine.  It might be something venal like ad targeting or high-frequency training.  It might be something frivolous like games.  You might switch specialties several times during your career.  In any case, being a great programmer means applying the technologies and techniques at hand to some goal other than programming itself.

 

Our relocation project — capabilities vs. specs

As we planned our relocation, we started to search for houses using a set of “features and functions” that closely matched our current house. They were all pretty typical specs: bedrooms, baths, square feet, lot size, schools, age of house, etc.

This approach was useful when narrowing neighborhoods, but they didn’t surface the house we ended up choosing here in Evansville. The house we chose fulfilled the capabilities we wanted from our new house, even though it didn’t exactly match the specs we used to benchmark houses.

For example, our new house’s lot is about half the size of our old lot. However, it does give us the “lot-driven” capabilities that we require — privacy (house faces into a small cul de sac and has nice mature trees around it) and a large, fenced yard space — even though it didn’t match some key yard requirements we thought we had.

For me, it was a useful reminder not to confuse the capabilities one expects from a project with product/solution specifications. In this case, what appeared to be a clear-cut, “must have” requirement of “lot must be over x square feet” would have been better expressed as “lot must be private and have a large, dog-friendly fenced area.”

More importantly, the square footage specification was just that, a specification, not the requirement or capability itself. Specs must serve the capability, not vice versa.

%d bloggers like this: