in reply to Avoiding "brain drain" in the corporate realm
This leaves me in a really interesting position. I get to do Systems Analysis, figuring out what people need and what my resources are. I get to do systems design, as I get to solve problems in any way I particularly want... usually. Right now, I'm working on a program to do what our 'client support' version of our software doesn't do, which namely is, work properly :)
Well, not so much that, but also there are last minute things, like, "we can't do this with a trade" or "we need to do this to monitor our systems from desktops."
Your computer sciency things will come into play the more you program. Most common problems say, involving sorting and searching, are already built into perl, usually. But say, binary searching for instance is something that has come up. Some of the caching techniques i've learned in my master's classes i've implemented. I've built a finite state automata machine for some of the stateful things I need to write.
I also practice offline writing opensource stuff, which I'll release once the company lawer gets back to me, (you hear me chuck?), which I will reintegrate into my solutions. I built a 2d ticker for instance, which is very customizable, which could be used for relaying messages company wide, or alert people when new data is available.
I guess what I'm getting at is, it's not when is the soonest time you can use tools a-z, but knowing when you can implement any random tool at any time to improve a situation. You'll find tiem to do opengl stuff, or perl stuff when the time comes in. Heck, I could write expert systems to determine if a system is really down or it's just a network blip, right? It's about using your knowledge for the better and becoming wise.
|
|---|