Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Simplicity (Score 1) 662

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

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.

Slashdot Top Deals

It is masked but always present. I don't know who built to it. It came before the first kernel.