Source: https://www.facebook.com/MITCSAIL/posts/10159858010977710

• Find someone whose code looks better than yours, and get them to do code reviews for you.

• Build the logic first , understand the purpose and then write neat and clean code.

• Trichotomy… 1. get playing and poking fun at the draconian constraints imposed on machine language use and 2. know what you want to do and torture the code into “best practices” and 3. invent new best practices for solutions in the problem space you address. 4. make your own language layered atop the trichotomy, or 5. write machine code to access the full power of the chip set. Manuals are for reference.

• Don’t write the whole thing and then expect it to work. It won’t. Develop it in small increments. Test as you go. Keep the program error-free after each increment.

• one of my advisors told me once “programming is copy and paste” alluding to the fact that some code is repeated and/or moved from place to place. Later with the code repositories such as stackoverflow the copy/paste advice is even more relevant than before.

• If you don’t understand why it works, it probably doesn’t work.

• The less code the better, and if you must produce code, error out loudly if intentions / conditions are not met. The worst code is the one that’s hard to debug. The truth about software is, you’re usually wrong, you just don’t know it yet.

• Code and then refactor. Before refactoring, track the refactoring task. Refactoring is learning.

• Try Python if you haven’t

• Dont think of code as code, think of it as a list of stuff

• Loop variables need not be always named i, j, k, and so on… Any legal variables will work! (Trust me. I had to explain the same concept to some people during my teaching times)

• Naming things is one of the hardest tasks. Don’t try to over simplify names, it doesn’t matter if the name of something is a bit long, but descriptive and understandable.

• Write libraries in one go without debugging. Troubleshoot the typos and bugs after. It leads to the occasional debug nightmare, but I find it much easier to split conception and debugging mode. It also feels really good when things just magically works after just a few typos fixes.

• Always ask for help if you can, don’t just look at the screen hopelessly

• dont take advice from udemy educated “scholars” and coursera evangelists

• Write code that is easily understood, if it isn’t then break it into easily understood parts

• Never use ‘test’ as your program name for MPI. It’s a reserved word, and the program wouldn’t compile

• Have a lot of practice of general programming and problem solving, before focusing on tools and frameworks.

• Making code simple and elegant is much more difficult than writing ugly, convoluted code.

• Coding is recoding.

• Start you day with solving hardest problems you have in the calmest place you can find.

• Don’t loose heart, if you can’t make it work for sometime.

• If it works, don’t touch it.

  

• Learn to google/search

• Use a duck to debbug

• Never assume that something is working right.

• Code a lot

• Write code 1st and foremost for humans to read, and only second for the computer. If a human can’t read the code, and it’s not documented how the code works, then the code doesn’t exist, because no-one else can maintain it or build upon it.

• Don’t mix up the dits with the dahs.

• Divide and conquer.

• First try to characterize the problem for which you are writing the code. This would clarify the logic of the program. Then after writing the code place yourself in the position of the computer and see the results of execution.

• Never take warnings lightly.

• never use while() loop → comment: why not? It’s still good if in a suitable case

• If agile methodologies and its ceremonies come in the way of delivering software, let agile go.

• Keep it simple and practical so that someone else can follow the thought process.

• Don’t debug after 2AM!

• Be sure about the requirements. Code that is effective but does not meet the requirements will not serve the project.

• Be concise but readable

• Draw state diagrams.

• Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. https://comic.browserling.com/79

• Keep it simple and stupid

• Always write clean code that you may understand even when reading the same after ten years.

• document your code

• Always write production level code. Even if it is POC or just a test.

• Always practice clean code and do proper documentations every time… adopt software engineering methodologies and always go back to basics in case something is amiss. Code reviews are good standard practice in software development. Avoid egoistic programming…

• your first complete version needs to generate the required output. elegance and performance do not matter. that version becomes the reference for testing. then you evolve it into elegant, understandable code. its output should match your reference. then you go for performance improvements as needed, leaving the understandable code in the source, still compilable, but unexecuted.

• Write it as if you’re writing a best seller

• Read documentation before you search through internet.

• The devil is in the details

• Never rush extensively the software development process. You will need much more time and resources later to face the implications. hackathons aim for code speed. They do not consist of the typical development process and the code produced is certainly unmaintenable and tested only under a specific context.

• Don’t take advice just code!!!

• CIAL (Code is a Liability) https://github.com/kelseyhightower/nocode

• keep a clear mind and think about the code.

• If it works don’t touch it and print statement is your best friend.

• Learn coding from here: https://github.com/georgegognadze/awesome-resources

• RTFM and think before coding. “think” is aided by tools and techniques whether pseudo-code, state diagrams, flow charts, design methods — whatever works for you

• Learn how to read code, at a job there is a great chance that you’ll read code more than you write it.

• Let the computer do the coding after you tell it the goal… this is the future.

• Understand the requirements before you start coding. Balance the complexity of the code against the complexity of the data structure(s). Test every single change. Build scaffolds to simulate live data. Have one coding style for everything you write. Write clear, simple code. Write code you can be proud of.

• Be analytical

• Don’t do coding