Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
The best advice I can give is: PLEASE, PLEASE, seek SIMPLE solutions to everything.
Look for patterns in the problem domain that map elegantly to capabilities in the solution domain. e.g. "this looks like a grid" database table/spreadsheet/array. Try to look for solutions that involve the least code, and will cope best with change.
Don't do overarching "this will solve everything" framework solutions. Avoid the "inner platform effect" (see thedailywtf.com)
A bunch of other things:
If you find yourself saying "this is just a quick hack, we'll fix it later", then that's a bad sign. Find a better solution.
Ask questions. Ask lots of them. Don't worry about being annoying. This will help you in not repeating peers' mistakes, and in not duplicating code. Work closely with more experienced staff members. Learn from them.
Leave your pride/ego at the door. Don't get attached to your code. Accept criticism. You still need to stand up for what you believe to be right - more senior people can still make crappy solutions. But, remember the politics and pick your battles.
Stir things up... but just a little. People get set in their ways, and this stifles innovation and improvement. As the new guy, you have a unique perspective, and your fresh ideas can help. In this game, there is no "one way" to do things, but established teams and experienced engineers often fall into the trap of thinking there is.
Whenever you find a solution, look for another one. Your first thought isn't always the best solution.
Learn from the team culture, norms, "this is how we do it around here". Fitting in is often (not always!) more important than doing things right (e.g. a solution cohesive with the rest of the codebase can be better than an otherwise superior solution). But, be sure to make a distinction between what you think is right, and what your team norms are - this is important, because both will influence how you solve problems now, and in the future.
Remember, not everything is best solved by writing code. Integrating existing components, or using existing components can save a lot of time.
Also, remember that there are thousands upon thousands of dumbshit hacks in the software engineering world. Beware of them and please do not become one of them. Focus on your skills and continually train yourself.