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.

 

PM Quote of the Day — Anatole France

To accomplish great things, we must not only act, but also dream; not only plan, but also believe.

Glen Alleman’s Mission to the Agilests

Dont I look like I should be the patron of desperate situations?

Don't I look like I should be the patron of desperate situations?

I don’t know why I think of Glen’s efforts to reconcile agilests and PMs in religious terms. Maybe it’s because many in both camps see topics as either/or — either you’re with us or against us. Or maybe I worry that it’s a hopeless cause (which is why St. Jude graces this post).

There’s not much I can add to Glen’s latest: If I’m Doing Project Management Right am I Agile?  To me, this question is not either/or, it’s both. The worst misconceptions are around planning (especially the schedule), per Glen’s comments on the Agile Manifesto tenet”Responding to change over following the plan”:

The notion that plans (schedules actually) are developed and then fixed is nonsense on any practical project. There are no doubt projects where this is the case. But it’s still nonsense. Anyone suggesting this is good project management practice is either selling you a bridge or seriously misinformed about how projects are managed.

Plans – the strategy for the successful completion of the project, and the schedule – the sequence of work needed to fulfill the strategy are subject to change for every imaginable reason.

PM Quote of the Day — Abraham Lincoln

Give me six hours to chop down a tree and I will spend the first four sharpening the axe.

This quote is useful to counter colleagues who disparage planning in general. It is, however, important to remember that initiating and planning activities aren’t for simply “easing into the project” (in the unfortunate phrase of a PM I once worked for). They’re meant to get the project’s execution machine fueled, oiled, and sharpened… and cutting the right tree.

PM Quote of the Day — George S. Patton

A good plan, violently executed now, is better than a perfect plan next week.

This quote is an nice appropriate bookend to yesterday’s Eliot quote (here).  Most SAP projects have to be delivered within a tight time window within strict resource constraints.  With two legs of the triple constraint almost fixed — and we can’t compromise on quality with mission-critical applications — our scope planning and prioritization must be ruthless. 

While it is important to have patience with ourselves and others, dithering about features and functions doesn’t work in today’s project environment.  To slip in another quote: Say what you’ll do, do what you say… and don’t look back.

%d bloggers like this: