And you are here why?

/via http://www.commitstrip.com/en/2013/08/01/moment-de-solitude/ I — literally — have no idea how many different types of ToDo lists I’ve worked my way through in my life. Off the top of my head, I’ve used • Post-Its : with the inevitable breakage when they fell off the monitor without my noticing) • TextEdit : Oh the fun when the laptop crashed, and my list hadn’t been saved. • OneNote : All well and good, till I switched to OSX… • Trello : Huh, I’m spending so much time tagging and categorizing my ToDos, I don’t actually have any time to actually  do  them. • JIRA : That one time I  Kanban ’d my way to using JIRA for my ToDos. It was excessively silly • Keep : Surprisingly effective. Really. Go figure. • Email : Ah, the old standby. Give that I’m always hovering pretty close to ZeroInbox, email does work extremely well. And lord knows how many other things. That said, I’m currently in an  Email + Keep  kinda place. What about you?

/via http://www.commitstrip.com/en/2017/02/28/definitely-not-lazy/ We’ve all done this, or an equivalent in the past, no? (•) Then again, there  is  a bit of a point here, the balance between laziness (“ I can’t be bothered to type it again ”), accuracy (“ It’s something complex, and I’d rather not have to look up the  grep options again ”), and safety (“ I know what works correctly, and I’m going to keep re-using it ”) So much of our day-to-day existence consists of adjusting for this balance, and it is  a significant reason to put Process in place . So yeah, it’s definitely laziness for  ls , but maybe not so much for other stuff… (•) history | grep ls  

How do you know? I mean, if you’ve been in the biz. for a while, you’ve probably got all sorts of metrics that you use to track this. OTOH, if you’re just getting into the game — either as a new biz, or through an unexpected promotion — then, well, how do you   know? There are many,   many   ways to do this, but there   is   One Simple Trick (sorry!) that you can use to figure out how things are progressing, and that involves looking at your BOM. What you want to do is keep track of it, and more importantly, keep track of how frequently it changes. (•) To put it simply, the more frequently it changes, a) the more rework you have to do to just get the system back to steady-state, and b) the less opportunity you have to build stuff on top of the hardware Remember, hardware, in general, is far less tolerant of incessant adjustments (yeah, neither is software, but it gets much worse with hardware). And, all the time you spend in fixing everything that broke ...

To be precise, Schlong size is rarely evidence of operational efficiency Huh? What? Are we talking about pr0n here? Actually, no, we're talking about conflict resolution in a business setting, which inevitably tend to tun to rams butting heads, stags locking horns, etc. etc. Many (all?) of these invariably end up as some variation of "I am correct because "  Look at my resume. I was doing this back when you wore diapers See these gray hairs? Thats experience! The boss is my poker buddy. etc. etc. Corollary 1 The moment this argument is made, all sides lose. On the face of it, "I am correct because, well, Look how well endowed I am!" - is an argument whose essential ridiculousness is pretty immediately apparent once it is called out.  I mean, seriously, is this where we want to be? Not exactly the most effective determinant, eh? The problem, however, is that at best you can hope to try and match sizes, and at worst, well, you already a...

The two languages I am most comfortable with nowadays are erlang/OTP and perl - which, strangely enough, makes me quite remarkably non -conflicted.  The key, I guess, is that they are so different, with the core use-cases being so fundamentally distinctive, that there really isn't that much of a context switch for me to move from one to the other.  And, of course, given their radically different natures, I rarely (never?) ever use one when I should have used the other. Erlang/OTP, of course, is your classic massively concurrent fault-tolerant distributed infrastructure language, which pretty much gives you all the aforesaid buzz-word properties by default.  You have to work, and quite hard at that, at making your system behave badly.   I could go on and on about why its the greatest thing ever, but others have done it far better (e.g. John Bender here or Alex here ), but I will say that once you have tested the beauty of the built-in concurrency, sup...

Edward A. Lee (of Ptolemy fame) is the Robert S. Pepper Distinguished Professor at U.C. Berkeley, and knows a thing or two about designing and building concurrent systems.  He also has a hate-hate relationship with Threads, as evidenced by my perusal of The Problem with Threads (Jan 2006).  For example Threads [...] are wildly non-deterministic  non-trivial multi-threaded programs are incomprehensible to humans we […] require that programmers of multi-threaded systems be insane. Were they sane, they could not understand their programs If we expect concurrent programming to be mainstream, and if we demand reliability and predictability from programs, then we must discard threads as a programming model  And there is more, oh so much more.  Just read the whole thing - its wickedly entertaining, and makes its points with no small amount of wit and humor.  Herewith a quick look at the points made in the paper. Note : All of the below applies to T...