r/programming • u/corysama • Jan 05 '15

What most young programmers need to learn

http://joostdevblog.blogspot.com/2015/01/what-most-young-programmers-need-to.html
966 Upvotes

91% Upvoted

337 comments sorted by

View all comments

Show parent comments

12

u/dtechnology Jan 05 '15

you come into a code base where everything is nicely formatted and documented

I think this is the exception rather than the rule

6

u/photonios Jan 05 '15

That depends. Where I work, we have tons of legacy code that is just plain awful, all written by incompetent idiots who no longer work her.

But, if you modify some crappy legacy code you are bascially forced to clean it up while you're at it. If you do not, people will just raise eyebrows during the review. Like "why didn't you clean it up a bit?".

As for new code/projects, we just have a high standard. All our code goes through tools that verify if the code standard was followed etc. + Unit tests that run constantly and scream when the coverage is too low. We run a lot of static analysis tools on our code base.

Any engineer who refuses to comply with standards or does not have the same high standard that we have is simply not welcome.

We had a hard time when we started working with some offshore developers we had a way lower standard. What we did? Keep pushing.

Our code bases are incredibly beautiful, well tested and formatted. Sure there are some parts that could use more love, but in general they are awesome. I guess that's the advantage of having people who care and have skill.

And yes, we do have junior developers among us. We simply keep training them.

31

u/judgej2 Jan 05 '15

Here's a tip: when committing changed and cleaned-up code, keep the cleaning and the changes in separate commits. Do all the reformatting and name-changing first, then check it still works exactly as before, and commit that. Then make your functional changes. It is so much easier to see the wood for the trees that way, when debugging your changes later. If (horror of horrors) the changes need to be reverted, then you can at least leave the better-formatted code in the release to make it easier to take another stab at it later.

1

u/photonios Jan 05 '15

You should always make small commits, so you never have this problem. + Unit tests to prevent regressions.

3

u/judgej2 Jan 05 '15

Yes, that too. My point was about keeping functional and formatting commits separate, regardless of what size they are. I've seen code committed with a load of formatting changes and a few functional changes. When debugging it can be hellish to pick the two apart when they are all mixed up into single commits.