Every developer is different.

Some sit and stare until inspiration strikes out of the blue. Some talk over problems and solutions with their colleagues. While still others put on their earbuds and proceed to get biz-zay.

What they all have in common is a process by which they approach their work. Proficiency doesn’t occur by accident; it occurs through a systematic application of your craft.

Why is process important?

Because without process, you can’t predictably project when any given engagement will complete. Without process, there is no reliable and repeatable way to communicate what you will do, how you will do it, or how others will sync up with your work.

Now, whether you call this project management, or methodology, or simply your mojo, it’s all the same – you need a consistent programming practice, a method to your madness.

Test Driven Development. Agile. SCRUM. Waterfall. ITIL. All of these methodologies are designed to wrangle order from chaos, getting teams of developers to have a common purpose and a common meta-language to coordinate their development efforts.

Minor wars have been fought over which methodology is better than all others. But this isn’t a treatise on best processes; only a declaration that process is necessary for proficiency.

What you will find, in actual practice, is that not every programming problem needs or deserves the full brunt of whatever team management process you currently subscribe to.

Sometimes a mix of methodologies is called for to get the job done.

The simple fact is this: over your professional life as a developer, you will learn – and forget – a multitude of technologies, languages, and tools. Mastering the tactical at the expense of the strategic

What will sustain – and prolong – your professional usefulness, is your ability to systematize your approach to your craft, to learn how to learn, and to embrace process.

Go, and be you.