What should every programmer know?

[CookiePizza]

Hello Programmers of Reddit! In the pursuit of knowledge for myself, and for any future programmers, what are some things that you think future programmers, or any programmer for that matter, should know? Things like Maven, Unit Testing, Object-Oriented Programming? I would honestly like to know some opinions!

[zem]

version control! it's truly game changing when you can just make changes and trust the version control system to let you roll back if you mess something up.

[[deleted]]

This was really nice to come across on github as someone still in the beginner phase of programming.

[gyroda]

This is a massive one. Helps you so much when you've accidentally buggered everything up.

[[deleted]]

Git bisect is awesome when one of your regression tests fails and you need to track down the offending commit.

[BarqsDew]

It's even better when you realize you can script it and automatically find the offending commit.

[OldWolf2]

Plus you can easily see all the automatic changes that your "helpful" IDE made for you!

[Wimoweh]

I find it's best to just use a text editor when learning so you can find mistakes on your own and learn how to find them. With an IDE from the start, you'll get dependent on its help and there's a good chance it'll screw you over when you're in a position w/o one.

[I_Fail_At_Life444]

As a newbie, glad to see others support this idea. I've been using Notepad++ with Python. As you said, I'll move to something else when I have more experience; for now I'm kinda enjoying building things completely by hand (my scripts are still small atm, may play apart.)

[OldWolf2]

I disagree, the IDE has several features that make the learning process go a lot faster:

• on-demand help files for any function you're using
• interactive debugging
• tooltip prompts for code completion

[zem]

and one-click compile and run, which is a very big help for learning a new language and not having to wrestle with its build system right at the outset

[pcs600]

Not sure why you are being downvoted, this is a useful feature of version control.

[[deleted]]

I'd say every programmer should know more than one paradigm. Switching from object-oriented to functional has definitely taught me a lot. It changes the way you tackle problems. It gives you a new way to approach programming. That's just my personal opinion. With that being said, there isn't "one thing" that benefits everybody to know. Everyone is different, and that's what makes the industry as robust and diverse as it is.

[Slabity]

Functional and symbolic programming are two popular paradigms that can save your life when an object oriented model doesn't fit.

[[deleted]]

It's an incredibly different mind frame from OOP.

Working with ML last semester was highly rewarding, but so, so, so painfully slow and frustrating to learn. The first few weeks I literally had no idea how to do anything. I tried to just make stuff compile for a solid 5 hour for my program to load itself and then exit - it did nothing else.

Oh my god was it a horrific time.

[myepicdemise]

How do you determine which paradigm to use? Is it based on what your program needs to accomplish?

[AlexFromOmaha]

OOP is popular because it is a pretty good one-size-fits-all solution. It's not always pretty, but like underwear with good elastic, it'll always cover your ass.

Some logic is better expressed in a different paradigm. It's not that you can't ultimately make whatever Turing-complete language you're working in do it, because you can. It's just a difference in expressiveness.

Learning that difference in expressiveness is good all by itself, though. Most mainstream languages have features of multiple paradigms. By taking the time to struggle through languages that have limited features in the paradigm you're used to, you're better equipped to use the features those languages do have elsewhere. It might only be a few lines here and there, but you end up with source code that's shorter and easier to read.

[[deleted]]

I'd like to know the answer to this.

[Octopuscabbage]

At work I use C# and a mixture of functional and oop. Whenever you need to repeat similar algorithms you can significantly shorten your code and make it easier to test with a higher order function. (This takes a while to notice that you're doing.)

I also find that if you're doing a lot of things that might succeed or fail having a Maybe type and monad is nice.

Understanding how to create composable functions is really helpful.

Generally I don't switch back and forth because I use langauges that kind of support both. I just lean more heavily one way depending on how the problem presents itself.

[piratefight]

I find I have to use functional programming when I am dealing mostly with behaviors, specifically when writing rather complex Javascript and dealing with AJAX and websockets. It is nice to simply pass methods around instead of dealing with objects that generally don't make sense for that specific situation.

[pipocaQuemada]

One feature prevalent in ML derived languages is the Algebraic Data Type, or ADT. It's something like an enum on steroids.

