[edw519]

I'm now a business/systems analyst...

I hate to break the news to you, but you describe yourself with a job title that's pretty much exclusive to the enterprise world. For the most part, start-ups don't really have a place for "business/system analysts". Let me explain...

School of Thought A: Call it SDLC (Systems Development Life Cycle), the project approach, or the waterfall approach goes something like this: Define a need, conduct analysis to answer the question "What", conduct design to answer the question "How", program, test, program, test, compare to the Functional Specs from the Analysis Phase, conduct User Acceptance Testing, promote, deploy, repeat anything as required. The more rigorous the documentation and project management, the better.

School of Thought B: Build something ASAP. Get it out there ASAP. Get feedback ASAP. Iterate indefinitely.

For the most part (I'm sure there are many counter-examples), enterprises employ School of Thought A and Start-Ups employ School of Thought B. There simply isn't a need for systems analysis in School of Thought B. By the time you're done analyzing, someone else is servicing the customers you wanted.

My advice: Combine a love for building stuff with your love of systems analysis. They go perfectly together. In fact, we now have a name for that: "programmer/analyst".

The systems analyst who can code is a better systems analyst because he can test/evaluate his ideas.

The programmer who can conduct analysis is a better programmer because he knows what to work on.

This may not be what you wanted to hear, but you're in a perfect position to do both, so do it.

[confusalyst]

This is exactly as I suspected, so thank you for confirming this.

"The systems analyst who can code is a better systems analyst because he can test/evaluate his ideas." This is something I have found from my personal experience and I'm glad I had that background. It truly has helped. Anyone reading this can count this as solid advice.

Moving into programmer/analyst territory is something I've considered only briefly and I'll look at it in greater detail. By brushing up on my dormant programming skills I guess the worst that'll happen is I'll become better at my current job. Never a bad thing.

[d_mcgraw]

I'm a programmer/analyst at a startup. It is a fun job. I'm always jumping between tasks and have a million things going on all at once. For me, the job is ~70% programming, ~25% analysis, ~5% other. That will certainly very depending on the company and responsibilities, but thats probably a good model of the work from what I've seen. If thats your cup of tea (sure is mine) then I would say this would be a great way to go. There are downfalls though; if you go the startup route that is. More then likely you will be making less then corporate and the hours may be more erratic to, but that depends on corporate culture. I would say give it a shot if your curious.

[DaveChild]

How would suggest a programmer improve his analysis skills?

[edw519]

There's always "old faithful":

http://www.amazon.com/Structured-Analysis-System-Specificati...

It's expensive and dated, but it covers the fundamentals as well as anything else. A programmer who has never conducted systems analysis ought to absorb this stuff like a sponge.

I followed these concepts for years in enterprises where they served me very well. But now I'm a bigger proponent of iterative prototyping, so I'm not sure how applicable they are. Then again, nothing wrong with a little fundamentals.