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.


Maintaining Outsourced Development Quality

Many firms that outsource want to reap all the savings from cutting costs on developers without accounting for the additional overhead they’ll need to manage developers who aren’t right down the hall. All the informal code reviews, requirements clarification, etc. that was done real-time and face-to-face must be made explicit and conducted remotely…often across multiple time zones. Furthermore, the project management performed by the outsourcing company is done for the benefit of the outsourcing company, not one’s own firm.

This overhead can only be ameliorated a bit with tools and technique: there is effort inherent in making inarticulate or tacit knowledge explicit. My heuristic is to add from between 25 and 33 percent more project management effort (beyond the typical in-house estimate range) to such projects.

From my comment on a long-standing LinkedIn post, this one on outsourcing QA.

Krigsman’s 2012 trends: three quick takes

The always valuable Michael Krigsman (@mkrigsman, IT failures blog here) weighs in with a 2012 prediction: that rapid implementation will get more sustained focus.  I believe that there has been considerable progress over the years in improving both ERP implementations and ERP sustainability (see here for a bit of the bad old days).  However, there’s room for further improvement, especially in achieving consistent success.  Here’s my quick take on the three initiatives Michael highlighted:

%d bloggers like this: