4 ms·
I am a computer scientist and a computer engineer. I recommend that you learn to code first. After that, the motivation behind the computer science is a lot m
by dswilkerson 4y ago
I am a computer scientist and a computer engineer. I recommend that you learn to code first. After that, the motivation behind the computer science is a lot more clear and you will learn it much more easily.
Learning to code means:
* Absolutely learn to type correctly and without looking; if you are not willing to do this, then do not bother with this field.
* Learn one editor really well; most people who are serious use gnu emacs or vi (vim?); I use gnu emacs.
* Learn a revision control system; these days, everyone will expect you to know git; get a github account, which is really cheap, and put all of your projects there; it makes it easy to collaborate with others; learn the correct way to write git commit messages.
* Start with the C programming language and the build tool gnu make; have someone show you how to write a simple makefile to build your projects.
* Have someone show you how to compile using, say, gcc so that the compiler outputs the assembly files (.s) annotated with the C input: https://stackoverflow.com/questions/137038/how-do-you-get-assembler-output-from-c-c-source-in-gcc https://stackoverflow.com/questions/137038/how-do-you-get-as...
* Write lots of little C programs and compile them and look at the assembly langauge with the C input interleaved with it.
* Maintain all of that in a github repository named, say, c-examples; write regression tests and run them every time you change anything.
* For any code repo you have called, say, foo, make another github repo called foo-notes; maintain a todo list in that repo, possibly in mulitple files; also maintain a list of relevant notes related to the project; also maintain another file or files of proposed changes or future work; doing this makes it easy to coordinate with others; DO NOT PRETEND TO KEEP EVERYTHING IN YOUR HEAD.
* Go through a book on C, say, The C Programming Language, and for every feature they mention, write a little program using it and a test for that.
* Learn to write C and read assembly before going on to any other language.
* After getting fairly competent at C, get a data-structures book and implement all of the primary data structures, such as linked lists, hashtables, red-black trees, etc.
* Build something you want, such as a tool to process your logs; you might want to use flex to process the input; write documentation for your project; if you put it in a file Readme.asciidoc in your repo, then github will run asciidoc on it and display it on the main screen of the repo.
Doing all of that, including learning all the idiomatic folk ways of doing things, like how to type without looking, how to write makefiles idiomatically, writing regression tests for everything you do, writing down EVERYTHING in the foo-notes repo, checking it off when done, etc. is a LOT of work; if you are not willing to do all of that, then pick a different field.
After you have built a few things, you might consider learning how the machine structures work, such as the memory hierarchy; learning this will help you write faster code. You might also want to study asymptotic analysis of algorithms which will help in picking the right data structure for a problem.
- ofalkaed 4y ago>Have someone show you how to compile using, say, gcc so that the compiler outputs the assembly files (.s) annotated with the C input: Never knew you could do this, not a single programming book that I have read has mentioned it. This is great and really helpful, thanks.
- dswilkerson 4y agoYou are welcome. Learning C is pretty straightforward when you know what it is doing: mysterious bugs are no longer mysterious. I think this notion of "information hiding" being helpful to people is ridiculous. Learn what the machine is doing at the bottom and then build up your understanding in layers.
- codingdave 4y agoHm. I've been doing quite well in this field for 30 years, and other than knowing git and having a github account, exactly zero of this applies to me. I'm not saying it doesn't apply to your corner of the industry, and I'm not saying that none of it is ever true, but it is far from universal advice, and definitely not a case of "if you are not willing to do all of that, then pick a different field."
- dswilkerson 4y ago> exactly zero of this applies to me You do not use a tool for managing the build of your program? You do not use a revision control system? You keep everything in your head? Really?