How to learn programming in general?

Nice little problem.

Surprisingly he does not make the observation that the numbers he gets in each cell, as worked in his spread sheet, form Pascal's Triangle: https://en.wikipedia.org/wiki/Pascal's_triangle. Which gives one all kind of interesting ways to think about the problem. As people have been doing for 2000 years or more.

These kind of programming puzzles are rather like the questions in maths challenges. The first thing you have to do is pull the problem out of the words the question uses. Those words are often thrown in as a "blinders" to throw you off the scent. As in this example.

The mathematician Po-Shen Loh gives exactly the same advice as this guy, look for different approaches, play with little examples, look for patterns, to kids tackling maths problems.
"Daily Challenge with Po-Shen Loh": https://www.youtube.com/channel/UCf78EJOm4wQ4xXwSS15PuxQ

Po-Shen Loh likes to say that one should not be afraid of maths, it's just "thinking". And so it is with programming.

1 Like

Thanks for your tips. I will start from scratch and I will try to build solid experience and knowledge

2 Likes

That's the spirit. Keep at it.

1 Like

Elm really helped me understand how to structure programs. Rust is similarly well-designed, so both languages nudge you towards doing the right things. The benefit of Elm is that it is much smaller and specific, so it's much easier to go beyond the syntax and constructs, and start thinking about how do to things better.

I agree with the others that the best way to learn is to make something. Only when you have felt the pain, do you understand why certain things are helpful. For example long variable names might feel unnecessary while writing, but once you've read your code from a month ago, you'll see why long names are absolutely worth the extra second of typing.

Incidentally, the Elm community puts out quite a few very informative talks and resources. Of the top of my mind, I can recall that The Life of a File and Making Impossible States Impossible helped me understand modules and types much better, not just in Elm.

2 Likes

thanks for the hint. I'll take a look

A bit late to the party, but here are some of my hints to become a better programmer.

  1. Never stop learning
  • Books, tutorials, hands-on coding. You need all of that. If you just see how C++ and Java evolved the last 10 years, you will see that keep learning is essential even if you stick to a single language.
  1. Learn smartly
    We do need to learn, but every one of us has a very limited of time to learn. So before delving into something we need to spend just a little time, looking at reviews and stuff like that to see if it is really worth. Related to that:

Exactly, one needs to read the right books. The one book which made the highest difference in the quality of my code was Working Effectively with Legacy Code , by Micheal Feathers. That book teaches the difference between average code done by experienced programmers to awesome code. Spoiler: it has nothing to do with smart one-liners or obscure features. It has actually to do with much simpler things which even a beginner can apply.

  1. Think globally, act locally.
    You need to exercise the ability to work on different abstract levels: see a forest for the trees. See each tree individually if needed. Talk to your team about architecture. No one can make good changes without understanding the system architecture.

  2. Verify what you are doing often. I really mean very often!
    Let`s compare programming to doing walking through a forest. If you want reach some goal on the other side you need to :

  • know where you are going (have a map, see the big picture)
  • Walk each small step
  • Verify often your steps are on the right direction
    The third point is where many people get wrong. I have seen experienced (and otherwise very good) programmers writing a lot of code and only then verifying if it works. This equivalent to working 1000m into the forest and then checking your GPS. No wonder the final path looks like a random walk, and that you may leave to the wrong side of the forest (incorrect software - which QA or the customer will gladly tell you does not work).
    You should be verifying your small steps (say every 5-15 minutes of coding - change a unit test status, or at least running some new debug output), as well as larger integration steps, say every 3-4 hours integrating into larger stuff and check waht is going on , doing integration tests

Here's an interesting one that I'd suggest: Don't go to college for it.

There are so many resources for learning programing that you can learn so much more that you actually need to learn for what you want to do that you don't need to go to college.

If you want a degree or something to show potential employers, then that might be a reason to go to college. But weigh that against the fact that you can get free certificates from Free Code Camp on certain things:

I think most real learning in college takes place outside of coursework. It’s a socially-acceptable way to spend a few years learning full-time as an adult; if you use that time well it can produce huge ongoing benefits, but it’s also really easy to squander it and only come out the other side with a piece of paper.

1 Like

Thanks for the hint with Elm. I heard about it before, but I didn't pay attention. Now I have taken a closer look at it, and I think it is worth learning.

It looks like a promising language and it might be a good frontend for Rust.