Is there evidence that some software development best practices depend on programming skill level? I mean, these methods are good, but maybe the way the are used or the extent might vary?

This question arose after I read Paul Graham's commentary about OOP, and the last bullet point of this accepted answer. It proposes that where, how, and how much to use unit tests might depend on your programming skill.

So do top programmers use different approaches than average programmers?

4 Answers 4


Short Answer: Yes, that is why it is good for novice developer to learn and follow common programming practices.

Actually, understanding the inner-workings (business process flow) of a project and fixing bugs is a good starting point for novice developer. Learning from code is also good with good debugging skills as pre-condition. That said, it is a common approach that experienced one would also follow.

It is also true that understanding of programming problem challenge varies by experience. The novice programmer just gets the requirements and start to code, while experienced developer take time to read requirements and clarify them with BA or PM before starting to code.

Thus, getting advice from experienced developers is very essential learning process.

What is advice in nerd language? - In aspect and functional programming, advice describes a class of functions which modify other functions when the latter are run; it is a certain function, method or procedure that is to be applied at a given join point of a program.

  • 1
    +1. I always debug someone else's code to get it better
    – superM
    Jul 28, 2012 at 11:13

An approach does depend on one's skills and especially experience. A novice programmer is using the methods he knows to solve a problem, and usually there isn't a wide variety of methods that a novice can suggest. On the other hand, more experienced programmers have solved more problems, they know many solutions and know when each of them will works best.

In addition, novice programmers aren't usually given tasks where they have to apply various techniques and patterns. The more experienced the developer is, the harder (and more interesting, as a consequence) tasks they get.

The problem is that many programmers just don't know how to apply their knowledge correctly. They might know a lot of design patterns, techniques, but have little (or no) experience applying them. So they only make their code more complicated and less maintanble trying to give a "smart" solution.

But of course if some bright newcomer suggests a nice approach requiring a lot of skills, no one will tell him it's too good for him. Vice verse, he/she will be encouraged to keep working the same way.


From PG's blog entry:

There is a danger in designing a language based on one's own experience of programming. But it seems more dangerous to put stuff in that you've never needed because it's thought to be a good idea.

With regard to your question, I'd offer the following:

There is a danger in solving programming problems with seemingly boring boilerplate code. But it seems more dangerous to program in ways that you never have before simply because it's thought to be a good idea.

For example, here's what I observed with .NET:

  • When .NET 2.0 shipped, junior developers used generics in ways that did not make sense, simply because they thought they were a good idea.
  • When .NET 3.5 shipped, junior developers wrote confusing LINQ statements in places where simple foreach loops would suffice simply because they thought they were a good idea.
  • When ASP.NET Web Forms fell out of favor with the development community, junior developers a fellow junior developer added new features according to an MVP Pattern simply because he read that it was a good idea.

To make it perfectly clear, Generics, LINQ, and the MVP Pattern all have their place. When used correctly, these can simplify code; but they must be used in the proper context.


I consider myself an experienced programmer, both in time and tasks. My style definitely has changed a lot over the years.

As I see, I am a strange kind of programmer/architect. I am never proud of what I have written, but the ability that I was able to accomplish that task. I do respect running code, but by the original meaning of the word: re-spect: check it again. And refactor, whenever it is not exactly what I want to see.

I change the name of a variable or a function several times, if it does not exactly mean what it does - until I don't have to roll up to the definition, because the name is evident. I move a function or data several times between layers of a system until they get to where they really belong. I always re-indent my codes, I never leave any () although I know the operator precedence, or the {} after an if for a single instruction.

I have a strong feeling that there is a good way to do a task - and far too many working, but structurally wrong solution. The structure (service layers, communication, responsibility, data) is much more important (because it affects the whole structure of a system), while the code should be "good enough" to run.

Programming for me is a constant search for that good answer, and I still have a lot to learn - but what seemed to be a whole field of many possible ways when I was a beginner, looks a map with a very few paths to try. It s fundamentally different.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.