Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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?
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.
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:
foreach loops would suffice simply because they thought they were 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.
