It seems like the consensus is to learn by doing when it comes to programming, well that seems like the advice given to most beginners.
How will beginners learn to write efficient code when they dive head first?
It seems like the consensus is to learn by doing when it comes to programming, well that seems like the advice given to most beginners.
How will beginners learn to write efficient code when they dive head first?
How will beginners learn to write efficient code when they dive head first?
Beginners learn to write efficient code when they learn to write readable code and show it to someone else. That someone usually tells them no one cares about their efficiency concern.
New programmers have a persistent problem in that when they finally get something working they want to keep playing with it. So long as they can keep playing with it they don't have to start a new task. They want make it better and the only better they can think of is efficiency. Short of actual Big O problems with actual large n values this is typically a waste of time.
At this stage there usually are many things that could make the code better. But since you're a beginner and, more importantly, since you wrote it you are a poor judge of what it needs to be made into readable flexible code (which is the best kind of better).
Beginners can show their code to others soon after writing it, while they're still willing to rewrite it. This will improve the readability and flexibility of the code as real issues get addressed. Once the code is readable it's far easier to tell how efficient it is. It's also easier to maintain. Do this and beginners can learn to write code that is as efficient as is needed.
There is very little code that needs to be efficient. Assume you are one of 20 million developers who need to sort an array. 19,999,999 of them don’t need to know how to do it efficiently, only one needs to know.
Take MethodA
for example. I just developed this now. When you call it, it takes two seconds to complete. Is that efficient? The simple answer is that you cannot judge that.
The reason I'm able to judge these cases as atrocious/amazing is because I compare it to other known attempts at doing the same thing.
We still don't know what MethodA
does, but I've also created MethodB
, which does exactly the same thing but it can do it in half a second. Even though we still don't know what either method does, we can already conclude that MethodB
is more efficient than MethodA
.
When I say something is efficient, I effectively mean that it is more efficient than earlier attempts.
Which brings me to my point, to answer your question: earlier attempts.
You don't write efficient code right off the bat. If you did, you wouldn't even know that it was efficient because you wouldn't have a less efficient earlier attempt to compare it to.
However, a good developer writes more efficient code as they encounter inefficiencies that they've created in the past and improve on their previous approach. This applies to self-starters and trained developers. Self-improvement is a must in software development regardless of how you started your career.
"So how do you find out which of your code is inefficient?"
As we established, you only know when something is inefficient when you've seen more efficient versions of the same thing. So if you want to be able to identify inefficiency, you need a wide ranging knowledge of implementations so that you can get a grip on how good your own implementation is.
Note also that some inefficiencies can be deduced by simply spotting unnecessary logic. Take these two examples:
public int Add(int a, int b)
{
return a + b;
}
public int Add(int a, int b)
{
return ((2*a + 2*b + 50) / 2) - 25;
}
It will always yield the same result, but the second example is clearly just doing some extra legwork that isn't necessary.
Note: I'm actually not sure if a compiler will automatically spot and optimize this particular example, but the general point still stands since there are more convoluted examples where the optimization is obvious to a developer but not easily identified by a compiler.
Efficiency aside, there is indeed a downside to learning anything just by doing.
Only the most talented people will recognize what they lack, know what next thing to look into and take their skill to the next level on their own. Most just hit a way that works for them and stick to that. They end up in a rut, being one-trick ponies. "Better" people showing the way can get you out of that rut and put you on the next track. That is the value of teaching.
So although doing it yourself is a necessity to make progress, it should not be the only thing. Trying something different never hurt anyone in software development and often you need some stimuli to do it, be it a senior developer or the internet.