It is a really worrying situation. I do well with CS subjects, but at the end of day it is all useless as I don't know how to code.
How do I learn to code to make projects? I can make small programs easily. I can't use programming to create good stuff.
What should I start with? Recommend a book and course that teaches me enough to get started with projects.
Really worrying situation. I do well with CS subjects but at the end of day it is all useless as I don't know how to code.
That is normal. Computer Science and Programming are two completely different things. You should not expect that studying one will not automatically make you learn the other, any more than you should expect studying astronomy will automatically make your learn how to blow glass.
It has been said that Computer Science is really a misnomer, and is akin to calling Astronomy "Telescope Science" – just because computers can be used to investigate information and processes doesn't mean that they are somehow inherent to that science, just like the fact telescopes can be used to investigate planets and stars doesn't mean that telescopes are somehow inherent to astronomy.
There are some languages, for example German, French, and Italian, where the scientific discipline makes no reference to computers at all: in German, it is called Informatik, in French informatique, in Italian informatica – all are a neologism based on information and the Greek suffix -ik. In Spanish, it is called ciencias de la informática (similar to German, French, and Italian) or ciencias de la computación: note the subtle difference to English, it is the science of computation, not the science of computers. Danish uses the terms datalogi (a neologism formed by combining data with the -logi suffix as in geology, meteorology, metrology, etc.) for the stricter sense of the science of information, data, computation, and processes, and informatik for a broader inter-disciplinary view of the effects of "datalogi" on society, politics, humanity, and the broader world in general; what might be called Social Informatics in English.
As you can see, in many languages, there is a clear distinction made between "Informatics" and computers. It is a rather unfortunate accident of history that the language which confuses the two also happens to be the lingua franca for it.
How do I learn to code to make projects? I can make small programs easily. I can't use programming to create good stuff.
You studied Computer Science to become good at Computer Science. In the same way, you need to study Programming to become good at Programming. In addition, you also need to study Software Engineering to become good at what they call "programming in-the-large", i.e. programming large and complex systems collaboratively in a team over a longer period of time.
What should I start with? Recommend a book and course that teaches me enough to get started with projects.
I am personally a huge fan of How to Design Programs (HtDP). It teaches you, well, how to design programs. And it does this by giving you recipes to follow for how to analyze problems, solve them, transform them into algorithms and further into working programs.
Note that "recipe" is basically another word for "program", so in other words, the book teaches you programs for humans to run in their heads in order to generate programs to be executed by computers. How cool is that? :-)
Note that the current, second edition of HtDP does not include Imperative Programming. That material was present in the first edition, but was removed to be covered in an as-of-yet unwritten second volume How to Design Components / Classes. However, if you are interested in Imperative Programming, the first edition of HtDP is still available as is an early draft of How to Design Classes.
Note that HtDP assumes no programming knowledge and is targeted at high school students. But don't let that stop you: it just means that you'll probably be able to finish some early chapters faster, but I don't think you will be bored.
Concrete Abstractions is also a good read along similar veins. Like HtDP, it doesn't assume any programming knowledge.
Another book that you might hear mentioned is Structure and Interpretation of Computer Programs aka SICP. It is one of the greatest programming books ever written, and again, it doesn't assume any programming knowledge.
It is, however, geared to complete newbies who study at MIT. And so, while it does not assume any programming knowledge, it does assume quite a bit of domain knowledge, e.g. in the fields of electrical engineering, physics and math. Note: these have nothing to do with the concepts being taught, they are just needed to understand the exercises and examples. So, it might be better to read HtDP or Concrete Abstractions first, and then read SICP. However, since you are familiar with CS in general, I don't think you will have many problems.
All three of these books teach Programming. What they don't teach, is a complex Programming Language. I personally think that is a good thing. Learning a programming language takes a lot of time, just like learning anything takes a long time. So, any second you spend learning a programming language, you are not spending learning programming.
In my opinion, learning programming is more important than learning programming languages. You will almost never be in a position to choose your programming language anyway, and will have to learn whatever gets thrown at you. Let's face it: almost nobody gets hired to develop something completely novel completely from scratch based on no constraints whatsoever. You will almost certainly join an already existing team working on an already existing system, where the programming language to use has been chosen and set in stone long ago.
All three (series of) books I mentioned above use very simple languages that can be fully taught / learned and understood in minutes.
What all three books also (unfortunately) don't teach is Software Engineering. HtDP does at least teach Testing and a bit of Debugging, and even suggests something similar to Test-Driven Development / Design. HtDP also teaches documenting requirements.
Unfortunately, and much to my regret, I cannot recommend any books or courses for learning Software Engineering. That is not to say there aren't any, only that I don't know of them. I, personally, consider myself to have been taught Software Engineering very badly, and been permanently damaged.
There is the Software Engineering Body of Knowledge (SWEBoK) and the Software Engineering 2004 (SE2004), but I feel that both of those are not really up-to-date with modern real-world Software Engineering practices and ignore modern real-world Software Engineering challenges. (For example, it is almost impossible nowadays in our interconnected world to disentangle good software engineering from security engineering.)
Personally, I found it very enlightening to study both the Manifesto for Agile Software Development and the Twelve Principles of Agile Software and the Manifesto for Software Craftsmanship. Please note: I am not saying that Agile and Software Craftsmanship are the be-all-end-all of Software Engineering. I am merely saying that I personally found it interesting to study those two documents and their history, and think about what experiences made the people who wrote them become convinced that this is the best way to engineer software. The authors of both of those documents are experienced software engineers, who have both delivered many successful large, complex projects, and have seen many large, complex projects fail. What made them draw those particular conclusions from those failures and successes? I find that fascinating.
However, here is the hard truth: whether it is Computer Science, Programming, Programming Languages, or Software Engineering, or even playing an instrument, painting, woodworking, sports, etc., the only way to truly master something is lots of deliberate practice. Note that the "deliberate" part of "deliberate practice" is important. Sitting and noodling "Knocking on Heaven's Door" on your acoustic guitar is not practicing guitar, that's playing a song. Going to the beach is not practicing swimming.
And writing small tools for yourself is not practicing programming, that's working. Someone once said: if you don't delete what you wrote immediately after writing it, then you're working, not practicing.
Some people swear by so-called Code Kata. Kata are an idea from several martial arts; they are a series of formalized techniques that are practiced repetitively and are performed in front of an audience.
Similarly, Code Kata are simple exercises that you solve over and over again, ideally at some point performing them in front of an audience. Some people have tried setting their performances to music, such that, for example, some big refactoring which results in the deletion of a bunch of code coincides with a big climax in the piece.
One of the best ways of learning Software Engineering, or well, pretty much anything, is to find a mentor. Especially in the Software Craftsmanship movement, which models itself somewhat after the concept of Master Craftsmen in e.g. carpentry, mentorships / apprenticeships are fairly common, so you might find a mentor in one of their programs. You don't have to go to such extremes as e.g. Corey Haines did, who actually spent the better part of a year on something akin to traditional Journeyman Years, but it wouldn't be the worst way to learn either.
A note on programming languages: there are thousands of them. It is impossible to learn them all. However, programming languages implement Programming Paradigms and there are only a few dozen of those. Programming Paradigms, in turn, are composed of Concepts, and there's only about 20 of those. So, if you understand Concepts, that will help you understand Paradigms, which in turn will help you understand Languages, without actually having to learn dozens of paradigms or hundreds of languages.
Peter van Roy has made a nice poster with the 34 most important Programming Paradigms. A more thorough explanation of that poster is contained in the article Programming Paradigms for Dummies: What Every Programmer Should Know which appeared as a chapter in the book New Computational Paradigms for Computer Music, edited by G. Assayag and A. Gerzso. Some examples of paradigms include the well-known imperative programming, functional programming, ADT imperative programming, ADT functional programming, and sequential object-oriented programming / stateful functional programming, but also lesser known ones such as concurrent constraint programming, active object programming / object-capability programming, constraint (logic) programming, or multi-agent dataflow programming.
Paradigms, in turn, are composed of Programming Concepts. E.g. sequential object-oriented programming is composed of record, closure, cell, and procedure. If you add thread, you get concurrent OO programming. The most important concepts include some well known ones like cell (state), procedure, and record, but also lesser known ones like by-need synchronization, nondeterministic choice, or solver.
I would argue that understanding about 1/3 of those 18 concepts allows you to understand about 90% of the top 100 mainstream languages, if not more.
This is an interesting example, where Computer Science concepts, more specifically concepts from the field of Programming Language Theory are directly helpful in an industrial context, helping you to quickly learn programming languages by analyzing their paradigms and concepts.
By far the best explanations of programming paradigms are found in Peter van Roy's works. Especially in the book Concepts, Techniques, and Models of Computer Programming by Peter Van Roy and Seif Haridi. (Here's the companion wiki.) CTM uses the multi-paradigm Distributed Oz programming language to introduce all the major programming paradigms.
My own experience has been that really understanding a programming paradigm is only possible
Ideally, you would use a language which takes the paradigm to the extreme. In multi-paradigm languages, it is much too easy to "cheat" and fall back on a paradigm that you are more comfortable with. And using a paradigm as a library is only really possible in languages like Scheme which are specifically designed for this kind of programming. Learning lazy functional programming in Java, for example, is not a good idea, although there are libraries for that.
Here's some of my favorites:
The most-often talked about part of programming languages are their respective syntaxes. Personally, I also find them the least important. You can learn to ignore syntax, or if it really bothers you, write a preprocessor. You cannot easily change a language's semantics or type system.
Most mainstream languages nowadays borrow their syntax heavily from a small number of influential ancestors: blocks structured with curly braces from B (e.g. C, C++, Java, C#, ECMAScript, PHP, Rust, Go), blocks structured with keywords from Algol (e.g. Ruby), blocks structured through indentation from ISWIM (Python, Haskell), member selection with . from … I don't know where :-D (almost all of them), message sending with whitespace from Smalltalk (Objective-C), types in front of identifiers from Algol, types after identifiers separated with a colon from maths, types after identifiers separated with whitespace, plus the Lisp family and ML family.
Once you have seen some of them, you have seen (almost) all of them, and they are easy to learn. Also, modern code authoring tools help tremendously with intelligent autocompletion for writing code, and specific syntactical intricacies are often not that important for reading and understanding code. For example, many coding styles require parenthesizing complex expressions, so that knowing the subtle differences in operator precedences between different languages becomes a non-issue: except in interview puzzles designed to stump you (for which you can prepare and memorize them, and promptly forget them after the interview), or in really badly written code (which you need to carefully study anyway, since operator precedence typically is the least of your problems), you simply will not encounter them.
My advice is not too dissimilar from Buffy. I would try to get involved in projects with others. You might look into the indie game development community, or into the open source community. Join a project, contribute and observe.
Aim small. Even tiny-sounding projects will be surprisingly complex, and will help you to get your programming sea legs ("C" legs? Haha) under you. Scale is the enemy of project completion.
Finally, pair program whenever you can. You'll start to get a feeling for how to choose and utilize libraries instead of building things from scratch.
Actually, this is the main trick of the people who seem to be mystifyingly good at building solo projects. Their big skill is to get good at choosing and utilizing libraries instead of building everything themselves. By leveraging preexisting code, you can take an apparently large project (very hard for a person) and convert it into a small project. The closer the library you choose to your needs, and the better you are at using it, the smaller the project becomes.
Honestly, this is a big block for many of my students, who can learn to code themselves, but don't want to face the comparatively harder (or at least "surprisingly different") task or learning to read and use code bases developed by other people. Needless to say, the students who don't develop that skill are not able to build larger projects on their own. There is just too much headwind if you can't utilize the work of others and instead must build everything yourself.
Good luck!
If you're really new to programming, joining an open source project can be quite overwhelming. I would recommend picking up a puzzle challenge like Project Euler. Make a habit out of solving a challenge or two a day. Its great fun, and you'll find that you'll learn the basics quite quickly.
Although I cannot agree more with what was said above, practice makes perfect, I would also recommend reading the language reference of the language you plan on using. In the case of Python, that would be Python Language Reference.
After that you can pick up on what the others suggested, like joining an Open Source project, etc.
Best of luck to you!
The way to learn how to do this (or most anything) is to practice it so that experience gives you better results. You aren't going to learn it from a book or a video.
And, a good way to do it is in partnership with someone else (search for Pair Programming, say at wikipedia).
I suggest that you find someone, such as another student with similar concerns and approach one of your CS profs and ask them for an informal project that they might be willing to give you some feedback on. It might even be possible to arrange a bit of course credit in some places (Independent Study). One possibility for projects is to provide a "reference implementation" for some project that the professor already assigns to students or is contemplating doing so. A compiler, for example.
One of the more interesting projects that I once built was an "Entity Relationship" modeling tool (a graphical program) to be used to design databases. I also built compilers for a variety of simple languages.
I was self taught in CS in the early years and only got guidance later, but one of my earliest projects was to build a simulator for a simple computer. It had a few registers and a few instructions. The professor that teaches architecture probably has a machine specification that can serve as the basis.
But the way to learn it is to do it. More than once. And try to get feedback from a professor on your trials. This will help you avoid building poorly designed and impossible to maintain projects.
Some universities have a senior "capstone" project course that tries to bring together much of the curriculum in a single project. These are more likely to be team projects than otherwise, however.
While I did study CS, I learned most of what I use daily on my own, previous to my studies. As an adolescent, I would find something that interests me, and figure out how to do it from whatever sources of information that were available (paper books mostly, at that time, there was no Internet yet, at least not for the general public).
So, let your thoughts roam and find something - anything - that sounds interesting to you. If you're studying CS, then there should be some reason why you picked that topic (aside from there being a lot of jobs on offer, and often substantial salary for good graduates). What fascinates you?
Then whip out your programming language of choice and just "do it". Implement whatever you want. It should not even matter if it's big or small.
Think about what you learned in your studies, and try to apply it. It is normal that CS is not very applicable - some universities tend to focus a lot on the theoretical parts. Still, you can find out ways to do so.
Example projects from myself:
And so on and so forth. You do not need to pick those projects of course, but they all interested me. That stuff was possible back then even with quite limited information, and many more impressive projects should be much more accessible today with better tools and information.
TL;DR: Pick something of interest, and then use your skills and knowledge to make it - if you are lacking skills and knowledge, obtain them in the process.
As others have pointed out practice makes perfect. The best way to learn is by trying. Even recreating something that you have created before is a valuable since you often times realize what you could have done better once you are in the later stages of a project.
If you are lacking an idea of what to build you could try:
http://www.raytracerchallenge.com/
It‘s a book that teaches you how to create your own ray tracer. The neat thing is that it does not use any specific programming language. It gives you instructions on what to do and test cases to test your code.
If you are willing to spend some additional dollars you might also want to check out the Live Projects from Manning:
https://liveproject.manning.com/#catalog-list
They often run promotions where they cut prices by ~50%.
