Coding Ninja

Code like a Ninja — but how?

Code like a Ninja — but how?

Here are some tips I’d like to share from my 4 decades of coding. This list began life in another article I wrote, but I realized it is worthy of being it’s own living thing (expect updates in the future).

  1. Don’t stop learning. There is always something to learn in this field.
  2. You may struggle less if you have at least a basic understanding of binary and logic gates. You don’t need to be able to build a computer, but it is helpful as a programmer to appreciate conceptually how a computer works. If you are completely new to this field, logic gates by themselves may not “click” — until perhaps, you understand how they might be connected together to do math — which is at the heart of what a computer does. This video may help. To this day, I still find this little trick magical.
  3. Stay active. Just like fitness, if you don’t use it, you lose it. Keep practicing. Coding katas are a great way to stay sharp. Codewars is a great resource to practice.
  4. Learn from others. They will likely have different opinions and perspectives to you. You don’t always have to agree — but stay open to new ideas.
  5. Watch for the trap of perfection. Don’t be sloppy — but know when to stop.
  6. Make it work first, then make it pretty (re-factor), then and only then make it work fast (if needed).
  7. Ditch the Ragu and cook from scratch. Modern languages, frameworks and libraries are wonderful and make you highly productive. They can appear magic. Dig deeper and try and understand the magic. For example, learn 3D graphics by avoiding libraries and GPUs and just code it from scratch at the lowest level possible. Do your own matrix multiplications, use your own data structures. For AI, avoid using ML libraries and try coding a single neuron from scratch. Write your own linked list. This may seem like re-inventing the wheel — it is. Just use the approach temporarily to solidify the concepts. Then, move to using the fancy libraries and frameworks once you have a better understanding of what they do for you.
  8. I have yet to discover a single paradigm to rule them all. Functional Structured and Object Oriented remain useful to this day depending on the problem you are looking to solve. Study the paradigms and you will find learning a new language becomes much easier.
  9. Similarly, the quest for a general purpose language to rule them all is as yet unresolved. With the rapid advances in AI, perhaps it will be natural language after all (at least for the “fuzzy” problems). Perhaps it will happen sooner than you think.
  10. When learning a new language, it’s more fun and rewarding if you use it to solve a problem you are facing.
  11. If you are already proficient in one language, consider re-writing it in another language.
  12. As you build up a repertoire of languages, use the one that is the best fit for the problem you are trying to solve.
  13. Learn by doing. You cannot learn tennis by reading a book.
  14. Be patient with yourself. If you are not finding any joy in the process of writing code and solving problems — perhaps the career of a software engineer is not for you. That’s ok — it’s not for everyone. Your talents lie somewhere else. At least you have tried it out which is better than wondering what if.
  15. Consider learning at least one functional programming language, one object oriented language, one assembly language and one systems programming language. This will give you a good grounding and enable you to quickly learn new languages. I recommend Haskell (functional), Python [ 1 ](object oriented), 8086 (assembly language) and C (system programming language). It’s not essential for you to learn assembly language — but if you want to learn something like C, I think learning assembly first will definitely help you understand pointers in C.
  16. Study imperative vs declarative approaches to programming.
  17. If you are an absolute beginner, or you want to introduce your child to programming, I recommend a visual programming language such as Scratch from MIT. The syntax of a traditional text-based programming language may be a barrier too high.
  18. Python is a great place to start if you are looking for your first language to learn (I don’t recommend BASIC — it’s not 1983 anymore). Python is unusual as it is both a great educational [ 2 ] language and is very widely used in industry [ 3 ].
  19. AI assistants, such as GitHub CoPilot are useful but only once you have achieved some proficiency in the language. I would recommend not using them while you are learning a language.
  20. Be wary of camps and tribes. Software engineers can get very opinionated and passionately defensive of the tools and languages they use. I was one of those. I would proclaim “Java is too slow. It’s Just Another Version of Algol. C++ is far superior” — only for me to wind up switching to Java a year later. Try and rise above the flame-wars and instead focus on solving problemsAs you progress, be sure to dive into the world of algorithms. For example, consider implementing a sorting algorithm or two. You will discover that the genius of software is not really in the language or the code itself — it is in the algorithm. You will also venture into the adjacent world of data structures as a bonus.
  21. As you progress, be sure to dive into the world of algorithms. For example, consider implementing a sorting algorithm or two. You will discover that the genius of software is not really in the language or the code itself — it is in the algorithm. You will also venture into the adjacent world of data structures as a bonus.
  22. Take small baby steps. Code a little, test a little, repeat [ 4 ]. Get your feedback loops running as fast as possible. When things break, and they will break you will avoid hours of debugging what went wrong.
  23. As you progress — don’t forget your tests! Be pragmatic — if you are just exploring, learning, experimenting — it’s ok to not worry too much about tests, code structure and quality. However, if the code you are working on will go to production and it needs to be maintained, tests are essential. Most languages have frameworks that support unit testing. Become familiar with them and use them. They will make your code better and you a better coder.
  24. Know that you will spend more time reading and debugging code (usually someone else’s) than actually writing new code from scratch. Debugging code can be very hard especially if it is not easily reproducible. Modern software is typically part of a large system made up of many layers and many components. Just like a detective, it is simply a process of elimination to find the culprit. When searching for a needle in a haystack, you have to make the haystack as small as possible. Carve out the area of code where you think the bug exists. Put this into its own little project? Why? So, you can speed up the feedback loop and try things out much faster. Would you prefer to wait 20 minutes for the build to complete or 2 seconds? It’s possible, although extremely unlikely [ 5 ] that the defect is in some 3rd party library or the compiler. If you do discover this is where the defect exists, that small little project you carved out to investigate can serve as a proof the defect exists you can send to the owner/vendor.
  25. We live in a hyper-connected world. The software you are writing is likely no exception. Ever since the Internet adopted TCP/IP 40 years ago, TCP/IP has become the networking standard. Learning the networking stack beneath the application layer will serve you well. You don’t need to become a network engineer, but being able to figure out why your software is failing to connect to another piece of software will get you closer to coding ninja status. This looks like a fun way to play with network packets.
  26. Know the one rule to rule them all
  27. Consider the world of art. Carving and Sculpting is mostly subtractive. Painting is mostly additive. A coding ninja is both a sculptor and a painter. When coding, be sure to subtract and eliminate code that is not adding value, is dead code or is no longer needed [ 6 ]. Why? it makes the code easier to comprehend, faster to debug and makes it more theoretically more secure [ 7 ].
  28. Learn to master the command line. IDEs come and go. Examples I’ve used over the years include Turbo Pascal, Visual Basic, Visual Studio for C++, Visual Age for Java, JBuilder, Eclipse, Atom and now Visual Studio Code. The command line has been my trusty companion [ 8 ] throughout my career. It continues to evolve and will continue to be my trusty companion in the future.
  29. Learn how to write code that is secure. This is a huge area worthy of it’s own list. Know the threats. Know thy enemy. Know the principles. Learn how to break things and not just how to build things. Study offensive security. Knowing how to attack things (ethically) will make you build things in a better way.
  30. Understand the basics of cryptography. You don’t need to (unless you want to) understand the mathematics that underpin cryptography, but understanding the basic concepts of symmetric, asymetric encryption and 1-way hashing along with understanding why and where they might be used to support the CIA triad will serve you well.
  31. Pay attention to and measure the health of your code. Know your numbers!
  32. Most of all. Have some fun!

Contributions

I’d like to thank the following Ninjas for taking the time to review and provide suggestions to the list:

Tom Gagnier Joey Gibson Ryan Hofschneider

. . .

[1]: — Python is not necessarily considered an object-oriented programming language — it does however support the object-oriented paradigm. It is what is considered a multi-paradigm programming language.

[2]: - Python is used for Stanford’s Code in Place program (of which I am a volunteer)

[3]: - Python is one of the most popular programming languages on the planet.

[4]: - “There are mountains in our way, But we climb a step every day” — lyrics from “Up Where We Belong”, Joe Cocker and Jennifer Warnes

[5]: - In my 40 years of coding, I have only discovered one defect in a (C) compiler. I found it by inspecting the assembler generated by the compiler.

[6]: - “A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.”, Antoine de Saint-Exupery

[7]: - Smaller code has a smaller attack surface area.

[8]: - Shells have evolved. I started with csh, then ksh, then bash. I had a good run with bash for many years. Several years ago I switched to zsh. And beacuse I’m lazy my goto today is “oh my zsh”.