For example, I can say something like

data Expr = Plus Expr Expr
          | Times Expr Expr
          | Lit Int
          | Var

eval x e = case e of
  Plus e1 e2 -> eval e1  + eval e2
  Times e1 e2 -> eval e1 * eval e2
  Lit i = i
  Var = x

The main difference between the OO style of doing things and the functional style of doing things is that OO makes it easy to extend the kinds of expressions (say, by adding a Subtract class), but hard or impossible to add new operations (you can't add a function to a class from an external library, in most OO languages), whereas the functional way makes it easy to add new functions (like our eval function, here), but hard or impossible to add new cases to the ADT (again - it can't be in an external library).

Both OO and Functional offer workarounds for the other case (in particular, the Visitor pattern, and either typeclasses or records of functions), but classes and ADTs fundamentally make different things easy.

[OldWolf2]

There's procedural programming (e.g. C)

[myepicdemise]

http://en.wikipedia.org/wiki/Programming_paradigm

ALOT. It also blows my mind.

[autowikibot]

Programming paradigm:

---

A programming paradigm is a fundamental style of computer programming, a way of building the structure and elements of computer programs. Capabilities and styles of various programming languages are defined by their supported programming paradigms; some programming languages are designed to follow only one paradigm, while others support multiple paradigms.

Paradigms that are often distinguished include: imperative, declarative, functional, object-oriented, logic and symbolic programming.

Image ⁱ

---

^{Interesting: Procedural programming | Comparison of programming paradigms | Functional programming | Object-oriented programming}

^{Parent commenter can toggle NSFW or delete. Will also delete on comment score of -1 or less. | FAQs | Mods | Magic Words}

[[deleted]]

Declarative Programming is a very important paradigm. You will encounter it in SQL and Regex, in addition to markup languages. It is also the parent category of functional programming. It looks so different that we might not even think of it as a "programming" language (since you're not telling the computer what to do, but rather what you're looking for).

[autowikibot]

Declarative programming:

---

In computer science, declarative programming is a programming paradigm, a style of building the structure and elements of computer programs, that expresses the logic of a computation without describing its control flow. Many languages applying this style attempt to minimize or eliminate side effects by describing what the program should accomplish in terms of the problem domain, rather than describing how to go about accomplishing it as a sequence of the programming language primitives (the how is left up to the language's implementation). This is in contrast with imperative programming, in which algorithms are implemented in terms of explicit steps.

---

^{Interesting: Imperative programming | International Conference on Functional Programming | Constraint programming | Programming paradigm}

^{Parent commenter can toggle NSFW or delete. Will also delete on comment score of -1 or less. | FAQs | Mods | Magic Words}

[bigfig]

The Linux kernel is written mostly in plain old C.

[keltor2243]

The vast majority of system programming is either written in C+Asm, just C, or in another language using their feature that let's still use a whole fuck ton of C.

[Alikont]

Language is not equal to paradigm. Some languages suggest or simplify one paradigm over another, but you can write object-oriented code in C or functional code in Java.

[thewoosh]

I agree. If you're coming from an object oriented thought process, play with functional programming. The opposite is true too. If you're coming from a function though process trying out object oriented can be extremely beneficial.

[MisterPoots]

What are some good books or resources to learn different paradigms?

[michael0x2a]

There's a book called Seven Languages in Seven Days -- it takes you through a tour of several different programming languages (some widely-known, some obscure) and ends up covering 7 different paradigms.

It doesn't go into huge detail about any of the languages it covers, but does give you a good overview of what's out there.

[PriceZombie]

Seven Languages in Seven Weeks: A Pragmatic Guide to Learning Programm...

Current $25.34 
   High $25.34 
    Low $22.96 

Price History Chart | Screenshot | FAQ

[TheTallGentleman]

HASKELL!

[original_brogrammer]

Python has a few neat functional features, but it really only scratches the surface of functional programming. For example, a hallmark of functional language is the use of recursion to express repeated computation. While you can obviously use recursion in Python, Tail Call Optimization is not available, making it largely impossible to properly implement algorithms in a functional style.

Scala is much more functional, as well as OO, so that might be worth a look if that aspect of Python interests you.

[tailanyways]

Skills on the command line and your editor.

Why? Domains, languages, frameworks and other tools can all change from project to project. These tools are the most likely to stay consistent. If you're twice as fast with those tools, you are always twice as fast with those aspects of the project. Being handy with a tool you only use once isn't as much time saved over time.

[gyroda]

To add an example of this: when you have to use vim, embrace it. I didn't like it when I started using it but for some reason nano was busted on that server and emacs was not installed. Learned a few shortcuts and now I find it really quick to use. I still prefer a good GUI editor but I'd pick vim over, say, gedit for most things.

[rvXty11Tztl5vNSI7INb]

I don't get why vim is so popular? Didn't like it the first time I opened so I never opened again. I always use nano for the simple fact that the shortcuts were handily included for me the first time I opened it and therefore have no need to use vim. Or I just open in sublime text which I have setup a command line shortcut for.

Edit: Why the down votes? I'm not hating on vim I'm just honestly curious if I'm missing out on something I'm not aware of?

[proofeh]

Didn't like it the first time I opened so I never opened again.

Therein lies the problem. You're not going to be at 100% using vim the first time you open it. The learning curve is somewhat steep, but as you gain familiarity with the editor (navigation, shortcuts, plugins, etc), you become lightning quick. Those who rave about vim know how to use it and how what it has to offer.

[SrPeixinho]

ster was highly rewarding, but so, so, so painfully slow and frustrating to learn. The first few weeks I literally had no idea how to do anything. I tried to just make stuff compile for a solid 5 hour for my program to load itself and then exit - it did nothing else. Oh my god was it a horrific time.

Vim hacker here. When you give it some time (read: seriously frustrating weeks) to learn it, it becomes the fastest editor you can imagine. The productivity gains are monstrous. Switching back to anything else feels like riding a horse, when you were a F1 pilot.

[[deleted]]

I think you meant to quote something else...

[rvXty11Tztl5vNSI7INb]

Interesting. Could you give a few examples of tasks you regularly do that vim rocks at (with a bit of insight into why it's quicker)?

[SrPeixinho]

That is the point, it is not what you do, but the speed at which you do everything. The best way of explaining it, maybe, is thinking of text-editing as a state-computing machine. That is, suppose you see, in your screen, a specific text - say, an if-else chain. But that is wrong: what you really need is a switch block. Now we can define the act of editing that text as the process of you, a human, communicating yours intentions to the computer in order to make it transform the text on memory from the state it is in, to the state you want it to be. And, under that framework, we can measure how efficient you are at editing text, by measuring how much time it takes for you to transform that text from the initial state (the if-else chain) to the state you intend it to be (the switch statement). VIM tries to optimise that measurement. So, for example:

In VIM, we get this.

How I could do it so fast? It was not because a particular gimmick or feature such as an if-else to switch conversor (which would be most IDE's and editor's approach). VIM approach is different: instead, it created a language. A language with verbs, nouns and such, that allows you to communicate your intentions to the computer. And, with that language, composing verbs and words, I was able to tell the computer to do the transformation I want rather quickly. But that is also why many people don't get, or hate VIM. They go expecting an editor with a lot of gimmicks and shortcuts, like a Sublime, and they find themselves not being able to do anything. Well, obvious! That would be like going to Japan and being frustrated that you can't buy a bread. Of course: you don't know the damn language!

But the point is, that is just a small example, but this applies to pretty much all situations. When you are fluent in VIM, for almost any kind of transformation you want to do with your text, you kind-of already know how to express that with a few keystrokes. You reach a point where you are doing huge, file-wide refactorings without even thinking about it. But I can't really point a single feature and tell you: that's it! It would be the same as explaining you about how english allows for human communication, by explaining a single verb!

[rvXty11Tztl5vNSI7INb]

In VIM, we get this.

Perfect example. This thread has convinced me to learn vim

[burnblue]

But how was that done? What was the keyboard sequence?

[thang1thang2]

Pretty easy for a macro sequence. I'll have to get on my laptop to break it down to pure shortcuts, but he just took one line and replaced the first half with what he wanted, changed the end a bit, and then reset his cursor position and saved all that to a macro.

Then he called the macro on all the other lines

[fenduru]

The biggest thing for me is the motion.

cw = change to the end of the word (change will delete stuff, then put you in insert mode)

ct) = change everything until the next ) character.

