1

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?

7
  • We learn to write efficient code by first writing inefficient code.
    – Dan Wilson
    Jun 24, 2020 at 3:58
  • 3
    Beginners never write efficient code, as they never have the correct notion of "efficient". It is not runtime, big-O, least lines of code or whatever the idea is. It is the most maintainable code that matters, and this is a thing you only learn be being a professional coder for quite a number of years.
    – mtj
    Jun 24, 2020 at 4:21
  • IMHO, a.k.a hearsay: Yes, learn by doing. However, that does not mean learn by doing without following examples or similar guidance. That is the first way you will learn. The second is experimentation with good tools, static analysis and testing… Again, by doing. That is perfectly fine way to learn programming. When it comes to software architecture, requirement analysis, and so on… It is better to start with the theory. However, you also need the praxis.
    – Theraot
    Jun 24, 2020 at 4:48
  • 6
    This is a false dichotomy. Learning and Doing usually happen in tandem, even in the extreme cases. The only case with just learning and doing is if a student tries to learn computer programming, but does not have access to a real computer on which program code can be written and executed (or simulated).
    – rwong
    Jun 24, 2020 at 5:52
  • I think the problem is more in area of how and when you receive feedback when learning. Another is that coding is usually not the main problem. Yet, I've met plenty of young developers who think they are hot sh*t just because they can hack together few lines of code. The main issues are in creating design that is understandable, maintanable and can be extendended.
    – Euphoric
    Jun 24, 2020 at 7:27

4 Answers 4

6

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.

3

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.

0
2

Efficiency isn't an absolute measurement, it's relative.

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.

  • If this method adds two numbers together, the efficiency is atrocious.
  • If this method brute forces a complex encryption, the efficiency is amazing.

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.

2
  • how do you gain that wide range knowledge of implementations? Jun 24, 2020 at 10:45
  • @HishamMohammed: How do you gain any knowledge? Experience and looking things up.
    – Flater
    Jun 24, 2020 at 10:51
0

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.

Your Answer

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

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