What-are-some-of-the-most-basic-things-every-programmer-should-know

2020-01-26

Word count: 1.5k | Reading time≈ 9 min

Calling a function from within a loop is no more efficient than running all the function’s code within said loop.
Executing a loop of N iterations inside a loop of M iterations will consume at least M times as much time as executing the loop of N iterations once.
Numeric values are not inherently binary, hexadecimal or base-10. A numeric value is the same no matter the base in which you choose to express it. Therefore it doesn’t make sense to ask how to convert an integer value to binary, only how to express it as binary.
One byte is 8 bits and can represent 256 values. The number of values any variable can represent is determined by 2^n where n is there number of bits reserved for the variable
Retrieving and removing a value from a stack is called popping and returns the most recent value added, while retrieving and removing a value from a queue is called dequeuing and returns the oldest value.
A 1-dimensional array of X bytes consumes at least X bytes of memory. A 2-D array of X-by-Y bytes consumes at least X*Y bytes of memory.
A 2-dimensional array is basically the same as a 1-dimensional array whose values are accessed by calculating the index with Ywidth+X. *Edit:** My point here is not that all 2 dimensional arrays are really just 1-D arrays. My point is that a simple 2-D array of 2 fixed dimensions can generally be implemented with a 1-D array.
Printable text in a program is generally referred as a string. Every character in a string generally takes at least 1 byte.
Unicode is a standard that allows most known characters in all languages around the world to be represented by a single coding scheme. (There’s much more to know here, but not all of it is basic and understood by all programmers.)
UTF-8 is a Unicode encoding scheme that allows the most common Latin-based characters to be represented in 1 byte, while other characters can take 2 or more bytes.
If it’s not tested, it doesn’t work.
Source control is your friend - make sure you use it.
Just because you wrote it doesn’t mean you own it — don’t be offended if someone else on your team has to change your code.
Don’t reinvent the wheel, library code is there to help.
The fastest code is code that’s never executed — look for early outs.
Just because you didn’t write it doesn’t mean it’s crap.
Source code is just a hint to the compiler about what you want to do, it won’t necessarily do it (e.g. You might declare a function as inline but the compiler doesn’t have to obey).
Code that’s hard to understand is hard to maintain.
Code that’s hard to maintain is next to useless.
“Whilst I’m editing this file I’ll just…” is a great way to introduce feature creep and bugs.
The neater your code layout, the easier it is to read. The easier it is to read, the easier it is to understand and maintain.
Code is not self documenting. Help others by adding comments to guide them. You may understand it now but what about in 5 years time?
Bad Code can and will come back to haunt you.
There is no such thing as a 5 minute job. It’ll always take at least half a day.
Magic numbers are bad.
Constants don’t take up storage, they’re compile time text substitutions.
Project management will always want you to do twice as much in half the time.
If there is a bug, the user will find it.
A code review is not a criticism.
It’s not the quantity of code that matters, it’s the quality. Any idiot can bang out 40kloc but that doesn’t make it fit for purpose.
The true cost of poorly written code is in the maintenance.
Eat your own dog food — fixing bugs in your own code helps you code better and improves your understanding.
Code rots over time.
If the user didn’t ask for a feature, don’t add it.
If it’s not tested, it doesn’t work (yes, I know I’ve included that twice but it’s really important).
Networking basics - ssh tunnels, subnets, basic routing tables, TCP protocol, HTTP basics.
Memory - probably should know a little about how memory is laid out, virtual addresses, paging, page frame; user space and kernel not details - but just an accurate higher level idea.
Basic Data types and their sizes (uint, float, string, character/rune etc.
If you are in JVM or any runtime oriented landscape probably should know how GC overall works; generational collection in JVM is interesting to follow. Mark and sweep.
Basic and extremely practical knowledge of data structures and algorithms - you need to be able to apply things you’ve learned - I know many people who know all theory in the world but to them it seems no problem can be applicable to any catalogue full of algorithms and data structures they know off. Linked lists, stacks, queues, trees and graphs and some of the basic algorithms of sort, search etc.
Working knowledge of computer hardware - if leave this to readers; I prefer to understand a lot of details.
You probably should be proficient in one of those editors like Vim, Emacs, Sublime, IntelliJ, Eclipse (any but one) …
Should be able to step through code. (Think gnu tool chain, gdb, IntelliJ debuggers for Java world for example).
Understand relational calculus a bit - write sql queries . Know what is and how to use a relational DB - and a NoSql Db.
Know what files are and how file system works in general from kernel and user space view points - understand why IO is a bottleneck - good if you know scatter gather, mmap and other voodoo ;-)
Functional programming - know functions as data, first order functions, higher order functions, map, flatMap/bind, fold. You do not need to be a Haskeler or a Lisper for this. Fairly common to have such constructs in most modern languages today.
Understand what pointers are (if you are in JVM world ignore this but it would still be worthwhile to know); and how things are allocated and accessed.
Know about threads - Green threads, Coroutines; how concurrency maybe managed and how does it translate to core utilization.
Knowledge of HTML5 canvas and other simple constructs.
CSS Box model and general CSS
Knowledge of ES 6 fundamentals.
Knowledge of Node package manager and a JS build system
There will always be someone somewhere, you’d write a better code
Always test your code, for both, usual cases and edge cases
Never trust the user input, always sanitize it
Always check for buffer overflows
Leave the code better than you got it
You will spend more time thinking about the code, than actually coding
A bad design will haunt you as soon as the requirement changes even slightly
Under-commit and over-deliver, always
Your success will depend more on your soft-skills and how you articulate the problems and solutions to them, than your technical ability
When asked for an estimate on a feature, always overestimate for a 20% buffer
Do not get emotionally attached with the code. The fact that you wrote it does not mean that someone else cannot change it
You’ll see a few of your prototype implementations (POCs) making it to the product, and a lot of them being scrapped, don’t take it to heart, that’s the way things work
Use source control, and do frequent commits (squash commits before pushing to remote), it will save you in case of a disaster
Bad code will come back to haunt you in future
Take code reviews positively. Do not get into a code review with an ego, take review positively and learn to improve
Learn to read between the lines from the business requirements and try to convert them into technical requirements
It is a good idea to discuss your solution with another programmer before starting to implement it, you might learn more
Always document the code well, it will help others (including yourself) in the future
Improve your skills over time, otherwise you will become obsolete in the industry
Your QA folks should be your friends, that will save you a lot of trouble
Try going into meetings with solutions to problems, rather than just problems, your folks will start liking you
Never, ever, push a feature in production unless it is well-tested
Love your job, but not your company, you never know when your company might stop loving you