IT Renaissance (wo)Man

So we recently "hired" another analyst (translation: do it all dude) for the optimization group I work in. He comes in with a good "can do" attitude, but his development/programming/technical background is weak.

I was asked to think about how I'd train such a person. So I took a deep breath and a long, hard look (at least 10 minutes) at what knowledge someone would need to be successful.

You may agree with this list, decry it for it's obvious development bent, or wonder why I included so many articles from Joel on Software. Simple: IT is software, and Joel has an uncanny insight into general corporate insanity. Plus he's fun to read, and education should be fun. Or at least not put you to sleep.

So without furthur ado..(adieu? adoo? achoo?) an edited paste of the document I sent in for review.:

Optimization Analyst Training Regimen
aka: “Indoctrinating New Analysts the realist Way”

This is a BRAINSTORMING document. It is in NO WAY intended to be final, comprehensive, objective, or otherwise representing the opinion of anyone other than it’s author.

Objective
To make the object of training perfect in every way. At least in my limited and completely biased opinion.

Seriously.

Ok, not really. What we’re REALLY looking to do is our collective best to give you the opportunity to learn/experience/widen your horizons. We’re looking to build an IT Renaissance (wo)Man. Someone who has a little knowledge about a lot of things, and a lot of knowledge about at least 2-3 things. Above all, you’ll have the ability to communicate effectively, efficiently, and effusively. Or something like that.

There are those who will question the obvious emphasis on software development. The reason is simple – IT is nothing but software. At it’s core, we are responsible for the care, feeding, creation, maintenance of software.

Additionally, understanding the environment (people, project teams, politics) in which that software resides is crucial. The stereotypical computer geek may grok’s the code, but is mystified when it comes to dealing with the human element.

Good luck. May you know that you know what you know.

Subjects

• MS networking (domain, AD)


• Tcp-ip/internet networking infrastructcure


• ‘nix sys admin


• Ms net admin


• Troubleshooting


• PC/computer architecture

General programming/development best practices

• Source code control


• Daily builds/auto builds


• Unit testing frameworks


• Design patterns


• Specs/requirements


• Eliciting specs/requirements from customers


• What makes a good spec?


• QA/testing

Language learning
We’ll pick one initially. Choice will be based on fundamental usability, ease of ramp-up, scalability, and (let’s be honest) marketability.

We will NOT choose a language simply because it’s the buzzword-du-jour

Possible candidates:

• C


• Perl


• Php


• Ruby on Rails


• C#


• VC.net


• VB.net


• Java

Methods (ie, how we’re going to get the training done)

• Web tutorials


• Rccd reading (below)


• MCSE curricula


• Redhat cert. curricula


• Tail network ops for a week or two


• spend time with developers



• 1 hr programming class/ 3x per week


• 2 hrs study 3x/week



• Identify a real need (small scale) and implement a solution while “eating our own dogfood” (dev/documentation/requirements gathering/source code practices)

Reading:

Books:
Peopleware - Productive Projects and Teams, 2nd Ed. - Tom Demarco

Getting
Things Done: The Art of Stress-Free Productivity - David Allen

The
Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition
- Frederick P. Brooks

User
Interface Design for Programmers - Joel Spolsky

Head
First Design Patterns - Elisabeth Freeman

The Best Software Writing I: Selected and Introduced by Joel Spolsky - Joel Spolsky

Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity - Joel Spolsky



Websites:

Joel On Software - General Cluefulness:
Command and Conquer and the Herd of Coconuts Mar 23 2000
Human Task Switches Considered Harmful Feb 12 2001
Hard-assed Bug Fixin' Jul 31 2001
Painless Software Schedules Mar 29 2000
The Joel Test: 12 Steps to Better Code Aug 09 2000
Painless Functional Specifications - Part 1: Why Bother? Oct 02 2000

Painless Functional Specifications - Part 2: What's a Spec? Oct 03 2000

Painless Functional Specifications - Part 3: But... How? Oct 04 2000

Painless Functional Specifications - Part 4: Tips Oct 15 2000
Top Five (Wrong) Reasons You Don't Have Testers Apr 30 2000
Up the tata without a tutu Dec 02 2000
Getting Things Done When You're Only a Grunt Dec 25 2001
The Guerrilla Guide to Interviewing Mar 23 2000
Daily Builds Are Your Friend Jan 27 2001



Daily skimmers

General geek thought: www.slashdot.org
Of QA, requirements, and men: www.stickyminds.com
General development: www.secretgeek.com
General development: www.codesnipers.com
Development in general: www.joelonsoftware.com
INFOSEC http://blogs.ittoolbox.com/security/investigator/