Programming - general advice

Printable View

07-30-2010
progcomputeach

Programming - general advice

I thought it would be good to write down a list of things you can do to improve your programming and job prospects when you have learned what you need to. To get the ball rolling:

a. learn the syntax of the language(and a Framework if there is one. E.g. .NET)
b. improve your coding by practising lots- the more you do the more you will reduce the number of errors you make. Having written lots of code you will remember what works and what does not
c. improve your problem solving-you will often have to work on this before writing your program
d. create a portfolio of programs which you can present to potential employers-perhaps upload them to a website
e. Put yourself in the shoes of the person using your program-what would you like to see, how would you like to use the program? This will help you (as a programmer) make the program easier to use.
f. Take some exams :-)

Suggestions, additions and comments are most welcome.
08-02-2010
ComputerWarrior

while this may or may not be related, knowing Win32, OpenGL (or DirectX),
and afew other major APIs will give you a good chance to have success.
08-03-2010
progcomputeach

programming

Oh of course its relevant. Anything that helps is useful :-)

Quote:

Originally Posted by ComputerWarrior

while this may or may not be related, knowing Win32, OpenGL (or DirectX),
and afew other major APIs will give you a good chance to have success.
08-03-2010
brewbuck

Quote:

e. Put yourself in the shoes of the person using your program-what would you like to see, how would you like to use the program? This will help you (as a programmer) make the program easier to use.

I think this single thing is the main reason why so much software is absolutely awful. Do NOT try to put yourself in the user's shoes, because you can't. The user is God. If you need a reference for what the user wants, that reference is the user. The reference is *never* yourself and your clever ideas.

If you are the user, or the users are other people like you, then the situation is obviously different, but that's not the usual case.
08-03-2010
pianorain

I'd disagree. If the developer cannot understand the user's needs enough to imagine a number of creative solutions, then the developer has no business working on that project. Obviously you have to check to make sure your imaginations are useful to the end user, but I wouldn't go so far as to say that a programmer shouldn't even try to imagine what would be useful to the user.
08-03-2010
brewbuck

Quote:

Originally Posted by pianorain

I'd disagree. If the developer cannot understand the user's needs enough to imagine a number of creative solutions, then the developer has no business working on that project. Obviously you have to check to make sure your imaginations are useful to the end user, but I wouldn't go so far as to say that a programmer shouldn't even try to imagine what would be useful to the user.

Solutions to stated problems are one thing, and problem domain knowledge and creativity are obviously extremely helpful. But IMHO the feature list and any specific requirements set down by the user are off limits to any sort of creativity.

I'm not saying you can't talk to the user and maybe change their mind about something, but once you have paper saying the features will be such-and-such and the interface will work like this-and-that, then that is the ultimate authority on what you need to do for the user.

The implementation guts are where you get to do your thing as a developer.
08-03-2010
claudiu

Quote:

Originally Posted by brewbuck

Solutions to stated problems are one thing, and problem domain knowledge and creativity are obviously extremely helpful. But IMHO the feature list and any specific requirements set down by the user are off limits to any sort of creativity.

I'm not saying you can't talk to the user and maybe change their mind about something, but once you have paper saying the features will be such-and-such and the interface will work like this-and-that, then that is the ultimate authority on what you need to do for the user.

The implementation guts are where you get to do your thing as a developer.

This is not the case in consulting. I met with a large nr of customers that walk in and say "what is the best way to get this done?" Obviously best is a different thing everytime.
08-03-2010
brewbuck

Quote:

Originally Posted by claudiu

This is not the case in consulting. I met with a large nr of customers that walk in and say "what is the best way to get this done?" Obviously best is a different thing everytime.

I've met very few users who care how something gets done, as long as it gets done. But nevermind, my intention isn't a thread hijack or a flamewar.
08-03-2010
pianorain

Quote:

Originally Posted by brewbuck

Solutions to stated problems are one thing, and problem domain knowledge and creativity are obviously extremely helpful. But IMHO the feature list and any specific requirements set down by the user are off limits to any sort of creativity.

I'm pretty sure I agree, as long as the user doesn't go so far as to say "this is exactly how I want the problem solved". In my mind, that's the role of the developer. I don't know how many times I've had a client say, "I want it done like this," and then change his mind after seeing their way contrasted with a couple of different ways I came up with.

Perhaps how we read (e) was different. My interpretation was basically "Consider use-cases", which I think is extremely valuable in terms of design.