33 votes

What do you think is one thing every programmer should know how to do?

My pick is definitely a basic understanding of git / version control in general

39 comments

  1. [4]
    Amarok
    Link
    As a grumpy old sysadmin who has dealt with masters students fresh out of college that... lacked certain kinds of understanding, I'll chime in. Have an awareness of how your program is interacting...

    As a grumpy old sysadmin who has dealt with masters students fresh out of college that... lacked certain kinds of understanding, I'll chime in.

    Have an awareness of how your program is interacting with both the hardware and the network. Some devs I've seen lack the basics of 'where the rubber meets the road' in computing. I'll give you a specific real world example.

    A client-server application was developed - what it did isn't pertinent. Runs fantastically well on the dev's machine and the local network. Runs fine with several dozen users on the local network as well. The instant it goes through a firewall, suddenly it can only handle one or two users (without issues, everything works fine) before the client communication starts bugging out and losing data. As soon as it gets busy with lots of users, the network basically dies - but only going through the firewall. For some reason, one or two users through the firewall is fine. More than that kills it.

    Take a second a ponder the possible causes in your head before reading further. ;)

    The developer comes in and insists that our firewall is the problem. Well, clearly he's got a point, it's involved somehow. There aren't any issues with the firewall rules, or a single user wouldn't work either. He insists that our 'cheap' firewall (a dual processor PC with 8GB of memory) just can't handle his awesome application.

    We pop open wireshark for a peek at the network activity the application is generating - and there's the problem. A single user of this application generates more than eight hundred connections in a single minute. Every single data object that was being sent between the server and the client was creating a brand new unique connection. As soon as enough users got busy with the application, the firewall simply couldn't handle the level of connection overhead. The state tables were basically imploding under the load of tracking all of them.

    This developer came from a well known and well respected CS department at a major school. He'd written one hell of an application - the work it was doing and data it was analyzing was really something, and that program made our company a lot of money. Somehow, though, in 6+ years of his college education, he'd never stumbled into the equivalent of Networking 101. He thought having that many connections was actually improving performance. This is a true /facepalm moment.

    The proper way is of course to keep to one or two network connections open and reuse/maintain them... not discard them the instant they've sent whatever it was you wanted to send.

    Whenever you do something in the processor, or with the hard drive, or over the network, resources are expended that are independent of your own code - there's a bookkeeping cost, if you will, to everything going on. In the case here, there's time needed to establish each independent network connection, and there's effort expended by all of the network devices (not just the firewall) for each connection they have to deal with - mostly that effort is in the establishment, not maintaining them.

    So, for the sake of the sanity of your co-workers, learn a little bit about the hardware and what your code is doing out there in internet-playland. If you're a masters in CS, trust me, it's not going to be that hard for you to spend an afternoon and pick up some of the basic stuff. ;)

    44 votes
    1. Akir
      Link Parent
      That's actually one of the reasons why I liked Rust so much; it basically forces you to consider how memory is used, and that's why programs written with it tend to be so fast. I find that the...

      That's actually one of the reasons why I liked Rust so much; it basically forces you to consider how memory is used, and that's why programs written with it tend to be so fast.

      I find that the older I get, the more I agree with Knuth's approach to teach people to code directly to the metal. Sure, it may not be the most accessible method, but it sure is effective.

      12 votes
    2. asoftbird
      Link Parent
      Besides, learning how microcontrollers work, how memory is handled and what components they're made of is a pretty fun read. I saw a bunch of Youtube videos on the subject a few months ago and am...

      Besides, learning how microcontrollers work, how memory is handled and what components they're made of is a pretty fun read. I saw a bunch of Youtube videos on the subject a few months ago and am now completely hooked on the basics of computing. I recommend looking into it, even if it's just the basics.

      Edit: that said, I highly recommend Ben Eater's video series on building an 8-bit computer from IC parts on breadboards. Very informative and logically structured.

      10 votes
    3. undu
      Link Parent
      Had a similar issue. I was asked to implement exponential backoff for an ftp client. the clients were overloading the server. Turns out that for uploading all the files in a folder and subfolder...

      Had a similar issue. I was asked to implement exponential backoff for an ftp client. the clients were overloading the server.

      Turns out that for uploading all the files in a folder and subfolder they were opening a connection (actually 2, ftp is fun like that) per folder level + one per each file, overloading the server.

      It was quite easy to change it to a single connection per upload session and the servers have been able to cope with the load since then.

      4 votes
  2. [3]
    masochist
    (edited )
    Link
    Know how to debug. You're going to create bugs, and you need to learn how to debug. Some folks debug the Kernighan way via printf() or whatever. Some folks like debuggers. Some folks like both....

    Know how to debug. You're going to create bugs, and you need to learn how to debug. Some folks debug the Kernighan way via printf() or whatever. Some folks like debuggers. Some folks like both. Sometimes circumstances preclude you from one method or the other, so it's best to know both. But most of the time it doesn't matter which one you use; just be comfortable with your tools.

    edit: Knowing how to debug requires some other skills like knowing how to read and understand code. But you asked for one thing, so I gave you the thing that includes the other important thing I'd've mentioned if you let me mention two. ;)

    19 votes
    1. Octofox
      Link Parent
      One of the things I love about web dev is your browser comes with an incredible debugger. I was testing something on IE last week and I noticed just how fantastic the firefox dev tools are. On the...

      One of the things I love about web dev is your browser comes with an incredible debugger. I was testing something on IE last week and I noticed just how fantastic the firefox dev tools are.

      On the backend I have simply never had anything that was too complex to debug by writing specs and printing things.

      5 votes
    2. esrever
      Link Parent
      Programming does not take up a large chunk of my life, but I have found Rubber Duck Debugging extremely helpful in various other areas unrelated to code. Being able to explain something simply is...

      Programming does not take up a large chunk of my life, but I have found Rubber Duck Debugging extremely helpful in various other areas unrelated to code. Being able to explain something simply is a good indicator of actually understanding the material.

      4 votes
  3. [10]
    Akir
    Link
    The only universal thing I can think of other than git is how to write good documentation and comments while coding. Everything else I can think of is one of those "no-brainer" things, like...

    The only universal thing I can think of other than git is how to write good documentation and comments while coding.

    Everything else I can think of is one of those "no-brainer" things, like figuring out the structure of the application before writing code. The things that a programmer should get automatically with experience.

    12 votes
    1. [9]
      masochist
      Link Parent
      I'm going to be unpopular for this, but I think most comments are garbage. A comment shouldn't explain what the code is doing in almost all cases. If you have any business reading the code, and...
      • Exemplary

      comments

      I'm going to be unpopular for this, but I think most comments are garbage. A comment shouldn't explain what the code is doing in almost all cases. If you have any business reading the code, and especially modifying it, what the code does should be obvious almost all the time. Comments explaining what it does only get in the way. Basic comments explaining what the code does may be useful for juniors as a mentoring aid, but what's far more important is why the code does what it does. Why did I choose this sort algorithm instead of another? Why did I use this data structure?

      But the pinnacle of comments in my mind is the comment explaining why not. Like explaining what, why will usually be obvious unless you're a junior developer. Why not, though? That's the tricky thing. That's the thing that comes from battling with bugs until 3 in the morning. Why not comments impart wisdom about the system that come from being burnt by doing the obvious thing and adopting something different. I'm an experienced developer and a lot of things are obvious to me, assuming I know the problem domain. But sometimes the obvious thing doesn't work, and that's, IMO, what you should comment.

      Note that what I've said here makes some assumptions. The first one that I've addressed in my comment a few times is that it doesn't work for junior developers. It also assumes there's sufficient documentation for the code itself (this is not comments, this is things like APIs and design / architecture documentation) which makes what the code does obvious. It also assumes that, in most cases, the code you're writing is simple and straightforward (i.e. the boring business stuff most of us write to pay the bills). If you're writing something like a device driver, yes, please, comment everything that someone else familiar with device drivers would want to know. The same goes for anything that isn't dirt simple "fetch the user whose ID was passed in via the user_id parameter from the DB and update its email to the address given in the new_email parameter because this is the update_user_email method" CRUD.

      31 votes
      1. InherentlyGloomy
        Link Parent
        This is something I had to learn the hard way. I made my comments far too verbose for a long time, until a manager did a code review and said (paraphrasing) "Don't write your code twice in the...

        This is something I had to learn the hard way. I made my comments far too verbose for a long time, until a manager did a code review and said (paraphrasing) "Don't write your code twice in the same file." He taught me to rely more on good variable names and readable code than ass-loads of comments.

        11 votes
      2. [2]
        Akir
        Link Parent
        You know, I pretty much agree with you. There is a reason why I put documentation first. In fact, I'm in the camp that one should write the documentation for a method before implementing it if...

        You know, I pretty much agree with you. There is a reason why I put documentation first. In fact, I'm in the camp that one should write the documentation for a method before implementing it if possible. That's basically the distinguishing line between being a programmer and code monkey. A good programmer should understand that the first step to writing an application (after gathering the requirements, of course) is to design the API.

        What you are saying is close to @timo's response about writing clean code. And that was one of those things I considered a "no-brainer" that comes with experience. Maybe it needs more thought than I gave it credit for, though.

        10 votes
        1. masochist
          Link Parent
          This is a very good point. Ideally, also, the tests should come first. Again, ideally, the tests represent the first real usage of the interfaces that you'll then be implementing, which is very...

          one should write the documentation for a method before implementing it

          This is a very good point. Ideally, also, the tests should come first. Again, ideally, the tests represent the first real usage of the interfaces that you'll then be implementing, which is very much in line with the rest of your thoughts here.

          And that was one of those things I considered a "no-brainer" that comes with experience. Maybe it needs more thought than I gave it credit for, though.

          I like to say that the amount of time spent debugging is directly proportional to the square of the number of assumptions made while debugging. ;) It's close, yes, but not quite the same.

          4 votes
      3. [3]
        unknown user
        Link Parent
        Comment your algorithms, comment your hacks, comment your abstractions, and comment your modules even if it is a one line description up top. Saves so much time when reading code or returning to a...

        Comment your algorithms, comment your hacks, comment your abstractions, and comment your modules even if it is a one line description up top. Saves so much time when reading code or returning to a portion of code off the beaten path, so to speak. Personally I'd rather read a few lines of prose than try to understand what is going on from imperative steps because often they are too granular to quickly give out what is going on.

        6 votes
        1. [2]
          masochist
          Link Parent
          I think we're saying mostly similar things here, just with different words. What I'm saying is that you should absolutely document those things, just not necessarily as code comments, unless...

          I think we're saying mostly similar things here, just with different words. What I'm saying is that you should absolutely document those things, just not necessarily as code comments, unless they're exceptional in some way. The approach that you're suggesting seems, to me, like it would be more fitting for someone new to the codebase--and IMO that kind of thing is best handled in things that aren't code comments but rather API documentation / other docs that aren't written on a line-by-line basis like code comments are. Am I misunderstanding?

          2 votes
          1. unknown user
            Link Parent
            Not really. I think I was too tired to understand well what I was reading, I am sorry. I think comments are a better place for this sort of annotations. Docs should mostly be about how to use the...

            Am I misunderstanding?

            Not really. I think I was too tired to understand well what I was reading, I am sorry.

            I think comments are a better place for this sort of annotations. Docs should mostly be about how to use the software / API; comments, how to implement, edit and debug the code. Emacs codebase is good at this. Comments, docstrings and manuals document different aspects, and come in handy in different settings.

            For example for a sort function the docs can be like

            • private comment for function that tells why a particular algorithm was choosen and how it is implemented

            • public documentation (collected from source code like rdoc or external docs like texinfo) that explain how to use the interface of the function, what it does when it succeeds and what are expected error cases

            • docstring (if available) exhaustive details of the input and ouput of the function.

            3 votes
      4. [2]
        Ordinator
        Link Parent
        I think that you'll find that this opinion is in fact remarkably popular among competent developers. In fact, I've found that an insistence on lots of comments is a great indicator that the person...

        I think that you'll find that this opinion is in fact remarkably popular among competent developers. In fact, I've found that an insistence on lots of comments is a great indicator that the person I'm talking to is at the very least inexperienced, and sometimes just not very good at writing software.

        1 vote
        1. masochist
          Link Parent
          That does seem to be what I'm seeing with the response, yes. :) I've stated the opinion in the past and it was not at all received well, which I suppose says something about my audience at the time.

          That does seem to be what I'm seeing with the response, yes. :) I've stated the opinion in the past and it was not at all received well, which I suppose says something about my audience at the time.

  4. [9]
    timo
    Link
    Write clean code. A lot of people can get their code to run and do what they want. But making it readable, understandable or maintainable is something else entirely. Things like using meaningful...

    Write clean code. A lot of people can get their code to run and do what they want. But making it readable, understandable or maintainable is something else entirely.

    Things like using meaningful names, keeping functions short and simple and not repeating yourself can make an enormous difference.

    10 votes
    1. [6]
      somewaffles
      Link Parent
      To that point, don't try to be clever. Sometimes it's better to expand your code into multiple lines so that the next dev doesn't have to spend an hour trying to pull apart your single liner. I...

      To that point, don't try to be clever. Sometimes it's better to expand your code into multiple lines so that the next dev doesn't have to spend an hour trying to pull apart your single liner. I get everyone wants to look smart but I don't care how clever you are, just write stuff that I can debug.

      11 votes
      1. timo
        Link Parent
        Agreed! I believe code reviews or pair programming can help immensely regarding both our points. It's so easy to get stuck in your own world where your code seems perfect.

        Agreed! I believe code reviews or pair programming can help immensely regarding both our points. It's so easy to get stuck in your own world where your code seems perfect.

        5 votes
      2. Octofox
        Link Parent
        Also don't try to be funny with names. I'm currently dealing with some code where the variable names are just jokes. I don't mind the occasional funny comment but please leave the code alone.

        Also don't try to be funny with names. I'm currently dealing with some code where the variable names are just jokes.

        I don't mind the occasional funny comment but please leave the code alone.

        4 votes
      3. [3]
        Emerald_Knight
        Link Parent
        Cleverness is a fallacy. I've had many, many rants about this subject in the past, but it all boils down to what you said: don't be clever. Be simple. Be predictable. Be consistent. Be sensible....

        Cleverness is a fallacy. I've had many, many rants about this subject in the past, but it all boils down to what you said: don't be clever.

        Be simple. Be predictable. Be consistent. Be sensible. Be proactive. Write code knowing that you or someone else will have to come back months later and touch it again. Write code knowing that you're going to completely forget the fact that you ever wrote it at all, and that you sure as shit won't remember the details of what you'd written in the first place. Write code that makes you not dread the idea of having to change it later when it inevitably turns out that there's a bug that was missed during QA or that requirements for that feature have suddenly changed.

        Cleverness is just stupidity with more steps.

        1 vote
        1. [2]
          somewaffles
          (edited )
          Link Parent
          Well, I think it depends! Cleverness is literally defined as "to show intelligence" and I think if a block of code was written with the sole purpose of displaying your intelligence, you're a...

          Well, I think it depends! Cleverness is literally defined as "to show intelligence" and I think if a block of code was written with the sole purpose of displaying your intelligence, you're a moron. But I think if a design pattern used in a way that is simple, predictable, sensible but still novel, I would consider that clever without having looked like you forced your giant brain on your team.

          1 vote
          1. Emerald_Knight
            Link Parent
            Keep in mind that the above is only a general rule of thumb. If something feels "clever", it's usually an indicator to step back and make sure you're not actually doing something incredibly...

            Keep in mind that the above is only a general rule of thumb. If something feels "clever", it's usually an indicator to step back and make sure you're not actually doing something incredibly stupid. It could very well be that your code is fine, but you should always double check when something seems clever to you.

    2. what
      Link Parent
      I’d say learning to work with linters is a great, if not essential skill. One of my favourite things about Go is the gofmt tool.

      I’d say learning to work with linters is a great, if not essential skill. One of my favourite things about Go is the gofmt tool.

      1 vote
  5. [7]
    Comment deleted by author
    Link
    1. asoftbird
      (edited )
      Link Parent
      This also goes for many other fields: not planning ahead / not writing a spec of exactly what's required is quite prone to problems/misunderstandings later on. It's not just for the programmer...

      Non-technically, I think it's crucial that programmers respect the design and documentation phases. The kind of programmers who come out of boot camps are usually better at this than those who are self-taught through open source or learned primarily in school (with the exception of actually good CSE programs). It's crucial to think about what you're building before you do so, and to write down what you are building while you build it as well as writing down how to use it.

      This also goes for many other fields: not planning ahead / not writing a spec of exactly what's required is quite prone to problems/misunderstandings later on. It's not just for the programmer themselves but also good for communicating with other parties, be it other programmers or people like designers, managers, marketing people.
      You should get the picture as clear as possible, as early as possible, work through it together and agree on what'll be in the product and what won't be.

      I'm an engineering student (with a knack for having too many hobbies) and even though I only have experience in group projects with other students, this is something everyone seems to do: ignoring structure that's set up to help you and your project get along well.
      Actually following some sort of plan ends up being very beneficial to the overal project: things get done, there's suddenly free time, crucial questions are asked early instead of one week before deadline, and so on. It's education so it's (more) okay to make mistakes, but I'm not very fond of willfully ignoring structure and making the same mistakes over and over.

      3 votes
    2. [4]
      welly
      Link Parent
      I think your seven year old link is a bit of a stretch to be honest and most of his points can be fully refuted. Interesting that you think git sucks yet people get on very well with it.

      I think your seven year old link is a bit of a stretch to be honest and most of his points can be fully refuted. Interesting that you think git sucks yet people get on very well with it.

      3 votes
      1. [2]
        Comment deleted by author
        Link Parent
        1. welly
          Link Parent
          Not even your link suggested it "really sucks". That was your editorialised title. To say it "really sucks" would suggest it doesn't work, when that is clearly not true. Hyperbole much? No you...

          Git is better than many other VCSes but it is not nearly as good as it could be. I think I'm perfectly justified in pointing that out.

          Not even your link suggested it "really sucks". That was your editorialised title. To say it "really sucks" would suggest it doesn't work, when that is clearly not true. Hyperbole much?

          1. Complex information model... and you need to know all of it.

          No you don't

          1. Crazy command line syntax

          He gave two examples. I tend to use a GUI for speed/efficiency and I work better with visual references yet I can navigate the CLI tool quite happily as well.

          1. Crappy documentation

          To give the author his dues, his article is seven years old. There is so much documentation about using git, this is clearly false. The official docs are comprehensive now, I'm not sure how that compares with when he wrote his article.

          1. Simple tasks need so many commands

          The author obviously has a preference to the svn workflow, I have a preference towards the git work flow. This is subjective.

          2 votes
      2. [2]
        masochist
        Link Parent
        Popularity doesn't imply quality. Popularity is more about circumstance and marketing more than anything else.

        Popularity doesn't imply quality. Popularity is more about circumstance and marketing more than anything else.

        1. welly
          Link Parent
          I'm not suggesting that popularity implies quality, I'm saying that the world round, developers are using git and getting on perfectly well with largely few complaints. Of course it's not perfect...

          I'm not suggesting that popularity implies quality, I'm saying that the world round, developers are using git and getting on perfectly well with largely few complaints. Of course it's not perfect but point me to a software product that is anywhere close to.

    3. Octofox
      Link Parent
      A common mistake I see beginners make is they shit out code in to the editor without actually knowing how to solve the problem. They then repeatedly edit it to try and get it working. I stopped...

      A common mistake I see beginners make is they shit out code in to the editor without actually knowing how to solve the problem. They then repeatedly edit it to try and get it working. I stopped one person and asked them to explain to me in english how the problem is solved and they couldn't tell me. How can you possibly write code to do something when you don't even know what the code is trying to do.

      This is probably why unis tend to require you to write english versions of your code before writing the real code. In the real world I have never needed to do this but I guess it stops this beginner trap.

      3 votes
  6. rogue_cricket
    Link
    Technically, I'd say: get to know your data structures. Many algorithms can be greatly simplified or sped up if you start off on the right foot by selecting an appropriate structure for your data....

    Technically, I'd say: get to know your data structures. Many algorithms can be greatly simplified or sped up if you start off on the right foot by selecting an appropriate structure for your data.

    On the softer skills side, just... the ability to organize work with others, to check in and question your own work and the work of others. A self-taught cowboy coder and an inexperienced TL combo is why I left my last team. The cowboy would work hours on something nobody wanted or asked for, and the TL would just let it happen, and the codebase became an absolutely awful mess. I could type for hours about how bad it got, but I'll save the time and just skip to the last straw for me: an electron app for running integration tests (yes, really) that only worked on Windows (yes, really) and was impossible to work around. Nobody uses any of the underlying tests I wrote any more because of this monstrosity. I seriously regret not stepping in.

    6 votes
  7. Emerald_Knight
    Link
    The concept of cyclomatic complexity. The general idea is that if you were to create a control flow diagram of your program logic, then conditional branches that merge back into the main path of...

    The concept of cyclomatic complexity.

    The general idea is that if you were to create a control flow diagram of your program logic, then conditional branches that merge back into the main path of execution and any loops you have will typically generate enclosed regions within the diagram. The more enclosed regions there are, the higher the cyclomatic complexity of your code.

    My takeaway from the above, however, is this: the more deeply-nested your conditional statements and loops, and the more of them that merge back into the main path of execution, the more difficult it gets to figure out just what the hell your code is doing. Yes, it's nice to have a single exit point in your function, but if you have if blocks nested twenty layers deep, then it just isn't worth it. Sometimes it's better to have multiple exit points and to simply return earlier on in your function call so you can avoid having to deeply nest these different blocks.

    Example:

    function myFunction(my_value) {
        var my_return_value = null;
    
        /* ,,, */
    
        if(condition_a) {
            if(condition_b) {
                if(condition_c) {
                    if(condition_d) {
                        if(condition_e) {
                            my_return_value = 0;
                        } else {
                            my_return_value = 1;
                        }
                    } else {
                        my_return_value = 2;
                    }
                } else {
                    my_return_value = 3;
                }
            } else {
                my_return_value = 4;
            }
        } else {
            my_return_value = 5;
        }
    
        return my_return_value;
    }
    

    Notice how terrible this is to read? If I ask you "what happens when condition_c is false", you have to find the right indentation level, figure out if there's an else block, and potentially do a bunch of other annoying stuff just to track down what's going on. Imagine if there were side-effects in this function and these different if blocks contained a lot more code. It would be tedious just to follow the indentation levels alone! Overall, there's just a ton of mental overhead associated with this sort of code structure.

    Now, let's try this again by reducing cyclomatic complexity to a minimum:

    function myFunction(my_value) {
        /* ... */
    
        if(!condition_a) {
            return 5;
        }
    
        if(!condition_b) {
            return 4;
        }
    
        if(!condition_c) {
            return 3;
        }
    
        if(!condition_d) {
            return 2;
        }
    
        if(!condition_e) {
            return 1;
        }
    
        return 0;
    }
    

    Notice how much better this is? You'll probably notice that you're now able to see each of the if blocks as error cases and that the lowest nesting level represents the "happy" path of execution, so your brain is now conditioned to think something along the lines of "if any of the conditions are false, return a non-zero error code, otherwise return a success code".

    Now, this is obviously a very special case. But structured correctly, this sort of reduction in cyclomatic complexity and willingness to halt a branch of execution early on makes it easier to track down where the "success" case is supposed to be (typically right at the bottom of your function) and keeps you from having to jump around all over the place to figure out what the code is supposed to be doing. The mental overhead associated with following the different paths of execution is now potentially significantly reduced, especially for otherwise deeply-nested levels of indentation.

    For those cases where your cyclomatic complexity is still fairly substantial even after a refactor, it also serves as a simple indication that you need to break your logic out more.

    The general concept of cyclomatic complexity isn't meant to be some hard rule to follow--every rule in programming has its exceptions--but one of many tools you can use to evaluate your code and determine whether or not it can be improved.

    6 votes
  8. Luna
    Link
    Dependency management. There's nothing worse than an undocumented requirement that you have <specific version> of <library> installed to <non-standard directory>, or requiring <oddball compiler...

    Dependency management.

    There's nothing worse than an undocumented requirement that you have <specific version> of <library> installed to <non-standard directory>, or requiring <oddball compiler flags>. When I create my readme files, I provide instructions to get my programs running from a stock Ubuntu install, whether that be just installing Python 3.6+ (because I needed the secrets module and at the time 3.5 was the Ubuntu default) and running virtualenv, or if you have to change some Postgres templates and generate some dummy SSL certs. If your system dies or you want to continue development on another computer, having everything written down and easy to setup will make things go a lot quicker.

    2 votes
  9. [4]
    Ordinator
    (edited )
    Link
    Nothing. Software development is an incredibly broad field. From hobbyists to professionals, from safety critical aerospace systems to rovers on other planets to web front-ends, there just isn't...

    Nothing. Software development is an incredibly broad field. From hobbyists to professionals, from safety critical aerospace systems to rovers on other planets to web front-ends, there just isn't anything that applies across the entire field of "programmers".

    To pick on OP as an example, there are plenty of hobbyist programmers out there that get by just fine without any formal version control. If they're writing software for little Arduino projects for fun, I think that's fine. There are also—gasp—people who prefer other version control systems over git.

    1. [3]
      judah
      Link Parent
      I meant more of “knowing x will help you with programming or make you better in some way.” Like, for instance choosing and sticking to a programming “style” and making sure your code is formatted...

      I meant more of “knowing x will help you with programming or make you better in some way.” Like, for instance choosing and sticking to a programming “style” and making sure your code is formatted consistently between files/projects. That’s something that helped me out a lot.

      And true! I’ve been (very briefly) testing mercurial, which has been nice. Not sure what other SCMs are worth trying though. Any suggestions?

      3 votes
      1. unknown user
        Link Parent
        RCS. It is old and clunky, but Emacs helps make it usable. I have some scenarios where I need only one file version controlled (e.g. research notes where it is one Readme.org file plus PDFs,...

        Not sure what other SCMs are worth trying though. Any suggestions?

        RCS. It is old and clunky, but Emacs helps make it usable. I have some scenarios where I need only one file version controlled (e.g. research notes where it is one Readme.org file plus PDFs, pictures, other multimedia or data), and I like it better than git for that purpose. Also whem unrelated documents are under the same folder, it is easier to move only a subset losslessly with it. I don't use it for code, only plain text documents.

        Fossil is interesting too. It combines VCS, wiki and issue management into a single tool. Created and used by the SQLite dev. I like Git plus an org mode file better, but I only really maintain my config and a couple small open source projects, so maybe there are benefits I can't see for bigger projects.

        3 votes
      2. Ordinator
        Link Parent
        Yeah, but I think my answer is the same for that phrasing as well. My point is really that you get much better answers to these sorts of questions when they're more tightly focused. When you zoom...

        I meant more of “knowing x will help you with programming or make you better in some way.”

        Yeah, but I think my answer is the same for that phrasing as well. My point is really that you get much better answers to these sorts of questions when they're more tightly focused. When you zoom all the way out to "every programmer", it's virtually impossible to construct advice that's both true and meaningfully actionable IMO.

        As for version control, I actually do use and prefer Git for my own work. The example I had in mind was a gamer developer I know who prefers SVN because it handles binary assets better than Git.