<p>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 <a href="https://projecteuler.net/" rel="noreferrer">Project Euler</a>. 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.</p>
<p>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 <a href="https://docs.python.org/3/reference/" rel="noreferrer">Python Language Reference</a>.</p>
<p>After that you can pick up on what the others suggested, like joining an Open Source project, etc.</p>
<p>Best of luck to you!</p>

CC BY-SA 4.0
2021-10-27T16:13:07.070Z
This is by far the best suggestion, all these "JuSt CoNTrIbUtE To OpEnSoUrcE!" answers are way too naive.  You can't "just" contribute to open source.  If you don't understand real code, you won't easily be able to navigate their codebase.  And the sense of accomplishment is probably *far far off*.  With puzzle challenges (and I'd recommend Advent of code as well) you get a lot quicker with the gratification loop and are encouraged to program more in a much simpler easy to verify environment (even if the challenges themselves are hard).
Krupip
CC BY-SA 4.0
2021-11-02T17:08:31.760Z
While good advice, solving programming challenges seems unrelated to _projects_ as I understand them. I'm guessing OP wants to make a "real" application, like a game, web app, mobile app, etc. Algorithm challenges are solved with tiny scripts that run on the command line and can be solved with 20-30 lines of code seem disjoint to making apps. OTOH, open source projects are far too intimidating and prohibitive to get involved with -- _too_ real.
ggorlen
CC BY-SA 4.0
2021-10-26T23:50:14.227Z
2021-10-26T23:50:14.227Z
S. Jacobs
<h1>Computer Science vs. Programming</h1>
<blockquote>
<p>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.</p>
</blockquote>
<p>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.</p>
<p><a href="https://quoteinvestigator.com/2021/04/02/computer-science/" rel="noreferrer">It has been said that Computer Science is really a misnomer, and is akin to calling Astronomy &quot;Telescope Science&quot;</a> – 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.</p>
<p>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 <em>Informatik</em>, in French <em>informatique</em>, in Italian <em>informatica</em> – all are a neologism based on <em>information</em> and the Greek suffix <em>-ik</em>. In Spanish, it is called <em>ciencias de la informática</em> (similar to German, French, and Italian) or <em>ciencias de la computación</em>: note the subtle difference to English, it is the science of comput<strong>ation</strong>, not the science of comput<strong>ers</strong>. Danish uses the terms <em>datalogi</em> (a neologism formed by combining <em>data</em> with the <em>-logi</em> suffix as in geology, meteorology, metrology, etc.) for the stricter sense of the science of information, data, computation, and processes, and <em>informatik</em> for a broader inter-disciplinary view of the effects of &quot;datalogi&quot; on society, politics, humanity, and the broader world in general; what might be called <em>Social Informatics</em> in English.</p>
<p>As you can see, in many languages, there is a clear distinction made between &quot;Informatics&quot; 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.</p>
<h1>… and Software Engineering</h1>
<blockquote>
<p>How do I learn to code to make projects? I can make small programs easily. I can't use programming to create good stuff.</p>
</blockquote>
<p>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 &quot;programming in-the-large&quot;, i.e. programming large and complex systems collaboratively in a team over a longer period of time.</p>
<h1>Books that teach Programming</h1>
<blockquote>
<p>What should I start with? Recommend a book and course that teaches me enough to get started with projects.</p>
</blockquote>
<p>I am personally a huge fan of <a href="https://htdp.org/" rel="noreferrer"><em>How to Design Programs (HtDP)</em></a>. 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.</p>
<p>Note that &quot;recipe&quot; is basically another word for &quot;program&quot;, 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? :-)</p>
<p>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 <em>How to Design Components / Classes</em>. However, if you are interested in Imperative Programming, <a href="https://htdp.org/2003-09-26/" rel="noreferrer">the first edition of HtDP is still available</a> as is an early draft of <a href="https://felleisen.org/matthias/htdc.html" rel="noreferrer"><em>How to Design Classes</em></a>.</p>
<p>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.</p>
<p><a href="https://Gustavus.Edu/+max/concrete-abstractions.html" rel="noreferrer">Concrete Abstractions</a> is also a good read along similar veins. Like HtDP, it doesn't assume any programming knowledge.</p>
<p>Another book that you might hear mentioned is <a href="http://MITPress.MIT.Edu/sicp/" rel="noreferrer"><em>Structure and Interpretation of Computer Programs</em></a> aka SICP. It is one of the greatest programming books ever written, and again, it doesn't assume any programming knowledge.</p>
<p>It <em>is</em>, however, geared to complete newbies <em>who study at MIT</em>. And so, while it does not assume any programming knowledge, it <em>does</em> assume quite a bit of <em>domain</em> knowledge, e.g. in the fields of electrical engineering, physics and math. Note: these have nothing to do with the <em>concepts</em> being taught, they are just needed to understand the <em>exercises</em> and <em>examples</em>. 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.</p>
<h1>Learning Programming vs. Learning Programming Languages</h1>
<p>All three of these books teach Programming. What they don't teach, is a complex Programming <em>Language</em>. I personally think that is a good thing. Learning a programming language takes a lot of time, just like learning <em>anything</em> takes a long time. So, any second you spend learning a programming language, you are not spending learning programming.</p>
<p>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.</p>
<p>All three (series of) books I mentioned above use very simple languages that can be fully taught / learned and understood in minutes.</p>
<h1>How to learn Software Engineering</h1>
<p>What all three books <em>also</em> (unfortunately) don't teach is <em>Software Engineering</em>. HtDP <em>does</em> at least teach Testing and a bit of Debugging, and even suggests something similar to Test-Driven Development / Design. HtDP also teaches documenting requirements.</p>
<p>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.</p>
<p>There is the <a href="https://wikipedia.org/wiki/Software_Engineering_Body_of_Knowledge" rel="noreferrer"><em>Software Engineering Body of Knowledge (SWEBoK)</em></a> and the <a href="https://wikipedia.org/wiki/Software_Engineering_2004" rel="noreferrer"><em>Software Engineering 2004 (SE2004)</em></a>, 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.)</p>
<p>Personally, I found it very enlightening to study both the <a href="https://agilemanifesto.org/" rel="noreferrer"><em>Manifesto for Agile Software Development</em></a> and the <a href="https://agilemanifesto.org/principles.html" rel="noreferrer"><em>Twelve Principles of Agile Software</em></a> and the <a href="https://manifesto.softwarecraftsmanship.org/" rel="noreferrer"><em>Manifesto for Software Craftsmanship</em></a>. Please note: I am <em>not</em> 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.</p>
<h1>Deliberate Practice</h1>
<p>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 <em>only</em> way to truly master something is <em>lots of deliberate practice</em>. Note that the &quot;deliberate&quot; part of &quot;deliberate practice&quot; is important. Sitting and noodling &quot;Knocking on Heaven's Door&quot; on your acoustic guitar is not practicing guitar, that's playing a song. Going to the beach is not practicing swimming.</p>
<p>And writing small tools for yourself is not practicing programming, that's <em>working</em>. Someone once said: if you don't delete what you wrote immediately after writing it, then you're working, not practicing.</p>
<h1>Kata</h1>
<p>Some people swear by so-called <a href="http://codekata.com/" rel="noreferrer"><em>Code Kata</em></a>. 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.</p>
<p>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.</p>
<h1>Mentorship</h1>
<p>One of the best ways of learning Software Engineering, or well, pretty much anything, is to find a <em>mentor</em>. Especially in the Software Craftsmanship movement, which models itself somewhat after the concept of <em>Master Craftsmen</em> 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. <a href="http://blog.coreyhaines.com/" rel="noreferrer">Corey Haines</a> did, who actually spent the better part of a year on something akin to traditional <a href="https://wikipedia.org/wiki/Journeyman_years" rel="noreferrer">Journeyman Years</a>, but it wouldn't be the worst way to learn either.</p>
<h1>Programming Languages</h1>
<p>A note on programming languages: there are thousands of them. It is impossible to learn them all. However, programming languages implement <em>Programming Paradigms</em> and there are only a few dozen of those. Programming Paradigms, in turn, are composed of <em>Concepts</em>, and there's only about 20 of those. So, if you understand <em>Concepts</em>, that will help you understand <em>Paradigms</em>, which in turn will help you understand <em>Languages</em>, without actually having to learn dozens of paradigms or hundreds of languages.</p>
<h1>Paradigms</h1>
<p>Peter van Roy has made a nice <a href="https://www.info.ucl.ac.be/%7Epvr/paradigms.html" rel="noreferrer">poster with the 34 most important Programming Paradigms</a>. A more thorough explanation of that poster is contained in the article <a href="http://WWW.Info.UCL.Ac.Be/%7Epvr/VanRoyChapter" rel="noreferrer">Programming Paradigms for Dummies: What Every Programmer Should Know</a> which appeared as a chapter in the book <em>New Computational Paradigms for Computer Music</em>, edited by G. Assayag and A. Gerzso. Some examples of paradigms include the well-known <em>imperative programming</em>, <em>functional programming</em>, <em>ADT imperative programming</em>, <em>ADT functional programming</em>, and <em>sequential object-oriented programming / stateful functional programming</em>, but also lesser known ones such as <em>concurrent constraint programming</em>, <em>active object programming / object-capability programming</em>, <em>constraint (logic) programming</em>, or <em>multi-agent dataflow programming</em>.</p>
<h1>Concepts</h1>
<p>Paradigms, in turn, are composed of <em>Programming Concepts</em>. E.g. sequential object-oriented programming is composed of <em>record</em>, <em>closure</em>, <em>cell</em>, and <em>procedure</em>. If you add <em>thread</em>, you get concurrent OO programming. The most important concepts include some well known ones like <em>cell (state)</em>, <em>procedure</em>, and <em>record</em>, but also lesser known ones like <em>by-need synchronization</em>, <em>nondeterministic choice</em>, or <em>solver</em>.</p>
<p>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.</p>
<p>This is an interesting example, where Computer Science concepts, more specifically concepts from the field of <em>Programming Language Theory</em> are directly helpful in an industrial context, helping you to quickly learn programming languages by analyzing their paradigms and concepts.</p>
<p>By far the best explanations of programming paradigms are found in Peter van Roy's works. Especially in the book <a href="http://WWW.Info.UCL.Ac.Be/%7Epvr/book" rel="noreferrer"><em>Concepts, Techniques, and Models of Computer Programming</em> by Peter Van Roy and Seif Haridi</a>. (<a href="http://CodePoetics.Com/wiki/" rel="noreferrer">Here's the companion wiki.</a>) CTM uses the <a href="http://WWW.Mozart-Oz.Org/" rel="noreferrer">multi-paradigm Distributed Oz programming language</a> to introduce all the major programming paradigms.</p>
<p>My own experience has been that <em>really</em> understanding a programming paradigm is only possible</p>
<ul>
<li>one paradigm at a time and</li>
<li>in languages which <em>force</em> you into the paradigm</li>
</ul>
<h1>Learning Concepts through Paradigms through Languages</h1>
<p>Ideally, you would use a language which takes the paradigm to the extreme. In multi-paradigm languages, it is much too easy to &quot;cheat&quot; 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.</p>
<p>Here's some of my favorites:</p>
<ul>
<li><strong>object-orientation in general</strong>: <a href="http://SelfLanguage.Org/" rel="noreferrer">Self</a>
<ul>
<li><strong>prototype-based object-orientation</strong>: Self</li>
<li><strong>class-based object-orientation</strong>: <a href="http://NewspeakLanguage.Org/" rel="noreferrer">Newspeak</a>
<ul>
<li><strong>static class-based object-orientation</strong>: <a href="http://Eiffel.Com/" rel="noreferrer">Eiffel</a></li>
</ul>
</li>
<li><strong>multiple dispatch based OO</strong>: <a href="http://WWW.OpenDylan.Org/" rel="noreferrer">Dylan</a></li>
<li><strong>functional + object-orientation</strong>: <a href="http://Scala-Lang.Org/" rel="noreferrer">Scala</a></li>
</ul>
</li>
<li><strong>functional programming</strong>: <a href="http://Haskell.Org/" rel="noreferrer">Haskell</a>
<ul>
<li><strong>pure functional programming</strong>: Haskell
<ul>
<li><strong>lazy pure functional programming</strong>: Haskell</li>
</ul>
</li>
<li><strong>static functional programming</strong>: Haskell</li>
<li><strong>dynamic functional programming</strong>: <a href="http://Clojure.Org/" rel="noreferrer">Clojure</a></li>
</ul>
</li>
<li><strong>imperative programming</strong>: <a href="http://Lua.Org/" rel="noreferrer">Lua</a></li>
<li><strong>concurrent programming</strong>: Clojure
<ul>
<li><strong>message-passing concurrent programming</strong>: <a href="http://Erlang.Org/" rel="noreferrer">Erlang</a></li>
</ul>
</li>
<li><strong>metaprogramming</strong>: <a href="https://racket-lang.org/" rel="noreferrer">Racket</a>, <a href="http://Schemers.Org/" rel="noreferrer">Scheme</a></li>
<li><strong>language-oriented programming</strong>: <a href="http://IntentSoft.Com/" rel="noreferrer">Intentional Domain Workbench</a>, unfortunately defunct; try <a href="http://jetbrains.com/mps/" rel="noreferrer">JetBrains MPS</a> instead</li>
</ul>
<h1>What about syntax?</h1>
<p>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.</p>
<p>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 <code>.</code> 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.</p>
<p>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.</p>

