quote: Original post by Dale
Are there any "secondary" skills required outside of programming? I''ve heard some people say that a background study of physics and maths is beneficial (which I have at first-year uni level) and problem-solving skills (which I have a knack for, why I went into support originally. )
Math and physics are very useful because a) computers are mathematical (their entire operation is based on binary math and boolean algebra, when viewed at a low enough level); and b) because many problems you will be faced with solving will involve a fair degree of math, especially calculus (rate of change anyone?)
In some situations you''ll be given the formulaic solution to your problems, so all you need to do is code/implement. Most of the time, however, you''ll be given fairly broad objectives and left to find a solution on your own. Which leads us to your next question...
quote: How much and what parts of the programming cycle, is a programmer allowed to exercise independant decision-making? I assume there wouldn''t be too much in the design cycle, but when it comes down to HOW an outcome is reached it would be a lot of decision-making. Is this true?
Yes... no... it depends.
(And in the final analysis, the answer to most questions is "it depends.")
There are definite instances where you will be given a set of parameters (inputs) and a desired outcome/output and told to do it your way. In such situations, you obviously have total flexibility, and might want to find the most efficient or most flexible way so that you can reuse your code. Other times you may be extending or integrating with existing software, meaning you may be confined by the (possibly bad) decisions made by the original software designer(s). In cases like this, grit your teeth and get through it as quickly as possible.
Case number three is when you''re asked to "update" (ie rework that pile of shit) or "modernize" (ie untangle my spaghetti and produce lovely OO) code. In such cases, I almost always advocate a complete redesign; it''s what I did for one of my former employers (never got to finish the app sadly). Figure out what is done, when, how and why, and incorporate that knowledge into an elegant framework of your design. You can rip out relevant pieces of code if you want to, but you''ll probably end up tracing globals and renaming variables till your hair turns white.
So, as you can see, the answer truly is "it depends."
I wanna work for Microsoft!