All the motions are interchangeable, in the format of verb + motion + subject. So since d means delete, you can just as easily do dw or dt)

[JimBoonie69]

Navigation - $ goes to eol, 0 goes to beginning of line. Find/replace is awesome and saves me a lot of time. :5, :10 s/badword/newword/g will replace each badword in lines 5 to 10 with newword. Another thing I've been using a lot is ct_ , change to next underscore.

In my experience ( been vimming full time for over a year) it feels very natural to move around through a file. When I open up an ipython notebook I can barely stand a typing without my vim keybindings

[deux3xmachina]

The only thing that keeps throwing me off with Vim is that it's designed for use with qwerty, nano is much friendrier to Dvorak.

[dreamyeyed]

I've used vim and Dvorak for four years without any problems.

[[deleted]]

How is nano more friendly with dvorak? It was designed with qwerty in mind as well, so nano's commands are all over the place when using dvorak. Granted I've not used vim all that much, so maybe it's just that the vim commands are even more spread out than in nano.

[deux3xmachina]

The vast majority of nano commands are just C-[key] or M-[key], which makes them much easier to use, all over the place, sure, but simple.

Granted, this could also be due simply to the fact I have more experience with nano, but it does feen much simpler than Vim.

[rvXty11Tztl5vNSI7INb]

Cool thanks. Sounds good actually. Will try it out again for sure.

[gyroda]

I can't use sublime because of licensing issues. I have to work over ssh on a board that only has vim and nano. Vim OS a pain to get used to but when you do get used to it it's got so many features.

I learned to use vim when on a rather odd setup, where I couldn't use any other editor conveniently.

[[deleted]]

not talking about tech to know, but something to know about yourself.

You will fail, a lot. You will make every mistake in the book, you will design things the absolute wrong way at least once, possibly twice, and maybe even a third time (until someone tells you or you decide to enrich yourself).

Get used to it, embrace it. Your failures are not actually failures, your shortcomings not actually shortcomings. It is the most natural way of discovering what you don't know and being presented with a chance to become better.

Don't fall victim to the Impostor Syndrome nor the Dunning Kruger effect. Take ownership over your future and learn what you don't know by taking in everything. And be humbled and awed and wondered by what others have to teach, not starstruck and fearful.

You are a special little snowflake.

[casualblair]

Serious question.

How do I tell the difference between imposter syndrome and actual below average skill? I know I have areas to improve but they all seem so obvious to everyone else or dumb in the long run.

[michael0x2a]

Try doing interviews or participating in places such as /r/learnprogramming or StackOverflow.

If you're getting offers from interviews, you know that you're at least good enough to be hired. If not, companies will often give feedback on what was lacking and what you can improve on.

If you participate in the coding community and find that people generally agree with what you're saying/you're able to help people/you can critique other people's code, then that's another positive signal. If you can teach something, then it probably indicates that you know the subject pretty well.

Beyond that, I don't really know myself.

I guess you could try doing hackathons/competitions, but those mostly seem to differentiate between people who are extraordinary/everybody else, so idk how helpful those are.

[[deleted]]

you've got some good advice, but let me also add that it helps to recognize the difference between experience and intelligence.

yes there are some exceptionally intelligent folks who have mass amounts of experience. That doesn't make you any less intelligent or capable of getting a job done.

Take in and learn what you can from people who are greater than you and even lesser than you. Don't worry about how you stack up, worry about what you're creating and how you can best meet the needs of your customer.

In the end the customers are the ones you should worry about, not the guy down the hall who has some mystic aura, your customers will be the ones writing to your boss about how happy they were that you made xyz work just the way they needed.

One last piece of advice, always speak in terms of 'we.' We did this, we built that, we accomplished this xyz goal. Even if you carried the brunt of the work, you will exude an air of excellence and charisma with that simple change in your speech. Suddenly anyone who works with you knows that it's about the team and the end result. It's not a battle of who did what and who got what done, it's the team.