CC BY-SA 4.0
2021-10-27T13:36:03.650Z
Other than the fact that this will probably bury the OP, this is pretty awesome.
Buffy
CC BY-SA 4.0
2021-10-27T21:54:03.190Z
I freely admit that most of these are pre-made soapboxes I have preached on before that I just pulled off my shelf. (Have I strained the metaphor enough?) One soapbox that I left out is Project Euler and friends, which I find to be interesting *Maths* exercises, but, at least for me, don't seem to be doing much for *programming* and certainly not for software engineering.
Jörg W Mittag
CC BY-SA 4.0
2021-10-28T02:41:44.953Z
I think this answer would be better without the lists of "paradigms" and "concepts", which seem arbitrary. Otherwise, right on the point! Regarding language concepts, [7 languages in 7 weeks](https://pragprog.com/titles/btlang/seven-languages-in-seven-weeks/) is also popular
Bergi
CC BY-SA 4.0
2021-10-28T16:24:15.323Z
*"in German, it is called Informatik, in French informatique, in Italian informatica – all are a portmanteau neologism based on information and mathematics"* Every single source I've read about this says the word comes from "information" and "automatique", not "mathematiques". Etymologically, "Informatique" is about automated processing of information.
Stef
CC BY-SA 4.0
2021-10-28T16:37:44.960Z
@Stef: Interesting. Both according to Wikipedia and Wiktionary, the term *Informatik* was coined by Karl Steinbuch, shortly before he became a professor in Karlsruhe. I studied in Karlsruhe under a professor who was himself a student under Steinbuch. He was the one who told us that. But actually, according to both Wikipedia and Wiktionary, we are both wrong, and Steinbuch simply added the Greek suffix *-ik* with no special reference to either mathematics or automatic.
Jörg W Mittag
CC BY-SA 4.0
2021-10-28T21:55:46.803Z
The best answer about the industry/discipline I've ever seen on SE and something I've personally been wondering about for a while, especially about the difference between the different degrees; thanks for this and please don't get rid of the paradigms and concepts part. Is there a good resource for learning all of the "concepts" in either Object-Oriented Programming or Functional Programming?
Hashim Aziz
CC BY-SA 4.0
2021-10-29T10:44:37.033Z
There is no "Greek suffix _-ik_ for what it's worth. I think you are thinking of [the Latin suffix _-icus_](https://en.wiktionary.org/wiki/-icus#la) which is cognate with the Ancient Greek suffix _-ikos_, but _-ik_ isn't a thing as far as I know.
terdon
CC BY-SA 4.0
2021-11-02T00:59:47.900Z
Just a note that Berkeley's cs61a course is based off a version of SICP and has its lectures, labs, hw, projects, etc entirely online for past semesters, which can be useful to go through alongside the book - see cs61a.org.
auden
CC BY-SA 4.0
2021-11-02T01:04:21.867Z
I would also be interested in your thoughts on Code Complete as a software engineering text, as I've seen it recommended a lot but never made it through the whole thing (partly because I started reading it well before I actually needed it.)
auden
CC BY-SA 4.0
2021-10-27T11:35:21.303Z
2021-10-28T16:39:29.537Z
2021-10-28T16:39:29.537Z
Jörg W Mittag
<p>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.</p>
<p>Aim small.  Even tiny-sounding projects will be surprisingly complex, and will help you to get your programming sea legs (&quot;C&quot; legs? Haha) under you.  Scale is the enemy of project completion.</p>
<p>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.</p>
<p>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.</p>
<p>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 &quot;surprisingly different&quot;) 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.</p>
<p>Good luck!</p>

