Project delays: why good software estimates are impossible (2015) - <AUTHOR> http://chrismm.com/blog/project-delays-why-software-estimates/? <comment><USER2> [https://news.ycombinator.com/item?id=12149515](https://news.ycombinator.com/item?id=12149515)

</comment><comment><USER3> I feel like this has been posted before, not too long ago.

And even though it's "impossible", I and hundreds of my peers at work do it every week with a workable degree of accuracy, relative to company-wide work in progress.

In any case, the usual problems are:

1\. We software developers think we're the first to face uncertainty, including massive uncertainty. We are not. We are in fact lightweights in this department. Ask a civil, structural or plant engineer for war stories. Or read _Industrial Megaprojects_ to see how skipping a single water-temperature test cost billions of dollars.

2\. We tend to embrace the nirvana fallacy. "Perfect or very accurate estimation is worthless; therefore, _all_ estimation is worthless".

3\. "Some projects are pure research". Yes. But very few. And even they contain bog-ordinary implementation details. Writing a fantastical new language? Well guess what: parsers have been written before, and someone with data or relevant experience could break down the task into subtasks and estimate them.

I think the real reason that we so dread estimates is:

1\. They aren't treated as estimates. People turn them into deadlines. Or try to negotiate with the estimate. Which means they aren't estimates any more.

2\. We get them wildly wrong the first few times and throw our hands in the air. Improving estimates is hard. If it were easy, we wouldn't need to consciously do it.

<comment><USER4> It's because most software is under the umbrella of office people playing grown-up and not something where reality matters or thinking happens. Engineering disciplines, when faced with uncertainty do some math and decide that if the deviation of possible quantities is too close to the tolerable limits of those quantities, you have to adjust one or the other.

High school level math and problem solving plus having ever worked with software clearly state that if you have a software team, you could at the very least collect a single statistic of estimation error (actual effort over expected effort) and get a long-tail (it's going to be more more than it'll be less) distribution. Now you can spec out new projects, get values for expected effort and factor in the error distribution to get a distribution of possible actual effort for the project. If some high percentile of that distribution is more time/money than you can tolerate you have to reduce risks by cutting features or increase the budget (or have a significant fraction of projects fail).

Of course, there's lots more sophistication that could (should) go into this but even this is beyond any part of software industry I've been allowed to participate in, because it gives answers that people with authority find inconvenient.

<comment> UK-AL Yes, that is part of the problem. People asking for estimates arn't looking for probability distribution of potential completion dates.

They are looking for estimates to hold you to account, because that's how you run a good business right?

If you gave your answer to someone in management. It would just look like your trying obfuscate the answer.

<comment><USER3> > _They are looking for estimates to hold you to account, because that 's how > you run a good business right?_

There's a difference between estimates and their misuse.

<comment> UK-AL I don't think most business leaders are looking for estimates, where the developer admits it's probably way off, but it's his best guess.

Or huge range of possible release dates(because there is huge variation between the estimate and actuals), as with other estimation methods.

</comment></comment></comment></comment></comment><comment><USER5> OP means this in the sense of "good estimates for software are impossible", but I submit that the alternate reading also obtains: that estimates for GOOD software are impossible. This is because, pace Brooks, the process of creation is also the process of eliciting the requirements that demand that creation in the first place. "Good" software, software that solves a real problem in a feasible way, is rarely so well-defined at the outset that your only risk factors are difficulties in finding the right library or algorithm. Frequently it is only possible for requirements to be understood once an early version of a solution actually exists.

<comment><USER6> Perfectly well-defined software is completed software. The act of defining the requirements completely and absolutely is writing the code.

This is what distinguishes software development from other disciplines. If you want to build a bridge, you create the plans and derive your estimate from the plan. But software development is the creation of a plan. Do engineers know exactly how long that planning process takes? Probably not. It's insignificant compared to actual construction. But for software development, that is everything.

<comment><USER7> Exactly. I think we really should be comparing software development creating processes instead of creating objects.

Look at something like a consultancy that develops safety procedures for organizations or a company that handles building logistics operations.

Software doesn't have the same physical constraints that bridge building does. Anytime you have fewer constraints, you have more possible solutions which take more time to sort through.

</comment></comment></comment><comment><USER8> I've always thought, if you can, with reasonable accuracy, predict how long it will take to build a piece of software, then it's probably already done, and you should just apt-get it or whatever.

However, if it's something truly novel, then kind of by definition, it's impossible to predict how long it will take, because it's never been done before.

Of course, there's a million shades of gray in between, but it's not like bridge building. Bridges are pretty unchanged in 1000's of years. Most software you write, should be brand new, otherwise, why do it?

<comment><USER9> > _it 's probably already done, and you should just apt-get it or whatever._

This leads to the next quagmire:

How do you reliably estimate how long it takes to find the already written software that does X?

<comment><USER8> Heh. How long does apt-cache search take. Kidding, and I do recall that being a real problem for most things at one point. You'd go to FreshMeat and just _hope_ that the highest rated one was good. But, re: apt, if it gets in the main repo, then I'm hard-pressed to think I'm smarter than all those people.

That said, for some classes of software, Drupal plugins and Minecraft mods come to mind, are all varying degrees of abysmal. Those take a lot longer to sort through.

Things like "evidence based scheduling" and your permutations around "velocity" and burndown charts seem to _help_ , particularly over time, but I've found no magic bullet.

</comment></comment></comment><comment><USER10> I think it boils down to this.

1\. If you are doing something that people have done before, then it is possible to come up with a reasonable estimate. How? Just talk with someone who has done something similar before and they will help you understand the complexity involved. Example : Rubik's cube.

2\. If you are doing something that no one has done before, then it is more difficult to come up with an estimate. Example: Unified theory of forces. In the 1970, people assumed that we are very close. It's been 45 years since then and we aren't any closer.

Of course, I have often made the mistake of underestimating tasks of type 1 because I didn't talk to anyone with enough experience. Maybe this has to do with self confidence. I am very confident of my abilities so I usually tend to underestimate things rather than overestimate them.

<comment><USER11> Even 1.) is very hard to estimate, and info from people who did something similar is of quite limited value.

Skills, technical environment (system, programming language, libraries, available tooling) and team efficiency vary A LOT.

\-- Regarding your comment of overestimation: I think this is a problem for almost everyone. When you get a task described, you often think "hey, this will be easy", without understanding all the requirements in detail, the complexity it will entail or the broader effects in a system. That's where only experience can help (your own or someone elses input)

<comment><USER10> On a different note, I have heard it being said that it is better to overestimate than underestimate. This is apparently the best way to manage other people's expectations and maintain credibility.

