|
At a smaller scale, the code you write every day and its experience matters. Did you write some awesomely complicated code that only Neo would understand? Great! Clean up the API, make it testable, expressive, and ask the intern if he “gets it”. If everyone on the team is scared to code review your code because you make them feel dumb, you’re doing it wrong. If you’re writing code for others to use, please consider the experience of those using it.
|
|
|
|
|
Amen2
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
I'll second that, or factorial it I guess in this case.
As I've often said about open source. It isn't open at all if developers can't read it and understand it.
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
Hmm.. you've not worked at my place then.
We have certain developers who make themselves feel dumb when you present them with a clean API that is expressive and testable. Unit tests are viewed with suspicion and not regarded as useful in any way, shape or form. Making an actual API to something is regarded as over-engineering by some. Interfaces, interschmaces.
When you're getting complaints about using a FirstOrDefault one-liner on an IEnumerable instead of a seven line foreach loop with an if inside then it's not you that's doing things wrong. If you're using generics and someone would rather you wrote a separate class for each generic type you need to handle, it's not you doing things wrong. If someone's objection to using interfaces is "I can't find the implementation", it's really not your fault.
|
|
|
|
|
Terrence Dorsey wrote: If everyone on the team is scared to code review your code because you make them feel dumb, you’re doing it wrong.
Sure, if everyone on the team had my skill level, then that would indicate something is very wrong, but then again, if everyone on the team had my skill level, nobody would be afraid of code reviews.
The reality is that teams are made up of people of different skills levels, some with less skills than me, others with more skills than me. And frankly, everyone who has the attitude "I can learn something from somebody else" doesn't walk into a code review scared. I've had junior level programmers ask me to explain a piece of code and only then do I realize that I did something poorly.
Being scared of a code review has nothing to do with complicated code. It has everything to do with the manager sitting in on the meeting, not understanding what is going on, and asking "why aren't we using VB?" or "can't this be done in SharePoint?" I kid you not.
It also has to do with not knowing how to facilitate a code review so that it isn't a waste of time or finger pointing and blaming. A code review should be a learning experience for everyone not a free form forum for criticism.
Those same people that fear code reviews are the same ones that don't like to use source control to check in their work at regular intervals, waiting instead for "when its perfect." (If you're reading this, you know who you are.) And that's based on insecurity stemming from knowing that you aren't as good as your resume says and you know you fooled people in their crappy interview processes, and now you're hiding.
Dumbing down code for the most junior person on the team isn't productive. If someone on your team feels dumb, then your team is fubar'd to begin with. I've worked with many junior level programmers and at worse, they will realize how much they still have to learn, but they are always grateful that someone is helping them learn, and guess what, they become productive members of the team.
Marc
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