CC BY-SA 4.0
2021-10-26T15:57:10.377Z
2021-10-27T18:33:52.970Z
2021-10-27T18:33:52.970Z
Ben I.
<p>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.</p>
<p>And, a good way to do it is in partnership with someone else (search for Pair Programming, say at wikipedia).</p>
<p>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 &quot;reference implementation&quot; for some project that the professor already assigns to students or is contemplating doing so. A compiler, for example.</p>
<p>One of the more interesting projects that I once built was an &quot;Entity Relationship&quot; modeling tool (a graphical program) to be used to design databases. I also built compilers for a variety of simple languages.</p>
<p>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.</p>
<p>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.</p>
<p>Some universities have a senior &quot;capstone&quot; 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.</p>

CC BY-SA 4.0
2021-10-27T03:40:35.877Z
"The professor that teaches architecture probably has a machine specification that can serve as the basis." I suspect you might be showing your age a bit there, Buffy. What university would teach Assembly code nowadays, when nobody in industry uses it anymore?
nick012000
CC BY-SA 4.0
2021-10-27T14:52:56.873Z
The purpose of building a machine simulator isn't to learn assembly language program, @nick012000, but to get an idea of how low level computation actually works. Building a Turing Machine simulator is also valuable for learning, but has little "practical" use.
Buffy
CC BY-SA 4.0
2021-11-02T17:12:32.340Z
@nick012000 Almost all universities I've known teach assembly nowadays. Why? It's foundational to how computers work. It's untrue that _nobody_ in the industry uses assembly. Sure, if your goal is to make React apps, assembly is not helpful and in that sense, I understand your point. Universities still teach CS and deeper knowledge than exclusively "just get me a job ASAP" skills, although they do that too.
ggorlen
CC BY-SA 4.0
2021-10-26T12:59:36.810Z
2021-10-26T12:59:36.810Z
Buffy
<p>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).</p>
<p>So, let your thoughts roam and find something - <em>anything</em> - that sounds interesting to <em>you</em>. If you're studying CS, then there should be <em>some</em> 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?</p>
<p>Then whip out your programming language of choice and just &quot;do  it&quot;. Implement whatever you want. It should not even matter if it's big or small.</p>
<p>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 <em>lot</em> on the theoretical parts. Still, you can find out ways to do so.</p>
<p>Example projects from myself:</p>
<ul>
<li>I programmed a moderately simple 3D modelling tool (I daresay you would call it CAD these days).</li>
<li>... made my own version of Breakout.</li>
<li>... programmed a client-server 2D isometric multiplayer game (you would call it ARPG today, or if there were ever more than 2 players online for the very short time the servers were running, an very small MMORPG), including the net code, an integrated scripting language, and all the tooling, everything from scratch.</li>
<li>... a tool which would parse a hypothetical programing language and displayed the internal representation as a graph on the screen (combining topics from Compiler Theory and Graph Theory)</li>
<li>... (one of my favourites) a floppy disk utility for an 8 bit computer, written in assembler, and includinf a lot of low level features including a disk formatting routine. You get one try at guessing how I lost the source code to this application eventually.</li>
<li>... used Prolog to make a tool to ... don't know what it was, maybe putting pupils into classes.</li>
<li>... worked on a popular open source rogue-like game (similar to Nethack), ported it to a fringe OS and maintained it for some time.</li>
</ul>
<p>And so on and so forth. You do not need to pick <em>those</em> 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.</p>
<p>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.</p>

CC BY-SA 4.0
2021-10-28T22:01:20.293Z
I'm currently in the same situation as you prior to your CS degree, and am deciding whether to study CS or something else. Do you think the CS degree was worth it in the end, or do you think you might have benefitted more from doing something like Software Engineering, or even just studying online programming courses?
Hashim Aziz
CC BY-SA 4.0
2021-11-02T09:58:07.610Z
For me it was perfect. I find almost all CS topics very interesting, and while the occasions where I could really apply the knowledge from those studies were very sparse in the last decades, occasionally it did happen. If I had not studied CS, I would never have come in contact with most of these topics (i.e., functional aspects - lambda calculus etc., logic programming (as in prolog or constraint programming), theoretical CS (temporal logic, complexity theory etc.) and so on and so forth. Even our even then very old-fashioned Compiler courses were benefitial at one point for me... ;)
AnoE
CC BY-SA 4.0
2021-11-02T09:59:37.320Z
That said, if you are just thinking in terms of increasing the worth of your CV, a more practically oriented course might maybe be more efficient, hard to know. If I'm looking at applications, I am looking at the whole picture, not just the degree.
AnoE
CC BY-SA 4.0
2021-11-02T16:32:10.903Z
Thank you, I appreciate the answer.
Hashim Aziz
CC BY-SA 4.0
2021-10-27T14:28:55.577Z
2021-10-27T14:28:55.577Z
AnoE
<p>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.</p>
<p>If you are lacking an idea of what to build you could try:</p>
<p><a href="http://www.raytracerchallenge.com/" rel="nofollow noreferrer">http://www.raytracerchallenge.com/</a></p>
<p>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.</p>
<p>If you are willing to spend some additional dollars you might also want to check out the Live Projects from Manning:</p>
<p><a href="https://liveproject.manning.com/#catalog-list" rel="nofollow noreferrer">https://liveproject.manning.com/#catalog-list</a></p>
<p>They often run promotions where they cut prices by ~50%.</p>

CC BY-SA 4.0
2021-10-27T11:14:00.370Z
Those are some very interesting resources!
Ben I.
CC BY-SA 4.0
2021-10-27T08:32:13.173Z
2021-10-27T18:10:28.123Z
2021-10-27T18:10:28.123Z
b0wter
<p>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.</p>
<p>How do I learn to code to make projects? I can make small programs easily. I can't use programming to create good stuff.</p>
<p>What should I start with? Recommend a book and course that teaches me enough to get started with projects.</p>

CC BY-SA 4.0
2021-10-26T06:32:28.473Z
Are you looking for web programming?  Mobile apps?  To get involved in an open source project?  "Projects" is very vague.
Ben I.
CC BY-SA 4.0
2021-10-26T06:41:28.450Z
I mainly want to learn to code projects. ie know programming basics enough so that I can be able to learn any technology and make projects. It could be web dev or android dev as most jobs are there in these fields. I feel like my programming basics aren't strong enough.
iwabawxoiu
CC BY-SA 4.0
2021-10-26T11:05:23.730Z
What level are you in your education. Secondary school? University?
Buffy
CC BY-SA 4.0
2021-10-26T11:19:53.880Z
@buffy University, studied CS concepts in college as I am doing cs degree.
iwabawxoiu
CC BY-SA 4.0
2021-10-26T17:01:57.303Z
Try an internship.
Bergi
CC BY-SA 4.0
2021-10-26T18:44:28.033Z
Cross-posted: https://cseducators.stackexchange.com/q/7094/1106, https://cs.stackexchange.com/q/145123/755.  Please [do not post the same question on multiple sites](https://meta.stackexchange.com/q/64068)..
D.W.
CC BY-SA 4.0
2021-10-26T19:11:57.233Z
Where exactly is the line between "small programs" and "good stuff" in your opinion?
Philipp
CC BY-SA 4.0
2021-10-26T19:12:39.510Z
@D.W. How do you always find these cross-posts?  Do you just make it a point to check on the network behavior of new posters?
Ben I.
CC BY-SA 4.0
2021-10-26T19:47:44.753Z
@BenI., something like that, but only for a small fraction of posts based on my experience.
D.W.
CC BY-SA 4.0
2021-10-26T20:37:52.523Z
https://projecteuler.net/ is a great way to get some practice in.
Stephen
CC BY-SA 4.0
2021-10-27T10:14:01.423Z
Big projects are often just small projects that got bigger and bigger and bigger.
Criticize SE actions means ban
CC BY-SA 4.0
2021-10-27T16:35:25.250Z
I wouldn't really expect any CompSci undergrad to have the faintest idea how to approach any kind of large project - 3 years at any university (even the very best ones) barely scratches the surface.    See https://norvig.com/21-days.html  -- The "10000 hours" estimate is a bit rough but also fairly realistic;  most programmers need many thousands of hours to gain the skills which would progress them beyond a 'Junior' stage in their career.  (e.g. 3 years at University plus 2-3 years working professionally)
Ben Cottrell
CC BY-SA 4.0
2021-10-27T16:43:03.777Z
I don't plan to post this as a answer. In your title you note `don't know how to code projects`. OK so find a current project you like, e.g. something from GitHub that is some what complex but not over your head. Then pick a programming language you like or would like to learn and translate the project into that programming language. If picked correctly you will have to learn about what I refer to as the ethos of both programming languages and in translating the code will understand what it takes to code projects in both languages. HTH
Guy Coder
<programming>
I am a CS student, but I don't know how to code projects. How do I learn this?
# I am a CS student, but I don't know how to code projects. How do I learn this?

(Asked by: username_0 on 2021-10-26)

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.

**Tags:** programming

> **Comments:**
> **username_1**: Are you looking for web programming?  Mobile apps?  To get involved in an open source project?  "Projects" is very vague.  
> **username_0**: I mainly want to learn to code projects. ie know programming basics enough so that I can be able to learn any technology and make projects. It could be web dev or android dev as most jobs are there in these fields. I feel like my programming basics aren't strong enough.  
> **username_2**: What level are you in your education. Secondary school? University?  
> **username_0**: @buffy University, studied CS concepts in college as I am doing cs degree.  
> **username_3**: Try an internship.  
> **username_4**: Cross-posted: https://cseducators.stackexchange.com/q/7094/1106, https://cs.stackexchange.com/q/145123/755.  Please [do not post the same question on multiple sites](https://meta.stackexchange.com/q/64068)..  
> **username_5**: Where exactly is the line between "small programs" and "good stuff" in your opinion?  
> **username_1**: @username_4 How do you always find these cross-posts?  Do you just make it a point to check on the network behavior of new posters?  
> **username_4**: @BenI., something like that, but only for a small fraction of posts based on my experience.  
> **username_6**: https://projecteuler.net/ is a great way to get some practice in.  
> **username_7**: Big projects are often just small projects that got bigger and bigger and bigger.  
> **username_8**: I wouldn't really expect any CompSci undergrad to have the faintest idea how to approach any kind of large project - 3 years at any university (even the very best ones) barely scratches the surface.    See https://norvig.com/21-days.html  -- The "10000 hours" estimate is a bit rough but also fairly realistic;  most programmers need many thousands of hours to gain the skills which would progress them beyond a 'Junior' stage in their career.  (e.g. 3 years at University plus 2-3 years working professionally)  
> **username_9**: I don't plan to post this as a answer. In your title you note `don't know how to code projects`. OK so find a current project you like, e.g. something from GitHub that is some what complex but not over your head. Then pick a programming language you like or would like to learn and translate the project into that programming language. If picked correctly you will have to learn about what I refer to as the ethos of both programming languages and in translating the code will understand what it takes to code projects in both languages. HTH  

---

## 6 answers

### Answer by username_13 on 2021-10-27. Score: 24

# Computer Science vs. Programming

> 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"](https://quoteinvestigator.com/2021/04/02/computer-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 comput**ation**, not the science of comput**ers**. 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.

# … and Software Engineering

> 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.

# Books that teach Programming

> 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)*](https://htdp.org/). 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](https://htdp.org/2003-09-26/) as is an early draft of [*How to Design Classes*](https://felleisen.org/matthias/htdc.html).

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](https://Gustavus.Edu/+max/concrete-abstractions.html) 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*](http://MITPress.MIT.Edu/sicp/) 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.

# Learning Programming vs. Learning Programming Languages

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.

# How to learn Software Engineering

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)*](https://wikipedia.org/wiki/Software_Engineering_Body_of_Knowledge) and the [*Software Engineering 2004 (SE2004)*](https://wikipedia.org/wiki/Software_Engineering_2004), 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*](https://agilemanifesto.org/) and the [*Twelve Principles of Agile Software*](https://agilemanifesto.org/principles.html) and the [*Manifesto for Software Craftsmanship*](https://manifesto.softwarecraftsmanship.org/). 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.

# Deliberate Practice

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.

# Kata

Some people swear by so-called [*Code Kata*](http://codekata.com/). 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.

# Mentorship

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](http://blog.coreyhaines.com/) did, who actually spent the better part of a year on something akin to traditional [Journeyman Years](https://wikipedia.org/wiki/Journeyman_years), but it wouldn't be the worst way to learn either.

# Programming Languages

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.

# Paradigms

Peter van Roy has made a nice [poster with the 34 most important Programming Paradigms](https://www.info.ucl.ac.be/%7Epvr/paradigms.html). A more thorough explanation of that poster is contained in the article [Programming Paradigms for Dummies: What Every Programmer Should Know](http://WWW.Info.UCL.Ac.Be/%7Epvr/VanRoyChapter) 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*.

# Concepts

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](http://WWW.Info.UCL.Ac.Be/%7Epvr/book). ([Here's the companion wiki.](http://CodePoetics.Com/wiki/)) CTM uses the [multi-paradigm Distributed Oz programming language](http://WWW.Mozart-Oz.Org/) to introduce all the major programming paradigms.

My own experience has been that *really* understanding a programming paradigm is only possible

* one paradigm at a time and
* in languages which *force* you into the paradigm

# Learning Concepts through Paradigms through Languages

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:

* **object-orientation in general**: [Self](http://SelfLanguage.Org/)
  + **prototype-based object-orientation**: Self
  + **class-based object-orientation**: [Newspeak](http://NewspeakLanguage.Org/)
    - **static class-based object-orientation**: [Eiffel](http://Eiffel.Com/)
  + **multiple dispatch based OO**: [Dylan](http://WWW.OpenDylan.Org/)
  + **functional + object-orientation**: [Scala](http://Scala-Lang.Org/)
* **functional programming**: [Haskell](http://Haskell.Org/)
  + **pure functional programming**: Haskell
    - **lazy pure functional programming**: Haskell
  + **static functional programming**: Haskell
  + **dynamic functional programming**: [Clojure](http://Clojure.Org/)
* **imperative programming**: [Lua](http://Lua.Org/)
* **concurrent programming**: Clojure
  + **message-passing concurrent programming**: [Erlang](http://Erlang.Org/)
* **metaprogramming**: [Racket](https://racket-lang.org/), [Scheme](http://Schemers.Org/)
* **language-oriented programming**: [Intentional Domain Workbench](http://IntentSoft.Com/), unfortunately defunct; try [JetBrains MPS](http://jetbrains.com/mps/) instead

# What about syntax?

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.

> **Comments:**
> **username_2**: Other than the fact that this will probably bury the OP, this is pretty awesome.  
> **username_13**: I freely admit that most of these are pre-made soapboxes I have preached on before that I just pulled off my shelf. (Have I strained the metaphor enough?) One soapbox that I left out is Project Euler and friends, which I find to be interesting *Maths* exercises, but, at least for me, don't seem to be doing much for *programming* and certainly not for software engineering.  
> **username_3**: I think this answer would be better without the lists of "paradigms" and "concepts", which seem arbitrary. Otherwise, right on the point! Regarding language concepts, [7 languages in 7 weeks](https://pragprog.com/titles/btlang/seven-languages-in-seven-weeks/) is also popular  
> **username_14**: *"in German, it is called Informatik, in French informatique, in Italian informatica – all are a portmanteau neologism based on information and mathematics"* Every single source I've read about this says the word comes from "information" and "automatique", not "mathematiques". Etymologically, "Informatique" is about automated processing of information.  
> **username_13**: @username_14: Interesting. Both according to Wikipedia and Wiktionary, the term *Informatik* was coined by Karl Steinbuch, shortly before he became a professor in Karlsruhe. I studied in Karlsruhe under a professor who was himself a student under Steinbuch. He was the one who told us that. But actually, according to both Wikipedia and Wiktionary, we are both wrong, and Steinbuch simply added the Greek suffix *-ik* with no special reference to either mathematics or automatic.  
> **username_15**: The best answer about the industry/discipline I've ever seen on SE and something I've personally been wondering about for a while, especially about the difference between the different degrees; thanks for this and please don't get rid of the paradigms and concepts part. Is there a good resource for learning all of the "concepts" in either Object-Oriented Programming or Functional Programming?  
> **username_16**: There is no "Greek suffix _-ik_ for what it's worth. I think you are thinking of [the Latin suffix _-icus_](https://en.wiktionary.org/wiki/-icus#la) which is cognate with the Ancient Greek suffix _-ikos_, but _-ik_ isn't a thing as far as I know.  
> **username_17**: Just a note that Berkeley's cs61a course is based off a version of SICP and has its lectures, labs, hw, projects, etc entirely online for past semesters, which can be useful to go through alongside the book - see cs61a.org.  
> **username_17**: I would also be interested in your thoughts on Code Complete as a software engineering text, as I've seen it recommended a lot but never made it through the whole thing (partly because I started reading it well before I actually needed it.)  

---

### Answer by username_1 on 2021-10-26. Score: 13

My advice is not too dissimilar from username_2. 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!


---

### Answer by username_10 on 2021-10-26. Score: 9

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](https://projecteuler.net/). 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](https://docs.python.org/3/reference/).

After that you can pick up on what the others suggested, like joining an Open Source project, etc.

Best of luck to you!

> **Comments:**
> **username_11**: This is by far the best suggestion, all these "JuSt CoNTrIbUtE To OpEnSoUrcE!" answers are way too naive.  You can't "just" contribute to open source.  If you don't understand real code, you won't easily be able to navigate their codebase.  And the sense of accomplishment is probably *far far off*.  With puzzle challenges (and I'd recommend Advent of code as well) you get a lot quicker with the gratification loop and are encouraged to program more in a much simpler easy to verify environment (even if the challenges themselves are hard).  
> **username_12**: While good advice, solving programming challenges seems unrelated to _projects_ as I understand them. I'm guessing OP wants to make a "real" application, like a game, web app, mobile app, etc. Algorithm challenges are solved with tiny scripts that run on the command line and can be solved with 20-30 lines of code seem disjoint to making apps. OTOH, open source projects are far too intimidating and prohibitive to get involved with -- _too_ real.  

---

### Answer by username_2 on 2021-10-26. Score: 4

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.

> **Comments:**
> **username_18**: "The professor that teaches architecture probably has a machine specification that can serve as the basis." I suspect you might be showing your age a bit there, username_2. What university would teach Assembly code nowadays, when nobody in industry uses it anymore?  
> **username_2**: The purpose of building a machine simulator isn't to learn assembly language program, @username_18, but to get an idea of how low level computation actually works. Building a Turing Machine simulator is also valuable for learning, but has little "practical" use.  
> **username_12**: @username_18 Almost all universities I've known teach assembly nowadays. Why? It's foundational to how computers work. It's untrue that _nobody_ in the industry uses assembly. Sure, if your goal is to make React apps, assembly is not helpful and in that sense, I understand your point. Universities still teach CS and deeper knowledge than exclusively "just get me a job ASAP" skills, although they do that too.  

---

### Answer by username_19 on 2021-10-27. Score: 4

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:

* I programmed a moderately simple 3D modelling tool (I daresay you would call it CAD these days).
* ... made my own version of Breakout.
* ... programmed a client-server 2D isometric multiplayer game (you would call it ARPG today, or if there were ever more than 2 players online for the very short time the servers were running, an very small MMORPG), including the net code, an integrated scripting language, and all the tooling, everything from scratch.
* ... a tool which would parse a hypothetical programing language and displayed the internal representation as a graph on the screen (combining topics from Compiler Theory and Graph Theory)
* ... (one of my favourites) a floppy disk utility for an 8 bit computer, written in assembler, and includinf a lot of low level features including a disk formatting routine. You get one try at guessing how I lost the source code to this application eventually.
* ... used Prolog to make a tool to ... don't know what it was, maybe putting pupils into classes.
* ... worked on a popular open source rogue-like game (similar to Nethack), ported it to a fringe OS and maintained it for some time.

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.

> **Comments:**
> **username_15**: I'm currently in the same situation as you prior to your CS degree, and am deciding whether to study CS or something else. Do you think the CS degree was worth it in the end, or do you think you might have benefitted more from doing something like Software Engineering, or even just studying online programming courses?  
> **username_19**: For me it was perfect. I find almost all CS topics very interesting, and while the occasions where I could really apply the knowledge from those studies were very sparse in the last decades, occasionally it did happen. If I had not studied CS, I would never have come in contact with most of these topics (i.e., functional aspects - lambda calculus etc., logic programming (as in prolog or constraint programming), theoretical CS (temporal logic, complexity theory etc.) and so on and so forth. Even our even then very old-fashioned Compiler courses were benefitial at one point for me... ;)  
> **username_19**: That said, if you are just thinking in terms of increasing the worth of your CV, a more practically oriented course might maybe be more efficient, hard to know. If I'm looking at applications, I am looking at the whole picture, not just the degree.  
> **username_15**: Thank you, I appreciate the answer.  

---

### Answer by username_20 on 2021-10-27. Score: 2

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%.

> **Comments:**
> **username_1**: Those are some very interesting resources!  

---