<comment><USER12> Over is probably the wrong word. I call it realistic estimation. Every stakeholder/business person wants it done yesterday. Their job is to push and prod and squeeze out as much efficiency as possible. It's the estimators job to give a realistic estimate, which often means pushing back to a lot of pressure, and that can be very hard. It's important to realize the most important thing for the business is an estimate as close to reality as possible though. This point is often missed when there is pressure to estimate it shorter, when in fact it is not the estimate the business person wants shorter, but the complete task.

And yes, it does take time to build that trust. Often times when I'm at a new company, the business people are used to short estimates and overruns. I have to train them to understand that while my estimates are longer, they are typically closer to correct. It only takes once or twice of having something done when expected to win them over.

<comment><USER13> > Over is probably the wrong word. I call it realistic estimation.

I generate realistic estimations by attempting to overestimate and failing to do so sufficiently.

Watching coworkers try to estimate how long it'll take to deliver software really makes you wonder if pessimists actually exist, or if they're rather some kind of myth or mirage.

</comment></comment></comment></comment></comment><comment><USER14> James T. Kirk: Scotty, progress report?

Montgomery Scott: Almost done, sir! You'll be fully automated by the time we dock.

James T. Kirk: Your timing is excellent, Mr. Scott. You've fixed the barn door after the horse has come home. How much refit time before we can take her out again?

Montgomery Scott: Eight weeks, sir -- [Kirk opens his mouth] -- but ye don't have eight weeks, so I'll do it for ye in two.

James T. Kirk: Mr. Scott. Have you always multiplied your repair estimates by a factor of four?

Montgomery Scott: Certainly, sir. How else can I keep my reputation as a miracle worker?

James T. Kirk: [over the intercom] Your reputation is secure, Scotty.

