Old school developers - achieving a lot with little

Unit tests are great in js/python/ruby because of the nature of the language

In C/C++ for example it's much more involved. In java it's bearable because of Eclipse/Netbeans facilitating lots of things.

But take for example the Linux kernel development: - There are two widely used "IDEs": VIM and Emacs, pick one

- Patches sent over email (yeah, please try doing a pull request to see what happens)

- No unit tests

- limited use of debuging tools, mostly printk

And still is one of the most solid and used softwares out there

Tools and techniques (unit tests, CI, etc) are good if you want to have several developers "with their hands on the code at the same time" and you have limited trust on them

  Regarding his programming style ... hardly ever uses unit tests, 
  starts his projects by designing the data structures and then works bottom up,
  with throwaway test stubs.

No matter how good heart rate monitors you have, how good shoes you have, how well nourished you are, how prepared you are, ... - you won't run your marathon any better if you aren't serious about the actual act of running. You can devise complex meditation practices and analyze your running stance and efficiency, but in the end it's the act of running which gets you through the 42195 meters of pain. The better you are at it, the faster you finish. Equipment helps, but only to a small degree.

Focus on working, getting stuff done.

I started with things like QuickBasic and PHP, so debugging by print has always felt natural to me.

This is a problem with things like Java that were clearly not designed around this paradigm where you should really be using a debugger or setting up log4J or something.

Anyway, I used to use the interactive debuggers in Visual Basic and Visual Studio, but for the web its easier to just be in an ssh terminal and so I just use logs.

If you want people to use TDD, then they should start learning it close to when they start programming, and I think that will make it much easier and more natural for them to do.

I have done some TDD, but not very much because it always feels like extra work. What I am used to doing these days is sort of small feature test programs when I need to and its convenient or just running the application and looking at logs. I think if I had learned to program with TDD it would be a lot easier.

This was really good for me to read. Coding is much more fun than planning, so I get pulled into the trap of staring at my screen while thinking things through, trying something, then approaching a better solution. I am trying to make myself create a clear plan on paper before turning my computer on. Only when I have a clear approach outlined on paper do I get to turn my computer on.

It's less "fun" sometimes, but it's much more satisfying.

Glennie developed Autocode, a "simplified coding system" - what many regard as the first real programming language. The story goes that when Glennie developed the first compiler for Autocode, Turing was furious that precious computer time was being wasted on such a task. Turing's mind was supposedly so brilliant that to him, the task of implementing a program in machine code was mere admin, something requiring no more skill than making up a punchcard. It simply did not occur to him that other people might consider computer programming to be complex enough to be a vocation in itself.

For once-in-a-generation geniuses, no safety net is necessary. The rest of us need to be protected from our own incompetence.

My tooling preference is evolving a bit. I used to hate IDEs, because I associated them with the (thank God it failed) attempt to commoditize programmer talent (starting in the 1990s with VB) that hijacked "object-oriented programming" and led to 21st-century spaghetti code. On the other hand, IDEs can actually be damn useful. You're in for hours of misery if you try to do Java development without an IDE, and IDEs are better adapted to one reality of software development: that most professional programmers spend more time trying to figure out other peoples' code than reading their own. The click-and-navigate capability (that automagically takes you to the file and line where a method or class is defined) is valuable.

Something Google had that I liked a lot is a code-navigation tool, much like a read-only IDE, served on the web, for its codebase. Very useful.

IDEs also help you navigate the dependencies and cruft-sprawl that are pretty much unavoidable on large Java projects. If you're on-boarding into an existing Java project and want to be productive in your first week, I think using an IDE is the only answer.

For my own projects (where I'll often use Scala but never Java) I still use emacs and probably always will, but if I'm working in a 100kLoC codebase of mixed Scala and Java, using a build and version-control system I'm not familiar with, I'm going to use the IDE, at least when I start out. IDEs aren't perfect: a lot of the things they hide or for which they automagically do the work (build system, version control) are things a programmer will actually want to understand at some point. But it's nice to be able to be productive (in a software environment you didn't create) on the first week.

Debuggers are another area where I'm coming to learn that printlining isn't always enough. The name of the game in debugging is not to break flow. Pinging about files inserting printlines (trying to figure out where to put them, and how to handle loops where you strictly do not want a printline for each time you're in the loop) can involve too much orthogonal thinking and context-switching to be productive, so an interactive debugger like what Lisp has or what Eclipse offers can be a godsend. Often printlining is the best solution because you know what you want to see in the execution (it's not "ad-hoc" debugging) but sometimes you don't. Once you start having to think about how to printline something, you're better off with an interactive debugger.

Unit tests, for me, are about not breaking flow. I'd rather do the debugging while the problem is fresh in my mind than possibly months later. I'm going to "REPL-test" the thing in any case, and I might as well turn that session into something persistent. I certainly won't remember, 3 months later, how comprehensive my REPL testing was. If I have unit tests, I can check and see what's covered and what isn't.

I don't write unit tests because I'm a nice guy. I do it because I'd rather spend an additional 20 minutes writing tests-- plus whatever debug time happens on account of bugs found, but that's strictly less time than it would cost me or someone else to debug it later-- than have to deal with a context switch weeks or months later to fix the damn thing.

As for Agile and Scrum, I think that stuff is mostly dopey pixie dust that's seems progressive because it's shiny and new, but most of it's neo-Taylorism, and Taylorism didn't fucking work the first time around. "Agile" is too ill-defined to mean much anymore. As for Scrum, structuring time into "iterations" is stupid (sure, you can call a 17-day period an "iteration" just as you can call an oblique trapezoid a "skwirk" and the class of mammals over 250 pounds "mforzas" but it doesn't mean anything), and most of this agile neo-management stuff can become a bog if (through benign neglect) it re-devolves through benign neglect into normal human behavior.

One example is stand-ups. If you're going to have frequent status meetings, stand-ups are the best way to do it. People tune out in meetings of more than 5 people except to communication directly affecting their work, so there isn't much learned in them. Stand-ups exist to encourage short status meetings rather than sprawling, boring slogs, so they're a useful innovation... when people actually stand the fuck up, If people treat it as a stand-up meeting (i.e. show up on time, actually stand, and only address issues that are directly blocking work) it can be useful, but if not, it just devolves.

The real purpose of stand-ups, by the way, is to prevent the issue where people delay communication on things they need out of fear or apprehension (that is, they're afraid to ask for what they need from people) and linger around being blocked on their main project, instead doing low-priority work. The purpose of standups is to allow people to say, objectively, "this issue is blocking me" and allow group pressure (rather than management fiat) to encourage resolution. It gives the blocked person an opportunity to state a blocking issue objectively without pointing a finger and the group pressure encourages people who have the power to resolve the blocker (who now not only know the blocker exists, but know that everyone else knows that they know, i.e. "common knowledge" in the modal-logic sense) to fix it. Without something like standups to force this, people with poor communication styles or avoidant personalities can end up lingering on low-priority work for weeks. So standups can be legitimately useful. On the other hand, most of this agile "magic sauce" is neo-managerial bullshit that quickly devolves into old-style bureaucratic muck.

For example, a lot of these "agile" startups that have standups have half the people not even standing up. It can creep into an hour-long sit-down meeting... except now it happens every day instead of once every 2 weeks. So now you're having 60+ minute long, boring status meetings every day, and productivity goes way down.