5 thoughts on “Tips for Young Developers”

  1. + Question authority. Don’t assume your boss/lead/manager always knows the best way. If you have a better idea, speak up. But don’t take it personally if your idea isn’t used.
    + Don’t start until you understand how your task/role/code fits in the big picture. All too often, I have seen developers build something that isn’t quite right because they didn’t make the effort to understand the world around them.
    + Your code is broken until proven working. Don’t submit untested code even when you are in a hurry. It will slow down QA, who has to find and document your bug. It slows you down because you have to go through your bug reports, open your code, remember what is going on in there, fix the bug, test the bug, and resubmit your code. It will make your project later than if you had taken the time to do it right the first time. If you need more time, talk to your boss/lead/manager.
    P.S. submitting bugs is bad for your reputation too.

  2. “P.S. submitting bugs is bad for your reputation too.”
    I think you mean, getting bugs submitted against your code is bad for your reputation, right?
    I think finding bugs is good for your reputation, especially when you find the super-secret edge cases.

  3. Good post.
    Point 1 could be shortened to – Process is not an excuse.
    Point 2.5. Getting stuck doesn’t mean you stop. Sometimes you are the first to discover a problem – innovate, explore, try!
    Point 6, I retch every time I hear “scrum” or “agile” proposed as a solution to poor product management or shortsighted resource management. Good software development is not defined by following a process and we are not all Google.
    Point 6.5. Use multiple forms of communication.
    I like Alan’s comments too. I would add to the first one that at some point you are part of the team or working against it.

Leave a Reply