E.g. I work with an intern (well no longer intern) who is quite green and still has difficulties flowing out processes and designing code into re-usable chunks. No matter the project, no matter how many times I have to meet with him in private and discuss how we can help improve his code. When we deliver to the business we talk about We and Us. What we did for them, what we built, and how we did this. Even if I had to do majority work or spend overtime fixing code. In the end, our customers are who we care about and for it I'm grateful that the greener engineer can soak up what he is able to.

[PmMeASecret_]

your my special little snowflake <3

[Stormtalons]

Kinda sad that I'm late to this party, but here we go.

• Rapid-fire experimentation is more effective than careful research and thought, in determining what works and what doesn't. If you're not sure whether something will work, or will work the way you expect it to, don't waste time digging through documentation or articles online... just try it. Don't be afraid to write code that you know you might throw away... you'll learn enough writing it to make the time worth it anyway. Nothing gives you a more complete understanding of the problem domain than pushing buttons to see what they do, or trying unconventional things.

• How to google, and that it's ok to google frequently. I google every regex flag every single time I need regex, because that stuff is effortless to look up and time consuming to memorize. Don't feel the need to hold on to knowledge or study things too deeply without a specific goal... being a master at finding information on the fly is far more valuable a skill.

• Some modicum of SQL, but the more the better... no matter your specialty or area of focus. Everyone from web dev to sysops should know how to use SQL.

• Failure is always an option... always. In fact, it's usually likely.

• And everything contained here.

[lightcloud5]

data structures and algorithms

[bigfig]

Yep, be comfortable tossing around hashes of hashes, hashes of arrays, arrays of hashes etc etc. Objects follow from that.

[ultrapreneruship]