[https://m.youtube.com/watch?v=t9SVhg6ZENw](https://m.youtube.com/watch?v=t9SVhg6ZENw)

<comment><USER15> This is good advice and I've actually followed it for estimating software projects. If you say 4x of what you think, and your boss/client doesn't balk, you probably have it right.

<comment><USER16> I'm roughly between 3x and 10x off, depending on the type of work. For greenfield work on small well-understood tasks and with application and test infrastructure setup, I'm ~3x off. Constantly changing complex applications without tests, I'm ~10x off. However even these multipliers have a 1-20x margin of error.

</comment></comment></comment><comment><USER17> It puzzles me why some insist on being called "Software Engineers", yet don't invest in automated, repeatable practices (i.e. true _Engineering_ ).

By all means, take risks and explore Software. But do it under the premise of Software _Development_ if Engineering practices will not be applied.

In agile environments, push for more "spikes" if estimates cannot reliably be provided for a story.

<comment><USER18> "invest in automated, repeatable practices (i.e. true Engineering)."

We do. We call those "libraries". We have more of them than most disciplines could dream of, and they work better than most disciplines could dream of.

So where most disciplines are taking the closest things to libraries they have and still applying a lot of drudge work to put them into the current context, with "unexpected work" forming small single digit percentages of the work, we get to yank all the easy drudge work off the shelf and the resulting "unexpected work" makes up the majority of what we're doing.

I'm not going to pretend everything is perfect in the land of software engineering, but the answer to "why are we so stupid that we don't do the obvious thing that people have been complaining about for 50 years now?" is that we aren't that stupid. We are very good at shrinking the obvious, easy parts of the problem down, so all that's left is the hard part. Which, since everything isn't hunky dory in the world of software engineering, we also often add to with self-inflicted injuries. Still, the amount of off-the-shelf crap that I can just push a button and have staggers the mind.

If "real engineering" worked like computer science, we'd be down to a guy pointing and five minutes of fiddling with his phone to lay a bridge down across the average river, four minutes of which would be rebuilding the bridge in various different aesthetic styles to see which suited the location best. "Do I like the fake aged wood look, or do I go with modernistic concrete? Let's see the wooden one again...."

Your homework is to write "hello world" in your favorite language and step through the resulting program in gdb or equivalent, starting from the moment the OS turns control over to the program, one assembler instruction at a time.

I apologize if this comes off a touch crabby, though upon re-reading I'm not sure exactly what to tone down about it. I'm getting really tired of the inferiority complex programmers have about "real engineering". Yes, we do real engineering. If other engineers had the advantages we had, they'd be much more "agile", and they'd make the same messes we do. They work the way they do because of the constraints they have on them, for exactly the same reason the space programmers work the way they do and for exactly the same reasons it would be wildly inappropriate for all of us to work the same way NASA does all the time.

<comment><USER19> Great points! One other remark I'll share about software engineering is that the _amount_ of engineering rigor required or warranted depends a lot upon the task and problem.

If I'm building a back-office website for a few colleagues, I may not invest the same rigor as if I'm building a website that will be accessed by hundreds of millions of people. Many software tasks do not require great rigor: you add rigor until the incremental benefit is less than the incremental cost.

As a result, I would guess that the average software engineering task is less rigorous than the average real-world engineering task, but that's only because real-world engineering frequently risks or protect lives. Even the tire rope swing, the hammock, and the treehouse put lives at risk if built poorly. The back-office website on average does not. Business might be disrupted or individuals might be inconvenienced, but typically no one can die.

Yet, many types of software involve just as much rigor if not more as other engineering disciplines. For an example, read "They Write the Right Stuff", a story of NASA avionics software engineers [0]. I consider software engineering to be an engineering discipline because of the fact that rigor is required, and because a good engineer must know how much of it is appropriate, and be able to apply it effectively. A software engineer produces software to specified reliability and tolerances, according to requirements.

[0] [https://www.fastcompany.com/28121/they-write-right- stuff](https://www.fastcompany.com/28121/they-write-right-stuff)

</comment></comment></comment><comment><USER20> This is hogwash.

As a team lead who lives in this world.=, good software estimates are not impossible. If you are doing the kind of work that you have done before, then it's very possible. If you are doing R&D, then sure it's damn near impossible. But if the work and requirements are clear, then there are plenty of ways to make "Good software estimates".

I fight estimates when I don't have a good business requirement, but tell me what your problem is and the solution you desire and I will give you a good enough estimate. Estimate is never just a date, it also includes the unit of work to be done, and the resources.

<comment> UK-AL If your doing similar work over and over again as a programmer, your not doing a good job.

<comment><USER3> Now suppose I substituted a different profession here:

> _If you 're doing similar work over and over again as a civil engineer, > you're not doing a good job._

Hmm. Not sure I feel comfortable with that.

> _If you 're doing similar work over and over again as a small business > accountant, you're not doing a good job._

Actually, I'd rather prefer you to stick to the basics, please, no need for discussions of complex derivatives of treasury stock.

> _If you 're doing similar work over and over again as an orthopaedic > surgeon, you're not doing a good job._

Thanks, but I think I'll get a second opinion.

<comment> UK-AL Civil engineering and software engineering are fundamentally different because software is digital.

You can't download the building package. You actually have to build the building again. If it's the same building I would expect them reuse the same blueprints. So that holds true.

Where as in software it's quite easy and desirable to reuse software. Which is why you should not be rewriting the same thing over and over.

As a result, the problems you face are unique. Your not just stamping out the same building again and again.

<comment><USER3> > _You actually have to build the building again._

You also have to factor engineering time into the plan. If you read _Industrial Megaprojects_ , the author shows that projects which _don 't_ do a bit of upfront estimating and research tend to go off the rails on a scale that software struggles to match.

<comment><USER7> Some upfront planning is required but, there is an overall problem with comparing software to building construction.

If you make a blueprint and give it to 2 construction companies to build the building, you'll end up with 2 very similar buildings.

If you give a software spec to 2 separate software companies you'll get 2 completely different programs.

You can't create a blueprint/spec that is sufficiently detailed so that 2 different companies/teams will build essential the same software.

A blueprint/spec that detailed would be the code itself.

The closest analog to software would be designing processes, or maybe designing a factory or assembly line. And the analog to the code in that situation would be the factory or assembly line itself.

<comment><USER21> Software shouldn't be compared to building construction, more appropriately compared to building design. Building construction is analogous to software deployment: a largely solved problem that is predictable.

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> One thing i'm a big fan of is the 'eta till the eta'. So many developers/managers often shoot from the hip with estimates - usually with the rationale that if it's all made up anyway might as well seem smart.

Yet if you spend just like 20 minutes to try and break down the tasks and do some research you can usually reduce the margin of error significantly. Our brains are good at ignoring complexity and our egos are good at telling ourselves we understand things we don't. Break it down and do you research. Stuff like poking through github repos of libraries you might be adopting. Lots of forks? lacking documentation/tests? What kinds of issues? Who is using it and why? You still can certainly still run into unexpected complexity but you get good at recognizing where it's likely to pop up. It's hard, and you won't get it right always, but it doesn't mean that shit is 'impossible'.

</comment><comment><USER23> the reason good software estimates are impossible is because the career/political cost of your project being late is less than the career/political cost of making a longer (and more correct) estimate and sticking to it.

<comment><USER24> too sad, too true :-(

</comment></comment><comment><USER25> The trick is not to say, "It will be done at exactly time X," but rather to say, "There's a 95% chance it will be done before time X."

For people having trouble with this, Jim Shore does a good job giving tips: [http://www.jamesshore.com/Agile- Book/estimating.html](http://www.jamesshore.com/Agile-Book/estimating.html)

<comment><USER26> While this may be true, most clients/managers won't accept that sort of answer.

<comment><USER25> They all accept that kind of answer......it's a matter of phrasing it correctly.

</comment></comment></comment><comment><USER27> Another one of these?

Bad estimation techniques - eg. guesses without a basis in historical data (most developers don't collect historical data) - are usually wrong. No one would argue this point.

If you do iterative development with intelligent planning and collect some historical data to use in estimates the game changes. First, most of the examples of "unexpected complexity" you gave can now be identified early and factored into your estimates. That leaves the 1% of truly unexpected stuff that you can then deal with as it comes up and factor into your future thinking in a post-mortem. Second, since you now identify risks earlier and can factor them into estimates, most of your work becomes estimable, and with historical data your estimates will improve.

There's even multiple process products around this idea already, but they're mostly used in the "safety critical" industry, see [1] [2].

[1]: [http://resources.sei.cmu.edu/library/asset- view.cfm?assetid=...](http://resources.sei.cmu.edu/library/asset- view.cfm?assetid=5283) [2]: [http://www.sei.cmu.edu/tsp/](http://www.sei.cmu.edu/tsp/)

<comment><USER28> The SEI work has been around a long time and it has had very limited success outside of academic or very controlled settings. It had its heyday in the late 90s but never really caught on broadly because it is impractical to collect the level of detail necessary, with consistent teams, languages, environments, and practices in a fast moving computing environment.

</comment></comment><comment><USER29> If you want a job as a software engineer, then you have to estimate.

</comment><comment><USER30> > Say that you are an experienced programmer, and you only run into > unexpectedly complexity about 5% of the time. If you are starting a new > project and split it up into 10 tasks [...] there's a 40% chance that you > will run into a complex task, and blow your estimations for this project.

Solution: divide the project into fewer tasks :)

<comment><USER31> Right, it is like asking a builder "how long to build my new house?" Way too many variables and things that are independent variables.

Prioritized (short) iterative development is the only path to success.

<comment><USER32> Except that if I'm hiring someone to build my house, if they tell me "well, I can guarantee you that we'll prioritize iteratively and get it done as fast as possible" I'd tell them to piss off, I can't throw good money at that. You at least need a baseline estimate, and some data as to how often things go over or under.

Apparently software engineers as a group seem to think "fuck you, it's done when we feel like it" is a valid answer?

I disagree, and have always offered estimates, probabilities and contingencies when talking to product owners when I was a lead. I tracked data, and adjusted accordingly, and ended up giving estimates that were statistically sound.

I don't necessarily expect individual contributors to do the same, but anyone that's a lead should be an adult and account for their team's actual productive capacity. This is absolutely expected of a building company, even if you don't expect a single dude with a hammer to be able to estimate how long the project will take.

<comment><USER7> Given the number of software estimates that fail and the number of software projects that collapse, the vast majority of developers are incapable of doing so.

If you are giving regularly accurate long-term estimates, I'd suggest that you create a consultancy that performs this service or teaches how to do it. Most companies and teams just aren't capable of doing this.

</comment></comment></comment></comment><comment><USER33> Quoting Charles Simonyi (1986):

"SIMONYI: We have great difficulty in predicting the time it will take to write a program. There are valid reasons why this is so. It doesn't mean we shouldn't try our best to predict, because there are reasons why a prediction might be useful, just like when a weather prediction has economic as well as other benefits.

Really good programs will live forever and take forever to write, at least as long as the hardware exists, and maybe even longer."

Source: [https://programmersatwork.wordpress.com/programmers-at- work-...](https://programmersatwork.wordpress.com/programmers-at-work-charles- simonyi/) (great book, btw!).

</comment><comment><USER34> If you have done it before it's easy to estimate how much it's going to take. Some things are actually really hard to estimate, like estimating how much root causing and fixing a bug will take.

Now, if you want to estimate properly... ask for a min time estimate, max time estimate, and confidence level.

To say "I am not sure", is actually fine. That can be the start of a conversation where you can have the opportunity to improve that estimate. Whereas a closed answer like "4 hours" won't.

</comment><comment><USER35> This is an interesting read, mostly because I remember working in the world it was murky and depressing. The unexpected happens, this is an undeniable truth but blowing estimates because of the unexpected should be an edge case and not the norm. There are 3 key thing the team I work with now does to manage the unexpected.

1\. Top level commitments should be vague

-the statement "we will build you a website" says nothing about what will be on it

2\. Scope the top level commitment, don't over scope, commit only to achievable scope

\- If you don't know if something can be done don't commit to it, commit to identifying if it is achievable. Green engineers I have worked with tended to miss deadlines and when we dug into it the problem was often that they took on tasks we didn't even want completed. Commit to delivering something you are certain you can do.

3\. Write the scope down, and stick to it.

\- A good scoping document is like a good legal contract, it keeps everyone honest while limiting liability. It gives someone a commitment they can hold you to, and it gives you an exit clause if they try to rewrite the rules. If someone tries to change your agreed scope after the fact, adding work means timelines must be adjusted and reducing timelines means work must be removed.

4\. If you work somewhere where you can't seem to make 1-3 happen find a new job its just not worth it.

<comment> UK-AL The problem with scoping a project is that no one really knows what's they want at first.

Developing software also involves discovering the real user issues by experimentation.

If you scope it, you may deliver the project, but you probsbly haven't delivered what they actually needed.

The best software is developed with feedback loops.

<comment><USER36> Yes it's no good producing a turd, even though it's an on budget and on time turd.

</comment></comment></comment><comment><USER37> Large Limits to Software Estimation: [http://scribblethink.org/Work/kcsest.pdf](http://scribblethink.org/Work/kcsest.pdf)

Mathematical Limits to Software Estimation: Supplementary Material: [http://scribblethink.org/Work/Softestim/softestim.html](http://scribblethink.org/Work/Softestim/softestim.html)

</comment><comment><USER38> It's even worse than that. Knowledge decay let you run into complex tasks earlier. Your acquired experience gets less useful over time or as stated in this article: Half of what a programmer knows will be useless in 10 years.

The way to access a Rubik's cube stays the same whereas accomplishing a coding task is enviromental dependend. Software changes over time making your experience how to solve a task redundant at some point.

</comment><comment><USER39> This is wrong. If the variables that affect estimates can be predicted, then they can be accounted for.

Source: i used to work at an organization you've heard of that could reliably predict, down to the day, how long it would take ~4000 engineers to build and release the next version of its product. Three years in advance.

<comment><USER6> I almost think it's far easier to estimate the output of 4000 engineers than the output of 10. It's also far easier to cut things to fit a deadline 3 years out.

</comment></comment><comment><USER40> The classic in the topic: Evidence Based Scheduling, by Joel Spolsky [http://www.joelonsoftware.com/items/2007/10/26.html](http://www.joelonsoftware.com/items/2007/10/26.html)

</comment><comment><USER41> Good software estimates are impossible because business stake holders don't like the true amount of time to get software done and always push to shorten the estimates.

</comment><comment><USER42> Someone once said, when estimating software projects you should multiply the time you think it will take with Pi. It has been fairly accurate so far

</comment><comment><USER43> u can build a house with just walls and a roof. Its important to understand the requirements. Then 80% of the project time will be spent polishing, so it helps to know the amount of polishing expected.

</comment><comment><USER44> Software development of novel ideas is art, not manufacturing.

</comment><comment><USER45> Software Requirements != Customer Expectations

</comment><comment><USER46> It depends largely on what you are building and the granularity (and validity) of the requirements.</comment>


Myriad brings 3x Faster Applications With New VM To Android - <AUTHOR> http://www.myriadgroup.com/Media-Centre/News/MYRIAD-BRINGS-3x-FASTER-APPLICATIONS-RICHER-GAME-GRAPHICS-AND-BETTER-BATTERY-LIFE-TO-ANDROID.aspx

<comment><USER2> Claim Posted on Internet, No Proof Supplied.

(download links? specs? papers? anything? bueller?)

<comment><USER3> The customers for this are phone vendors, who will be getting one-on-one sales pitches. They don't really need to convince _you_.

<comment><USER2> Then why post it here? "It could exist in a future phone at some point, it doesn't involve you. But here's a link, for you to read." If I shouldn't care, then why should I care?

</comment></comment></comment><comment><USER3> It's interesting that Google has a JS JIT but not a Dalvik JIT; I'd think it would be simpler.

Edit: I see they're working on it (although still in secret): [http://www.h-online.com/open/news/item/Android-s-Dalvik- to-b...](http://www.h-online.com/open/news/item/Android-s-Dalvik-to-be-JIT- boosted-861870.html)

<comment><USER4> For a relatively constrained device like an Android handset, I'd have thought it would be better to compile the bytecodes into an optimised native executable at installation time?

<comment><USER3> If the native executable is larger than bytecode, no. Now that you mention it, it would be interesting to compare dex vs. Thumb2 code size.</comment></comment></comment>


How to jailbreak iOS 6 and install Cydia - <AUTHOR> http://www.idownloadblog.com/2012/09/19/how-to-jailbreak-ios-6-and-install-cydia/

<comment><USER2> There are reasons why the jailbreak isn't officially out yet: you should not do this, and you should wait for the actual official release of redsn0w.</comment>


iTerm2 3.3 - <AUTHOR> https://iterm2.com/downloads/stable/iTerm2-3_3_0.changelog <comment><USER2> Here's some comparison of input lag:

        # Title              Min    Max   *Avg*   SD
        1 iTerm 3.3.0beta16  11.2   33.6   15.9  3.4
        2 iTerm 3.2.9        10.8   29.5   21.3  4.5
        3 hyper 3.0.2        22.3   46.9   27.6  3.6
        4 Terminal 2.9.1      2.4    8.3    5.8  0.5
        5 Alacritty 0.3.3     5.2   16.8    6.3  1.4
        6 Kitty 0.14.3        7.7   11.6    9.6  0.8

Measured using [https://github.com/pavelfatin/typometer](https://github.com/pavelfatin/typometer)

Edit: Added iTerm 3.2.9 (2) added alacritty (3) added Kitty

<comment><USER3> Could someone explain to me terminal performance and what these numbers practically mean? It's a complete mystery to me. It's so incredibly variable, the fact that I notice variability as a user really perturbs me, it's 2019, and displaying a matrix of a few thousand characters is still a challenge.

I live in fullscreen iTerm, Tmux and Vim. I have 256 colours enabled. Vim has lazy redraw enabled. I'm on a 2018 MacBook pro. Scrolling is smooth _only_ when connected to power (probably related to CPU throttling - but it's 2019 and it shouldn't matter). iTerm is significantly faster than Terminal when resizing Tmux panes and Vim windows. I've had similar issues on Linux.

The only terminal emulator that has decent performance scrolling and resizing Vim buffers Alacritty.

What's going on? Why is there a bottleneck here? Is it rendering the text? Is that still hard to do in 2019? I don't understand the technical challenge of parsing a protocol that would literally work on a real VT100 sans some escape sequences and colours.

<comment><USER4> I have found iTerm to have _very_ bad performance relative to Terminal.app. I honestly have no clue why its so popular, I cannot stand it.

<comment><USER5> For me it's only 1 feature: the profiles window. I configure them as ssh to hosts. And then I have a decal/text in the corner + a color in the bg. But most importantly is the favorites manager

<comment><USER6> I do this in my ssh config to get what I assume is the same effect with the iTerm badge.

      Host * !github.com
        LocalCommand printf '\e]7;file://%n/\a'
        PermitLocalCommand yes

</comment></comment></comment></comment></comment><comment><USER7> @gnachman Thank you for iTerm! Despite major workflow changes, iTerm has remained my daily driver for years.

If you in a position to support free software, I kindly suggest donating to George's Patreon: [https://www.patreon.com/gnachman/](https://www.patreon.com/gnachman/)

</comment><comment><USER8> When I moved back from the betas, the minimal theme is what I missed the most. Its so clean. Combine that with the status bar at the bottom, and I'm in heaven.

It's one of the few pieces of software that I really miss when I'm on my linux boxes -- even if its purely aesthetic.

edit: if you want your status bar at the bottom, Prefs > Appearance > General > Status Bar Location

<comment><USER9> Don't see the status bar, or there isn't anything in the status bar :(

<comment><USER10> You might have to manually enable it for your profile

[https://www.iterm2.com/3.3/documentation-status- bar.html](https://www.iterm2.com/3.3/documentation-status-bar.html)

</comment></comment></comment><comment><USER11> Kudos to Mr. Nachman on continuing to develop a terrific piece of macOS software!

I've been running the 3.3 betas for a while and some of the new functionality is really great. Exporting a recording of a terminal session from the "Instant Replay" panel is very handy!

</comment><comment><USER12> For a person who is comfortable with Tmux, is there any significant benefit that iTerm offers over the Terminal.app? I believe Terminal.app is better than other consoles when it comes to power consumption.

<comment><USER13> If you like tmux, you should try the tmux integration feature in iTerm. It makes tmux windows native windows, and tmux panes native panes.

<comment><USER14> And what's the advantage of a native pane over a tmux pane? Could you clarify?

<comment><USER13> Being able to use native macOS shortcuts like Command-` to move between windows. Native copy–paste. Focus-follow-mouse behavior for panes. Or just the ability to see multiple tmux windows (not panes) at once. And perhaps most importantly, the tmux windows actually look any any other window on macOS.

<comment><USER15> Huh, all those are features of tmux itself. I can copy/paste to/from system clipboard, I can easily movie between windows (and could set in my tmux.conf to use Command-` if I wanted), I can focus panes with the mouse, etc.

</comment></comment></comment></comment></comment><comment><USER16> If windows had iTerm2, I am pretty sure I could let my last mac go. Everything we have for windows is as good as a piece of iTerm2, but none of them bring it all together.

<comment><USER17> I'm pretty happy with ConEmu [0] and the linux-shell on Windows after years of using OSX.

[0]:[https://conemu.github.io/](https://conemu.github.io/)

<comment> james-skemp I use it since I view Cmder - [https://cmder.net/](https://cmder.net/)

Developer is responsive and it adds enough to the experience to make it worthwhile as a wrapper.

</comment></comment></comment><comment><USER18> Wow, the new Python API looks incredible.

[https://iterm2.com/python-api/](https://iterm2.com/python-api/)

[https://iterm2.com/python-api/tutorial/](https://iterm2.com/python- api/tutorial/)

<comment><USER19> Yes. Now I can finally script shell and terminal colors changes for day/night/late night. Tmux and status bar control API should let me get all the magic out of Zsh prompt.

<comment><USER11> see [https://iterm2.com/python- api/examples/darknight.html](https://iterm2.com/python- api/examples/darknight.html) and [https://iterm2.com/python- api/examples/theme.html](https://iterm2.com/python-api/examples/theme.html)

<comment><USER19> Thank you! Just what I was wishing for.

Now I wonder if I could make Sublime Text / VS Code style command palette within iTerm... Probably requires Python shell script as front. I didn't yet find mention of custom dialogs or the like in the API docs.

<comment><USER18> Not sure if there's extensibility yet but the View > Open Quickly palette is a primitive start.

Do you have specific use cases in mind?

<comment><USER19> I was checking quick open actually for its possible extensions. It does mention /s to "run script" but didn't find it mentioned in the docs.

I'm looking to get:

\- switch layout and run server/compile start commands and the like for given project \- call my own shell scripts and assorted helpers from terminal's context \- get Jupyter notebook running and console connected to it \- connect to tmux session on host or start one with given layout if it isn't there \- Kubernetes and Docker context in their own tabs \- Quick Open can probably take care of finding tabs and ssh sessions so need to learn to remember it's there

That's the first things I find myself constantly doing manually. Nothing that can't be done, say, with regular shell and TMUX stuff, but those have so low level control mechanisms. I'm hoping Python access to gives same power with less work.

<comment><USER18> Oh interesting. I didn't realize it had slash commands either.

It's briefly mentioned under "View > Open Quickly" on [https://www.iterm2.com/3.3/documentation-menu- items.html](https://www.iterm2.com/3.3/documentation-menu-items.html):

> If you have lots of sessions you can quickly find the one you're looking for > with Open Quickly. Select the View > Open Quickly menu item (cmd-shift-O) > and then enter a search query. You can search by tab title, command name, > host name, user name, profile name, directory name, badge label, and more. > Queries are scored according to relevance and sorted by score. Open Quickly > also lets you create new tabs, change the current session's profile, open > arrangements, and change the color preset. If you start your query with a / > then that gives you a shortcut to various commands. /a followed by an > arrangement name restores the arrangement. /f restricts the query to > existing sessions, excluding options to open new tabs, etc. /p restrics the > query to profile names to switch the current session to. /t restricts the > results to "open new tab" for matching profile names. /c restricts the > results to color presets.

I think with /s and creating custom scripts you could wire up some of these use cases.

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> Anyone using Hyper? I played with it but pretty quickly reverted back to iTerm2. In fact iTerm2 is basically the first thing I install on a new system along with ZSH/Oh my ZSH.

<comment><USER2> Hyper is usable, and it has become rather fast when they switched the backend a few months ago. It's real promise is in scriptability, and, unfortunately, there aren't any must-have extensions for it.

I think there are quite a few low-hanging fruits for the terminal, such as better integration with documentation or using an actually good language such as ruby directly on the command line. If I ever get around to try some of those ideas, I'd use Hyper as the platform.

<comment><USER21> There is no reason for me to use Hyper really.

The reason I stick with VSCode even though it's slower than other editors is because of the features.

Hyper has non of those.

</comment></comment></comment><comment><USER22> I like having options but wouldn't recommend iTerm.

Apple's Terminal.app is more performant rendering text and more responsive to input while admittedly having somewhat less unnecessary features.

In fact, iTerm is one of the slowest terminals out there!

See: [https://danluu.com/term-latency/](https://danluu.com/term-latency/)

iTerm used to have a lot of really compelling stuff that was missing from the official terminal like tabs, etc... that made straying away from the canonical terminal app worth it but most of them eventually made their way to Terminal.app so nowadays it's mostly just fluff.

<comment><USER23> Might be a dumb question, how do you split the terminal vertically or horizontally, and hide and un-hide the split terminals on Terminal.app? Without tmux or screen.

I have tried Terminal.app multiple times, but have come back to iTerm2 every time because I've not been able to figure out how to do that.

<comment><USER24> Disclaimer: I'm not poking at iTerm, its my MacOS terminal emulator of choice.

Why _not_ use tmux? It is pretty fantastic software, and IMO provides a much better interaction model. iTerm itself is even integrated w/ tmux through control mode.

<comment><USER23> Hah - I probably should! I've been impressed every time I see coworkers using it. Especially suspending and unsuspending remote sessions and everything.

When I'm on linux I end up using Konsole or Terminator (depending on the env) which support this functionality. So other than the saving remote sessions - which looks really cool - I've not had a strong impetus to learn tmux.

<comment><USER24> Its worth learning IMO. There is a learning curve, and the default configuration is unfriendly. If you are interested here are some things I found helpful:

1) Rebind the prefix key from ctrl-b to ctrl-space. 2) Map alt-h,alt-j,alt-k,alt-l to move between window panes. 3) Remap the split keys to something more accessible. 4) Start numbering windows at 1 instead of 0 (makes switching more intuitive imo). 5) Steal a simple configuration for the status bar from the internet.

Beyond that, the defaults are pretty straightforward, and you don't really need to know much to get started. I can share my config if someone is interested.

</comment></comment></comment></comment></comment><comment><USER25> I have found the new design around the tabs to be very nice. The status bar looks neat, but it doesn't seem to carry over to tabs created by tmux sessions so I never see it. I also wish there was a way to put that status bar at the bottom.

<comment><USER26> There is a way, look in Apperance - General - Status bar location.

<comment><USER27> Thank you so very much, stranger on the net. Was looking for this today.

</comment></comment></comment><comment><USER28> I moved away from MacOS on my desktop/workstation to Linux and one of the things I've missed actually was iTerm2. Really great terminal altogether. However, I found a great replacement, even better in some ways - Kitty!

<comment><USER29> KDE's terminal app Konsole is great and really ITerm-like at least with my usage patterns.

</comment></comment><comment><USER30> iTerm2 is a treasure. Such a great app.

The new minimal and compact themes look great. Is it possible to drag the window when they are active? It looks like the drag region is reduced to a small area around the stoplight buttons.

</comment><comment><USER31> iTerm2 is my go-to terminal on OS X. It used to be kind of sluggish but recent iterations have been snappy, which is exactly what I need with the command- line.

</comment><comment><USER32> Just switched back to Terminal.app because iTerm is a bit of an energy hog. I run a pretty stock bash shell. Anyone else? Any tips for improving it?

</comment><comment><USER19> I've been using betas for a while now. Update check don't seem to notice new releases so I was running old version for longest time before I noticed. Speaks to beta cycle's stability.

iTerm is one app that is always on and in use. Especially thanks to its fast full screen switching and transparent tmux integration. I've been contributing through Patreon and consider that money well spent.

</comment><comment><USER33> Thanks for the release. Excited about the scripting API. Sometime I wanted to add "autocomplete" features to iTerms (just like on phones), but the completion predictions will be sourced from stackoverflow. When user types a part of the command, I was planning to add an extra line to the current list of predictions (which are taken from bash command history). Unfortunately, append operation was not supported because of the way the code was written(by the time key is pressed, list is already populated and sent to the handler). So, I could not proceed then.

Hopefully this python API fixes the problem.

<comment><USER34> The API was originally designed for a third-party app to add autocomplete. That never happened, but it should have everything you need.

<comment><USER33> Looks like exactly my usecase. Thanks to third party for not completing!

</comment></comment></comment><comment><USER35> iTerm is awesome, thanks for the great work! Using macOS without an alternative to Yakuake would have been extremely painful.

Two pain points I'm running into with this release:

1\. The tab titles just say the profile name (in my case, "Quake-style") rather than the foreground process name (bash, curl, etc.). It's subtle, but annoying given that I've become accustomed to relying on that information to quickly differentiate between tabs.

2\. When I close every open tab and then re-open iTerm with my hotkey (F12), it starts off minimized and I have to drag the cursor over to the dock to manually open the window.

</comment><comment><USER36> "\- Add touch bar mitigations: haptic feedback, key click, and blink cursor when touching esc."

Thank you for this! Can't believe how many times per day I accidentally trigger touch bar Esc.

<comment><USER15> Because of the touch bar I was motived to switch Esc to Caps Lock (using Karabiner Elements), but I have since switched it over on all my machines (i.e. those without touchbars) because it's so convenient/ergonomic.

<comment><USER37> I've enjoyed having Ctrl where Caps should be so much, and my right hand missed having a Ctrl key on these small Mac keyboards, so I turned the Enter key into Ctrl as well! (Possible as a Complex Modification in Karabiner: "post left_ctrl when enter_or_return is held", so that tapping Enter is still treated like the Enter key)

</comment></comment></comment><comment><USER38> First off, wow love the status bar idea.

Second, I'm not sure if this is a bug or a profile configuration I have, but when I have my tabs to the left in the new minimal mode I think my terminal is clipping the window bar:

[https://i.imgur.com/W94XwI3.png](https://i.imgur.com/W94XwI3.png)

Edit: possible GitLab issue [https://gitlab.com/gnachman/iterm2/issues/7988](https://gitlab.com/gnachman/iterm2/issues/7988)

<comment><USER39> How did you accomplish the tabs on the left?

<comment><USER38> iTerm2 > Preferences > Appearance > General > "Tab bar location:" > Set to "Left"

:)

</comment></comment></comment><comment><USER40> Honest question for the folks complaining about input lag, does this actually effect your typing of text/commands into the terminal? I feel like I am particularly sensitive to latency in the audio world (such as recording though effects or using virtual instruments), but I work all day long in iTerm2 and never once have I thought to myself that text is not appearing fast enough as I type it. Is this problem exacerbated when like pasting a huge chunk of text into vim or something?

</comment><comment><USER41> The new features after the app updated were introduced really well, I thought, especially the try it now button beneath the screenshot of each feature. I probably made an audible but quiet oooh at each of the features and enabled all of them, and already have a couple of ideas for building some work things for the status bar.

</comment><comment><USER42> Is anyone else having problems with vim? Specifically, I can't see my cursor since upgrading.

I don't really remember what my cursor looked like before the upgrade; maybe it was a red block? But now you can't see it.

My cursor outside of vim is fine.

</comment><comment><USER43> imgcat is very useful for me. Glad they are still maintaining it.

<comment><USER44> Yes! I love imgcat. When working on a project with lots of images, imgcat + mc in iterm2 was a golden combination.

Never use tmux, just tabs in iterm.

</comment></comment><comment><USER45> I just enabled the status bar (in Session) but it seems to not show up for me. I'm using a custom theme but I've tried the default themes.

</comment><comment> dfeojm-zlib Is there any way to disable this scripting API? It seems like an enormous security hole.

<comment><USER34> This has been considered. See here for details:

[https://gitlab.com/gnachman/iterm2/wikis/iTerm2-Version-3.3-...](https://gitlab.com/gnachman/iterm2/wikis/iTerm2-Version-3.3-Security- Updates)

</comment></comment><comment><USER46> I use the default terminal + fish shell (+some plugins) + fzf + tmux

</comment><comment><USER47> Minimal Theme and a new Dock Icon, im sold !! Amazing work

</comment><comment><USER48> iTerm2 is incredible. I recently tried alacritty, though, and was amazed by how much faster it is with screen redraws on my 2014 Macbook Pro. I was shocked the first time I used mouse scrolling in vim through Alacritty and found that it was as snappy as in a native app; it never occurred to me that, even for a small pane, the bottleneck was in the emulator. I had to reimplement some of my favorite shortcuts for tab/pane management in tmux, but overall everything is running _lightning_ fast thanks to alacritty's optimized, GPU-accelerated rendering. Alacritty also uses a dirt-simply YAML file for config (which I prefer to a GUI solution) and is cross-platform (which means I'll be able to install this same setup, with tweaked shortcuts, on my Windows box next time I use it).

The new iTerm features sound really awesome, but the one thing I'm already missing badly is inline image-rendering via escape codes. I had a great workflow set up on for viewing astrophysical data products on a remote analysis server using the itermplot matplotlib backend to render plots directly in my terminal from ipython. I'm still planning on firing up iTerm2 for that use case.

All that said, iTerm2 is the best terminal emulator I've ever used, especially when you're first learning things. I probably wouldn't have been able to switch to tmux as easily if I hadn't already used it a bunch through iTerm2's beautiful tmux integration (I'd already configured some tmux functionality for that use case). The aforementioned image-rendering should be a universal feature for terminals. And though the input and redraw lag are higher than Alacritty or Terminal.app, it's always been fast enough. I still recommend it to people with Macs who are just starting to program.

That said, if you're a speed addict and want something with limited but easily-configurable features, give Alacritty a try!

[edit] I should also mention that, if you're willing to put in more effort, you can implement a ton of iTerm2's visual bonuses (like the status bar and pretty icons) with a combination of a Nerd font [0] (particularly a pretty modern one like Iosevka [1]) and an advanced tmux configuration [2].

[0] [https://github.com/ryanoasis/nerd- fonts](https://github.com/ryanoasis/nerd-fonts)

[1] [https://github.com/ryanoasis/nerd- fonts/tree/master/patched-...](https://github.com/ryanoasis/nerd- fonts/tree/master/patched-fonts/Iosevka)

[2] [https://github.com/samoshkin/tmux- config](https://github.com/samoshkin/tmux-config)

<comment><USER49> Thanks, that was cool hearing about your use of itermplot :-)

[https://github.com/daleroberts/itermplot](https://github.com/daleroberts/itermplot)

<comment><USER48> I think I've thanked you before in the HN comments for it, but thank you again!! itermplot is one of those great tools that actually makes things _just work_ in a pinch. I wrote/maintain a low-latency gravitational wave/high- energy neutrino joint source search, and crazy stuff is always happening. Being able to throw together plots and just see them in my terminal right away helps me maintain my sanity ^_^

</comment></comment></comment><comment><USER50> Seems good

</comment><comment><USER51> Does it have an Undo button? If not, I'm sticking to MacOS Terminal.

<comment><USER52> Undo what exactly?

<comment><USER51> My typical typo: rm -rf /

</comment></comment></comment><comment><USER53> > 3.3.0

> Major version

Why do people hate semantic versioning so much? Just call it 4.0.0 if it's a major version, or if it's not, don't call it major.</comment>


Ask HN: Which podcasts do you listen to? - <AUTHOR>

<comment><USER2> This comes up from time to time, so here are the ones that I subscribe to (and get OCD about making sure I'm caught up on).

There's others that I might listen to here or there, but these are the main ones:

\- Informative

 _After Dark_ : Overflow from other 5by5 shows. Usually less than a half-hour, frequently funny. Probably not recommended if you don't also listen to the other shows on the network.

 _Back to Work_ : Ostensibly a show about getting to what's important with Merlin Mann and Dan Benjamin. If you like Merlin's stuff, you'll like the show. Frequently goes off on tangents, but some of the recurring bits are awesome and hysterical.

 _Build and Analyze_ : Marco Arment's show. Also ostensibly about development, but basically topics meander (I think to the show's credit). This was the hardest 5by5 show for me to initially get in to (I think I was initially hesitant because I assumed it was going to be all iOS stuff), but I now enjoy it greatly.

 _The Critical Path_ : Horace Dedieu's show. This one snuck up on me, but I really like the way Horace presents information. Probably the least funny show I listen to regularly, but one of the more informative ones.

 _Exotic Liability_ : This one should probably be in the entertaining category, as it's a security podcast that very rarely talks about security. Probably not for everyone (not even all security people), but I find it endearing.

 _The FunctionSource Show_ : There's only been a couple of episodes of this one, so it might be dead. The first couple episodes have been really really good though. Basically, thoughts on the web, and programming in general. The hosts are great.

 _Herding Code_ : This is a fairly recent addition to my list. I'm always looking for an actual good development podcast (that's actually about development), and this one is usually interesting. There's a bunch of hosts though, and I find it really difficult to tell who is talking.

 _Hypercritical_ : This has quickly become my favorite podcast. It's just John Siracusa complaining about things, but for some reason, it's much better than that tagline would have you believe. I feel like Siracusa is a kindred spirit, so maybe that's why I look forward to his show as much as I do.

 _Startalk_ : Neil Degrasse Tyson's podcast. I shouldn't really have to explain it any more than that.

 _The Talk Show_ : The world can be split into people who like Gruber, and people who think he's an asshole. Thankfully, the two aren't mutually exclusive, and I really like listening to his show. In particular, the latest episode (where he might have been celebrating beforehand) is definitely the best of the bunch (and one of my favorite podcasts of all time).

 _This Developer's Life_ : Scott Hanselman and Rob Connery talk about things developer-related (but it's not at it's core a technical podcast). I really like this one, they do a great job with it.

\- Entertaining

 _Comedy Bang Bang_ : Easily the best podcast I listen to. Always hilarious. I'm embarrassed to get so much value out of something that's free. The show is usually a bunch of comedians (some of whom are being interviewed, and some of whom are doing impersonations of characters), but is flat out the funniest thing I've found available in any medium.

 _Doug Loves Movies_ : Usually recorded live, and it's a panel of famous people who are interviewed by Doug Benson (the comedian). Episodes are mostly made up of the panel playing a game Doug made up called "The Leonard Maltin Game", which is way more amusing to listen to than it should be.

 _Geek Friday_ : This might be dead (or just on hiatus), but it was a show of Dan Benjamin and Faith Corpi talking about geek-related things. Usually very funny.

 _Gelmania_ : Bret Gelman is a comedian who I first heard of from his appearances on Comedy Bang Bang. His style is very aggressive (it's part of his act), but I think his show is awesome.

 _How Did This Get Made_?: A bunch of people pick a terrible movie and then talk about it. It's usually really really funny.

 _improv4humans_ : A fairly new show. Basically it's recorded improv. They take suggestions on Twitter ahead of time and then construct scenes. So far, they've all been really good (which is more than I can say for most live improv).

 _Nerdist Writers Panel_ : This might not be interesting to the public at large, but I find it fascinating (and usually pretty funny). It's a recorded panel of TV writers. They talk about their experiences writing on shows.

 _The Pod F. Tompkast_ : Paul F. Tompkins is my favorite part of Comedy Bang Bang, and his podcast is fantastic.

 _Roderick on the Line_ : New-ish show with Merlin Mann and John Roderick (musician, and super funny guy). It has no rhyme or reason (which might turn off some, as it meanders), but so far they've all been entertainment gold.

 _Thrilling Adventure Hour_ : This is actually a live show in Los Angeles, but they release segments as a podcast. It's billed as "old-timey radio", and most of the segments are fantastic. Specifically, "Beyond Belief" is my favorite.

</comment><comment><USER3> My job involves a lot of mindless tasks (molecular/cellular neuroscience - culturing cells is much less exciting than you'd think). This affords me plenty of time to listen to podcasts. My favorites in no particular order:

Economy/Finance:

-Motley Fool: <http://wiki.fool.com/Motley_Fool_Money_Radio_Show>

-Market Foolery: <http://wiki.fool.com/MarketFoolery>

-EconTalk: <http://econtalk.org/>

-Planet Money: <http://www.npr.org/blogs/money/>

-American Public Media Marketplace: <http://www.marketplace.org/>

_______________________________________

Startup/Tech:

-Startups for the Rest of Us: <http://www.startupsfortherestofus.com/>

-TechZing: <http://techzinglive.com/>

-Lifestyle Business Podcast: <http://www.lifestylebusinesspodcast.com/>

-Entrepreneurial Thought Leader Seminar: <http://etl.stanford.edu/>

-Coder Talk: <http://codertalkshow.com/>

_______________________________________

Miscellaneous:

-Think: <http://www.kera.org/think/>

-Caustic Soda: <http://www.causticsodapodcast.com/>

-Science Magazine: <http://www.sciencemag.org/site/multimedia/podcast/>

-Astronomy Cast: <http://www.astronomycast.com/>

-It's All Politics: <http://www.npr.org/blogs/itsallpolitics/>

</comment><comment><USER4> Economics: Russ Robert's EconTalk at <http://econtalk.org>

Videogames: GamersWithJobs Conference Call: <http://gamerswithjobs.com>

Sports: Mike and Mike in the Morning Radio Podcast: <http://espn.go.com/espnradio/show?showId=mikeandmike>

All subscribable via iTunes.

</comment><comment><USER5> I have to recommend The History of Rome podcast anytime I have an opportunity. Mike Duncan does a great job "storytelling" the history, and is very up front about what should be accepted as relative fact (strong sources) vs. the more uncertain elements from the more questionable sources. It's great if you're driving a lot.

<http://thehistoryofrome.typepad.com/>

<comment><USER6> Thanks for the link. I also recommend Hardcore History[1], by Dan Carlin. He recently did a series on the fall of the Roman republic, which I liked a lot. Dan Carlin also has a political podcast titled Common Sense[2], which is also very interesting even if a bit US centered.

[1] <http://www.dancarlin.com/disp.php/hharchive> [2] <http://www.dancarlin.com/disp.php/csarchive>

</comment></comment><comment><USER7> To get most all my news I listen to the following: (sorry, no English broadcasters except sometimes BBC)

das Computermagazin - B5, VOA - Voice of America in Spanish, ciencia al cubo, Wirtschaft - Deutsche Welle, Klartext - from sveriges radio,

In case anyone understands German I'd definitely recommend Computermagazin, runs 20 minutes and stays compact (I agree with zrail don't like much blabber, give me the facts )

</comment><comment><USER8> The boring basics. Radiolab, Stuff You Should Know, and Planet Money are my go-to podcasts. I can't really stand anything that's too much like talk radio, especially when I'm at the gym (where I listen to podcasts.)

</comment><comment><USER9> When do you people have time to listen to podcasts? Reading blogs/RSS is much less time-intensive.

Also, for those occasions when people insist on delivering information via embedded video only, why don't contemporary embedded players have a "replay at 2x speed" button? I can listen faster than you can talk (and if you actually say something that makes me think, I can find the pause button just fine).

<comment><USER10> Commute + treadmill

</comment></comment><comment><USER11> You Look Nice Today, This American Life, Back to Work, Savage Lovecast. I tend to listen to podcasts on my meal breaks at work and at home for background noise. I can't stand listening to them while I'm actually trying to do work, because I have a hard time paying attention to two things at once.

</comment><comment><USER12> I don't listen to podcasts, but I participate in a weekly podcast...is that bad? It's a videogame podcast if anyone's interested. <http://feeds.feedburner.com/gamerhighway>

</comment><comment><USER13> The only one I'm listening to at the moment is nodeup: <http://nodeup.com/>

The podcasters are some of the central figures in the node world and always have useful content.

</comment><comment><USER14> Adam Carolla (<http://www.adamcarolla.com>). I grew up with comedy, and it helps a lot whenever i'm commuting/treadmilling

</comment><comment><USER15> I really like "This American Life", it's not related to technology directly but it's sometimes very inspiring about how people do things. Also listen to "Planet Money".

</comment><comment><USER16> If you're a subscriber, the Economist iPhone / Android app has an audio edition which is quite good.

</comment><comment><USER17> "Hipster Runoff", it's hilarious.

</comment><comment><USER18> Tech Zing.

</comment><comment><USER19> Radiolab

</comment><comment><USER20> Mixergy</comment>