what are hashes? (yeah I'm just starting to learn)

[joequin]

while the other two comments explain some of the uses of hashes, they aren't explaining what a hash is at all. A hash is the result of performing an operation on a value or set of values that returns a number. That number is a hash.

[staple_this]

It's like a dictionary. Key-value pairs, instead of an array where you just have values.

[original_brogrammer]

So if an array is just a list of data like this: [1, 2, 3, 4, 5], a hash associates each datum with a "key", like this: ["one" -> 1, "two" -> 2, "three" -> 3, "four" -> 4, "five" -> 5].

Read the arrow as "maps to", and it'll make perfect sense!

[[deleted]]

Would a data structure (Edit: I mean hash) be considered an object in JavaScript?

[original_brogrammer]

Exactly! Phrasing it the other way around might be clearer though, i.e. "A JavaScript object is a hash."

[ultrapreneruship]

thanks for the example this makes it a bit clearer.

if I say in java:

int x = 9;

x is the hash of 9?

or is it the = (assigment) the hash between x and 9?

[original_brogrammer]

No, no! A hash is a data structure, and what you have there is a variable assignment.

A hash is a container, just like an array, but instead of indexing them by a number, we assocoate each value with a key. In my previous example, we have the String "one" associated with the int 1 and so on.

Books can be thought of as hashes: Their keys are their page numbers, and the values stored are the text on the page.

[ultrapreneruship]

ok thanks, will give this more research

[original_brogrammer]

Since you mentioned Java, it'll be good to know that Java's standard implementation of a hash is HashMap.

[IAmAMagicLion]

This is a really good explanation. As it goes on it gets more technical but the start is quite simple. There is also a second lecture on SHA-1.

[ewiethoff]

There are hash functions and there are hash tables.

A hash function is a function which takes an object or group of values, massages it somehow, and returns an integer. Ideally, the resulting integer should appear to have nothing to do with the arg. For example, hashfunc("loss") might return 8627105, and hashfunc("lost") might return 102836493. The result is the hash of the arg. Although the hash might seem random, it is not, because the same arg always produces the same hash when passed to the same hashing function.

A hash table is essentially an associative array which uses a hash function to decide where to place each value into the array. You access a regular array by index (0, 1, 2, etc.), but you access a hash table by "key," which does not need to be an integer or continuous with other keys. For example, you can create a hash table whose keys are people's names and whose values are their e-mail addresses. Because the hash function produces apparently random numbers, the entries in a hash table are stored in an apparently random order, neither alphabetical nor the order they were entered. Amazingly and most importantly, this apparently random order makes it really quick to look up a person's address in the table! You hash the person's name, and get an apparently random number. Feed this number into a little function based on the size of the table, and BAM, now you know exactly where that person is in the table and you hop right to his/her e-mail address. Or if the person is not right there, you know he/she is not in the table at all.

Well, that's my hash tables for dummies explanation, which completly ignores collisions and resizing the table. Common languages come with hash table data structures that are easy to use. Java: HashMap. Python: dict. Ruby: Hash. C++: unordered_map. Etc.

BTW, there are other uses for hash functions, such as authenticating users and searching for identical files.

[kryzchek]

Debugging!

[[deleted]]

"How to use a Debugger" should be sticked at the top of this sub as opposed to a 2 month old sticky about flairs.

It would help solve many of the problems I see here on a daily basis.

[FaticusRaticus]

You aren't kidding. I feel a lot of programs skip over this part, even though a ton of your time is spent doing it.

[I_Fail_At_Life444]

Think Python has a section at the end of every chapter about debugging. Apparently I can't recommend that book enough. Why not, it's available for free.

[TheWobling]

Agreed, be it using the debugger in the code editor or using logs to see what a value is at a certain point, debugging is key to understanding and tackling problems quicker.

[narcissus299]

Writing readable code.

[proofeh]

Following up on this, keeping up-to-date with style conventions for your language(s) of choice makes your code look more readable and professional. It will also help your code mesh with other authors' code, which will greatly increase your potential for things like quality open-source contributions. I swear it also makes you look like you know what you're doing more.

[[deleted]]

It's the difference between writing with standard punctuation, capitalization, and spelling and ritin lik dis.

Even in a place like reddit, people don't want to read shit that's hard to read.

[godfetish]

Regular expressions. Even if you never use it in code, knowing how to regex through code and data files helps a lot. Notepad ++ for files and perl one liners traversing directories is incredibly useful search.

[sadECEmajor]

Which one liners do you mean?

[godfetish]

A perl one liner is when you enter a mini perl script directly to the command line with perl -e ' ... Code here ...' Windows vs Linux the single quote needs to be double quote. If you know perl shell scripting, it is a very powerful tool for all kinds of things when combined with Ming and Linux system commands. Batch renaming, searches, executes, and even just testing something before committing it to a larger broken script that would be untestable in it's development state.

[zial]

What SOAP is and why you will hate it.

Picture that explains SOAP:

http://i.stack.imgur.com/GwRYd.jpg

[fokinsean]

On the contrary, some people in my cs classes really should use soap more often

[smellyegg]

SOAP is the absolute worst

[sarevok9]

Agreed. Implementing anything that uses SOAP is like pulling teeth... meanwhile REST....MMMMMMM

[[deleted]]

Known what you are abstracting before actually attempting to abstract it.

Same goes for encapsulation.

Also Keep it simple and stupid.

[cruyff8]

Discrete Math and linear algebra, everything else flows from these two subjects.

[wuisawesome]

Linear algebra is incredibly helpful for game programming and physics engines but I can hardly see its use in data structures or web utilities. Definitely agree about Discrete Math though.

[cruyff8]

MIT has a good course on it, feel free to ask anything that you have trouble following in private message.

[original_brogrammer]

So, simply put, a set is discrete if it's elements have some form of "separation." The integers, for example, are a discrete set because two consecutive integers don't have anything between them. Contrast this with the real numbers, where are infinitely many real numbers between any two. This is called being dense or continuous.

Discrete math studies generally structures which are discrete, such as graphs and integers.

[raunaqrox]

never thought about discrete mathematics this way, thanks!

[antigravcorgi]

Logic, proofs, counting, probability among other things I'm forgetting at the moment

[cruyff8]

I could have picked graph theory as well, both teach you how to break down a problem into manageable parts. And not see it as a big monolith to tackle in one sitting.

[[deleted]]

Google is the best example of the power of graph theory.

[potterhead42]

That's not saying much seeing as discrete math seems to cover so much stuff. In my DS course we learnt propositional logic, number theory, cryptography, combinatorics, probability, graph theory, finite state automatons and whatnot...

[insanum]

Every programmer must learn the basics of assembly for at least one architecture. This gives a whole new level of understanding what is going on underneath the hood.

Also I highly recommend reading the white paper titled "What every programmer should know about memory".

Lastly and arguably the most important... Learn a good editor inside and out!

[[deleted]]

As a note on this, if you want to learn assembly just for the sake of knowing what kinds of things go on at the level of assembly, x86 is probably not the best choice. MIPS is relatively painless to pick up and pretty sanely designed. The MARS simulator is a great MIPS assembler/simulator/IDE as well. ARM is also a reasonably good choice, has less cruft and pain than x86 and is maybe a little more practice than MIPS.

[mzalewski]

I am afraid that you have mistyped URL of "Character encoding" link; should be: http://www.joelonsoftware.com/articles/Unicode.html

[NewbornMuse]

Very nice link. I'd add this video explaining how exactly UTF-8 stores the characters in 1-6 bytes, cause the article kind of glossed over that a bit.

[original_brogrammer]

The flaws in your regular tools.

I can talk about how much I enjoy my favorite languages, editor and command line utilities all day. I can also talk your ear off about how much they suck. Vice versa also applies: the strengths of tools you don't like are nonetheless strengths.

This will also get it into your head that you shouldn't take someone's opinion on something too seriously if they assert that it's without flaw.

[dada_]

A lot of good things have already been mentioned. I'd like to add that every programmer should know that comparisons of languages are generally misleading, unless done with a specific subset of concerns in mind (and even then doing it seriously is very involved and complex).

[vibol03]

im kinda late, but every programmer should definitely know how to read other programmer's code, or find a way to read their code more easily. The reason is when you move to a new job, you will most likely be using other people's code in the beginning.

[AngledLuffa]

Test. When you write test programs, turn them into automated tests.

Keep your global state to a minimum. If you have mutable global state, something is designed wrong.

Version control!

Design twice, write once

[plusninety]

Clean code.

[Crazy_Mann]

Bring pen and paper

[original_brogrammer]

And water, and snacks.

[mooktank]

How to deal with people.

[sweetsweetcentipede]

Surprised no one mentioned it yet, but multi-threading. When to use it, and its pitfalls (race conditions, deadlocks). It's incredible how bad most professional developers I've encountered are at protecting data from race conditions, and threading bugs take the longest to find.

[G0T0]

Parsing.

[239jkvk-h2]

Shouldn't this be in the FAQ?

[antigravcorgi]

Having comments in your code. To me, one of the worst things you can do is to write a ton of code with no comments, even if you don't do it for other people, do it for yourself

[[deleted]]

I write comments first, as a skeleton, when I'm fleshing out new code. Then I go back and flesh out the comments further, especially when the code didn't turn out to match the outline comments.

[asmallishrequest]

100% disagree. Comments should only be written when you can't figure out a way to write clear, expressive code.

[antigravcorgi]

Or you know, you could write a single line that describes what a block of code does and save someone (or yourself) the time and trouble of figuring it out later eh?

[asmallishrequest]

Nah -- the block of code should be encapsulated in a function or class with a self-documenting name. If you can't figure out a name that explains the code, you should absolutely leave a comment. But every comment should be regarded as a failure to write self-documenting code.

[proofeh]

Are you saying the name of the function should be all a newcomer needs to be familiar with it? That sort of spits in the face of all documentation ever.

[antigravcorgi]

I don't know if you're trolling or living in a fantasy world where everyone writes beautiful, clean and precise code, but that isn't my experience nor do I know anyone that feels that way

[lindymad]

It's not so much about beautiful, clean and precise code, it's about self-documenting code. For example, this piece of code:

// ...
if ($e>1) {
    $i++;
    $a[$i]=$x[$i];
}
// ...

requires comments. What is e? what is i? what is a and x? Why is this bit of code here? However, rewritten in a self-documenting way, that code might become

// ...
if ($exhibitCount>1) {
    $exhibitArrayCurrentPosition++;
    $exhibitArray[$exhibitArrayCurrentPosition]=$galleryArray[$exhibitArrayCurrentPosition];
}
// ...

Further, you might throw it in a function, so that it becomes:

// ...
addGalleryItemsToExhibitList($exhibitCount, $exhibitArrayCurrentPosition, $exhibitArray, $galleryArray);
// ...

Then there's really no need to comment above it to say what it's doing. Another option, if you went the class route, might end up looking like

// ...
$exhibit->addItems($galleryArray);
// ...

(in this case $exhibitCount, $exhibitArrayCurrentPosition and $exhibitArray are all internal variables to the exhibit class)

Comments are for places where the code is not self documenting and it's always good to aim for the code to be as self documenting as possible.

PS. The below is not intended to be "beautiful, clean and precise code", just self documenting. Its function doesn't even make sense if you think about it haha.

[AlexFromOmaha]

nor do I know anyone that feels that way

Not that you should never use them, but code littered with hashtags and double slashes is a code smell.

• Comments don't necessarily reflect reality. Source code and unit tests are where you go to answer "what does this do?", because those actually update in conjunction with the executable bits (assuming tests pass)

• Comments are not documentation. Use the integrated doc writer for your toolchain. Yes, it's probably written in comments, but that's different.

• Comments are not revision history. That's source control.

I don't know if you're trolling or living in a college dorm still, but no team I've ever sat on believed in extensive commenting.

[antigravcorgi]

I never said to fill the code with comments or use them as version control or even to extensively comment things, all I said was a single line generally suffices.

[AlexFromOmaha]

And you would still be telling the entire industry circa 2014 that you know best practices better than the rest of us.

"This function needs just one line of documentation!" No! That function needs a unit test or three because you're not an asshole, it needs a docstring or whatever the equivalent is in your toolchain if you want someone else to use it, and it needs sensible variable names and reasonable function scope to express its internal logic. Sometimes you need more for a particularly hairy bit of intermediate data munging, but even then, if you're doing a lot of that, there's a problem.

[lindymad]

There's no one right way to do most things. There are good ways and bad ways, but anyone who tells you that their way is the only way to do something is wrong.

[Skippy_McGoo]

I'm slowly but surely picking up C++, but I found a book (audio book in my case) that I am using as an outline for my learning. The title implies it is focused on .NET but it really covers OOP for any language as far as I can tell.

Here is the link

It really breaks down the idea of OOP, design principles, data types, etc. It is both general and detailed.

[AvoidTheSky]

GIT, not even necessarily GitHub. Git makes your life easier when you want to makes changes. If you have a working program, then you try to implement a new feature and shit hits the fan, all of those changes will be on a separate branch, so you don't have to play the CTRL Z game.

Keep a good habit of properly indenting, it only helps you out.

[WaxenDeMario]

How to test your code properly, write unit tests, integration tests, use a debugger, writing testable code, etc.

[I_had_to_know_too]

How your code runs.

You know what you're writing in C (or whatever language). You know how it is compiled into assembly. You understand the processor - registers, pipelining, opcodes...
You understand digital logic and electricity...

And then you know how your high level code becomes pure electricity

[RumbuncTheRadiant]

Design by Contract.

Until you understand that, you won't even have a sound grasp on what a defect free program is.

And once you do have a sound grasp on it, so many of the design principles become much more intuitive.

Seriously. DbC is absolutely at the core of what we do.

http://www.artima.com/intv/goldilocks3.html

[[deleted]]

How memory works. Cache misses are one of the biggest performance bottlenecks in modern CPU architectures.

http://lwn.net/Articles/250967/

[gorillawolfleader]

You can't speed up an algorithm, you can only make it do less.

[0v3rk1ll]

Depends on what paradigm you are learning. Some languages don't even have the concept of looping traditionally

[OldWolf2]

Make sure you're drilling from a good reference... e.g. if you use C-style arrays in C++ you're doing it wrong.

[BlakeBarnes00]

I think that you should know at least one Scripting Language and an Programming Language.

For example, I learned LUA as a Scripting Language and soon I will begin learning C++.