Start all of your commands with a comma (2009) - <AUTHOR> https://rhodesmill.org/brandon/2009/commands-with-comma/ <comment><USER2> This is clever given what we have, but it seems like the wrong solution to the problem.

I already have a PATH order. What would be nice is if typing say `sc` gave me the first `sc` program, but typing `,sc` gave me the one after that.

This would generalize, so if I were stuck with _cough_ several pythons I could call them with `python`, `,python`, `,,python` and so forth.

This would be a shell-level patch but surely not an impossible one.

Ironically, the one person whose workflow this would clobber is the one who wrote this blog post!

<comment><USER3> Your solution requires shell support and is incompatible with previous code, while the author's solution works today.

Who has the wrong solution now?

<comment><USER4> Software can be bad.

</comment></comment></comment><comment><USER5> Seemingly this is just as a cheap version of namespacing or something in the event something comes out that uses the same name as a name you chose, rather than actually being about "overriding"?

Because otherwise why not just do what I assume everyone else does, and put ~/bin _before_ everything else on your PATH?

<comment><USER6> It's to avoid collisions altogether, not to prioritize the custom commands over the standard ones.

For example, let's say I have a script that improves upon the systemctl command, and I want to use it all the time and not type a bunch of characters to invoke it. I might call it "sc", forgetting that I also use the spreadsheet calculator sometimes.

If I always prefix, then ",sc" is my shortcut, and "sc" is the spreadsheet calculator.

<comment><USER7> There isn't just the risk of a name clash between programs that you use. It's a hygiene problem: a clash that you don't know about, involving some program you don't use (or not directly).

The system programs can potentially rely on each other, invoking each other in a way that relies on PATH searching, and not set PATH to a sane value when they are invoked. Your utility can accidentally shadow something and break the program whicc relies on it.

In other words, setting PATH to point to ~/bin first breaks unhygienic programs which blindly inherit PATH --- which is pretty much all non-setuid programs in a Unix-like system!

Setting PATH to point to your ~/bin last, on the other and, potentially breaks _your_ programs when they call each other (in a way that relies on path searching), and are shadowed by new system programs. A fix for that is to to put ~/bin last, and ensure that all your programs refer to each other in a way that doesn't rely on PATH. E.g. _prog_ is invoked as _$bob_utils /prog_.

</comment></comment></comment><comment><USER7> According to POSIX, variables that contain lower-case letters are for application use. If Debian (or whoever) introduces such variable names, they are being nonconforming.

For instance, my programs might be in /home/kaz/bin. Suppose I create a one- letter variable:

      k=/home/kaz/bin

Then /home/kaz/bin/foo can be run as

      $k/foo

Bash will complete on this. Firstly, $k[Tab] will add the missing slash to make $k/. Then if Tab is hit twice, the completions under /home/kaz/bin are shown.

Since k contains an absolute path, it does not rely on PATH searching.

The programs under $k/ can refer to each other using the $k/ notation, without relying on PATH.

The comma notation relies on PATH. When the ,foo script wants to invoke the ,bar script and just calls it ,bar args ... that relies on PATH containing the directory in which ,bar lives.

For interactive use, I'd use PATH anyway: put /home/kaz/bin _at the end_. Then if the system shadows one of my programs _prog_ , I can just use ~/utils/prog or $k/prog to detour around the clashing system program. My programs themselves don't rely on PATH for calling each other, so they are immune to the shadowing, and since I added the new PATH element at the end, I haven't perpetrated any shadowing that would break system programs.

<comment><USER8> If you are using absolute paths, I found this easier to get used to:

        hash -d b=/home/me/bin

Then you call foo as:

        ~b/foo

I have an array of these defined to my most used directories.

<comment><USER9> I believe hash -d and supsequent expansion of those paths only works in ZSH, which calls this "static named directories" ([http://zsh.sourceforge.net/Doc/Release/Expansion.html#Static...](http://zsh.sourceforge.net/Doc/Release/Expansion.html#Static- named-directories)).

</comment></comment></comment><comment><USER10> Many Lisp REPLs require you to prefix REPL metacommands with a comma. This helps distinguish between metacommands and variables to be evaluated, because the comma is the unquote operator to the Lisp reader, and is unlikely to occur in a Lisp expression outside a quasiquoted sexpr.

</comment><comment><USER11> This is a great idea. I would have assumed by default, with no particular reason, that tools would choke at least on file names starting with, if not all of those containing, a comma, but a quick test with a few basic bash tools shows no issue.

I wonder (having never really grokked the latter) if it's productive to think of this as akin to a leader key in vim ….

</comment><comment><USER12> > Red Hat never really worried me, because they packaged (comparatively) so > little software.

Erm, nope:

        $ dnf repoquery -l $(dnf repoquery -f /usr/bin/\*) | grep ^/usr/bin | wc -l
        34989

<comment><USER13> I think the OP meant in comparison to Debian. Official Red Hat repositories have been way smaller than the official Debian repositories for as long as I can remember, back to the 90s. I know Fedora has a lot more packages though.

<comment><USER12> That's hardly a fair comparison, unless you can call up Debian on the phone and get 4 hour support for any of those binaries. Back in reality Fedora is the closest analog to Debian.

<comment><USER13> Touché. I didn't actually point out the difference as a point in favor of Debian; I can see the advantages of both approaches.

</comment></comment></comment></comment><comment><USER14> The author has helpfully open-sourced the scripts as well, some of which are quite helpful like this one to convert dates to unix time and back: [https://github.com/brandon- rhodes/homedir/blob/master/bin/%2...](https://github.com/brandon- rhodes/homedir/blob/master/bin/%2Cdate)

Agree with the commit message; I've probably spent way too much time the past decade firing up a python prompt or using an online epoch converter to do this.

<comment><USER15>
      date -d @$1 +%Y-%m-%d

<comment><USER16> $ date -R Gets you very close with fewer characters

<comment><USER15> I mean, if you're not fixed on the output format, then date +%c.

</comment></comment></comment></comment><comment><USER17> Some time ago I wrote a simple tool to implement directory history in bash. Unfortunately I couldn't use 'cd<' and 'cd>' for obvious reasons, so I used 'cd^' and 'cd,' instead.

<comment> dan-robertson But bash already has pushd and popd

<comment><USER17> Umm, I wasn't aware.

</comment></comment></comment><comment><USER18> > And, best of all, thanks to the magic of tab-completion, it became very easy > to browse my entire collection of commands.

This. I always forget the names of all these useful tools that I only use now and then.

<comment><USER19> What's wrong with ls ~/bin?

<comment><USER20> Two keystrokes vs 9 (using shift with some keyboard layouts). Also, interaction with zsh or fish is better.

</comment></comment></comment><comment><USER21> Brrrr, such an ugly solution. If you want proof against future then you should use longer naming, maybe something that ends in <First name initial, Last name initial, Middle name initial, Underscore, my>. Allows to get better implementations of existing ones and having a fixed schema can help you in the future as your personal tools library grows.

Examples:

cat -> cat_uni_my (personal implementation of standard cat)

grep -> grep_uni_my (personal implementation of standard grep)

<comment><USER22> That's not really easier to type though :)

<comment><USER21> maybe, but it's a lot easier to understand if you share your tools with other people. As for personal use, sure, you can do whatever you want, including using his comma style naming.

</comment></comment></comment><comment><USER23> That's weird, because I use comma every time I type something in my shell (on Windows, not cmd.exe, but FAR). Why? In order to make sure that builtin ",time" is called, not "time.exe", because FAR Manager would try to run the executable under the PATH, instead of the command.

<comment><USER24> FYI in bash there's somehow similar `command` built-in.

Say you have an alias that overrides `ls`. When you want to run original ls, you run `command ls`.

<comment><USER25> Or, you know, fully-specified path:

        /bin/ls

<comment><USER24> When you override a bash built-in like `cd` with an alias, `command` is the only option.

<comment><USER25> Fair point.

Is there an alternate mechanism for invoking a shell's built-ins externally? Obviously for state-changing operations such as 'cd' that's of limited use.

       $SHELL -c '<commands>'

Comes to mind. Though likely bypassing initialisations might be useful.

</comment></comment></comment></comment></comment><comment><USER26> BTW I've long wanted to do sth like this:

Assume I have commands my_cat, my_grep, my_sort, my_send, and I want to use them in a pipe

with_prefix my_ | cat file | grep phrase | sort | send | end_with | cat

The last cat would be the system one.

I don't think it's possible with bash?

<comment><USER27> > I don't think it's possible with bash?

No, pipes don't work like that. The closest I can think of is something like `(PATH=~/bin; cat file | grep phrase | sort | send) | cat`, where the custom commands don't have a prefix.

</comment></comment><comment><USER28> TL;DR Prefixing your custom commands/scripts with a comma, in order to avoid collision with present or future system commands.

Been doing it for years with a jj prefix instead, it is just under my index finger on the home row :-)

<comment><USER29> Typing jj+tab gives me:

        jjdoc   jjs     jjtree

on Ubuntu 18.04

</comment></comment><comment><USER30> I just name all my shell scripts in all-caps. Nary a collision...

<comment><USER31> I hope you don't use APFS…

<comment><USER32> APFS can handle FOO and foo just fine, and I think only on macOS do you have to ask nicely that you'd like to have them not conflict, iOS and watchOS already do that by default. I have observed no problems with running a fully case sensitive macOS install.

<comment><USER31> Interesting! I seem to recall that not all to long ago a lot of things would completely break if you tried to use a case-sensitive filesystem.

<comment><USER32> I think Adobe or other entrenched bloatware might still break, but I had zero problems with it so far and I use a reasonable range of applications.

</comment></comment></comment></comment></comment><comment><USER33> On my International English Magic Keyboard I'd use § for convenience though. Neat idea, works with aliases too.

<comment><USER34> I'd never heard of that keyboard before. Is this something that's handy for programming because it had extra keys?

<comment><USER33> No, I just chose it over US English for the L-shaped Enter key and over UK English because # was easier to access. You can see the layout differences here:

[https://www.apple.com/uk/shop/product/MLA22B/A/magic- keyboar...](https://www.apple.com/uk/shop/product/MLA22B/A/magic-keyboard- british-english)

</comment></comment></comment><comment><USER35> Although this seems like a good idea, I wouldn't like typing an extra symbol. Maybe I'm just irrational.

Instead of prefixing my commands, I just search for a command in a manpage repo, cht.sh [0], and with my package manager (`dnf provides` for the DNF package manager). If nothing shows up, I'm probably safe. The process is easy to automate.

<comment><USER36> Typing a comma is too hard, but that 4-step jerry-rig isn't?

<comment><USER37> He does that check once, when he's deciding on what to name it, not every time he runs the command.

<comment><USER35> This, plus I also said "Maybe I'm just irrational".

</comment></comment></comment></comment><comment><USER38> the dash character would also work.

      ▷ echo 'echo "this is a -test"' > ~/bin/-test
      ▷ chmod +x ~/bin/-test
      ▷ -test
      this is a -test

</comment><comment><USER39> Why not just use shell aliases?

<comment><USER7> They are not real system commands; they can't be exec-ed.

</comment></comment><comment><USER40> How is this ugliness a solution? How about just name the binaries properly - I'd rather just prefix my commands with ~/bin.me/<blah> and keep ~/bin out of my PATH, than futz with horrid looking names. Or, even better, just put my username in front of it .. "fit2rule_grep" ..

</comment><comment><USER41> "Like many Unix users, I long ago created a ~/bin/ directory in my home directory"

No, this is my laptop - /usr/bin is the place for that. No, this is a simple server - /usr/bin is the place for that.

Perhaps I'm missing something after 23 odd years of using Unix systems including this Arch laptop.

<comment><USER42> /usr/bin is under the control of your package manager _ unless you're building and installing packages for all your adhoc scripts, aren't you worried about name collisions?

<comment><USER43> I know Arch's package manager, at least, will refuse to install a package if it would overwrite an existing file.</comment></comment></comment>


Should Your Driverless Car Kill You to Save Two Other People? - <AUTHOR> http://gizmodo.com/should-your-driverless-car-kill-you-to-save-two-other-p-1575246184 <comment><USER2> If the scenario in the article happened then 1st, the vehicles shouldn't have been going so fast that a head on collision could be possible over X mph and 2nd, the autonomous vehicles could choose the option of engaging all breaks and relying on the oncoming vehicles to do the same, while preparing to deploy airbags. There is no reason that "drive off a cliff" would ever be an option because the vehicle wouldn't put itself in that much danger.

It should never be possible for an autonomous vehicle to hit someone unless they jump from the side or top and even then the vehicle should be able to stop instantly because it calculated that there was the potential for something to happen in that area.

If the vehicle is approaching an area where it can't see things that could possibly come in front of it's path then it should be going slow enough to be able to stop if something does appear.

If the vehicle is passing people then it should be going slow enough to be able to stop if anything steps out in front of it's path.

Yes, inner lanes and highways that have barriers on the sides would allow for much faster traffic.

</comment><comment><USER3> As a consumer, I'd be very unlikely to buy a car that would kill me to save strangers. Not that I don't care about strangers, but _to me_ my life is simply more valuable. So given a choice, I'd pick the model that did everything to protect me, my friends and family. I assume most people would do the same..

Ideally autonomous vehicles will communicate so as to minimize such conundrums.

</comment><comment><USER4> This is an interesting philosophical question.

Likewise the question "would your driverless car kill Hitler if it saw him crossing the road as a toddler?"

Philosophical question. Probably not practical for what your car will know.

</comment><comment><USER5> Unless the cars reach a Nash equilibrium or something they may just all go off the cliff to save the others. That wouldnmt be too good.

Also see [http://en.m.wikipedia.org/wiki/Aumann's_agreement_theorem](http://en.m.wikipedia.org/wiki/Aumann's_agreement_theorem)</comment>


We will stalk you till you quit your bad habit Dead Serious - <AUTHOR> http://texmote.tumblr.com/post/21198413566/all-we-need-is-a-little-push-www-texmote-com

<comment><USER2> There is a great Stephen king movie called Cats eye. it is a series of three short stories one of them was about a company that helped you quit smoking, if you did not follow their program they kidnapped a love one and electrocuted her (punishment gets worse the more they deviate)

<comment><AUTHOR> @madao: Lol! Thats sounds a lil too drastic! We are less evil & play secret santa mostly! :)

<comment><USER3> Everybody says that.

<comment><AUTHOR> @ajuc: I can assure you we will NOT kill anybody or their loved ones to rid them of their bad habits! Spam, Abuse, all issues, agreed. Fixing, Fixing, Iterating, Fixing. We will be better soon. Promise.</comment></comment></comment></comment>


How an Amateur Meteorite Hunter Tracked Down a Fireball - <AUTHOR> http://www.nytimes.com/2016/03/11/science/how-an-amateur-meteorite-hunter-tracked-down-a-fireball.html <comment><USER2> 1) I'm surprised that meteorites would end up on the surface rather than embedded in the ground. I'd have thought that a hunk of metal or stone falling from the sky would penetrate rather than bounce. Is it a matter of the angle that it comes in at? Is the terminal velocity just that slow? Or do most of them bury themselves and it is only the ones that remain on the surface that are found?

2) There was an interesting story that came out a couple months ago about a new "trove" of meteorites being found in Antarctica. While quite a few have been found on the surface, there was a recent realization that more should have melted their way in after being heated by the sun: [http://www.universetoday.com/127492/does-antarctica-have- a-h...](http://www.universetoday.com/127492/does-antarctica-have-a-hidden- layer-of-meteorites-below-its-surface/)

<comment><USER3> It's actually pretty interesting that the impact speed is not that crucial when it comes to how deep the projectile is embedded. Isaac Newton was the first to explain it and to approximate how deep a projectile can go -- it boils down to the density ratio of the impactor and the target material. Additionally, penetrating the atmosphere itself can be thought of as equivalent to penetrating 10 meters of water, so the projectile already loses a lot of energy to push through it.

See [https://en.wikipedia.org/wiki/Impact_depth](https://en.wikipedia.org/wiki/Impact_depth) for more explanation.</comment></comment>


You're not writing code, you're solving problems - <AUTHOR> https://lanraccoon.com/2020/youre-not-writing-code-youre-solving-problems <comment><USER2> I think this article constructs a strawman argument – pretty much all developers are solving some sort of problem.

The big question is _who_ you're solving problems for – when I was a single person doing freelance web work (like this article seems to assume), I was always solving problems for customers and their clients.

Once I started working with other developers, I became interested in solving their problems too – sometimes in the form of a big refactor to improve the code, but also making tools to improve the codebase at scale.

<comment><USER3> Aren't a lot of jobs about solving problems?

A therapist solves psychological problems.

A lawyer solves problems between people and organizational entities.

A surgeon solves medical problems.

The reason I'm asking this question is because a few groups proudly say that they are problem solvers. The most notable groups that I've seen are programmers and the consulting industry.

But who isn't solving problems? Why this focus on it?

Sorry for derailing the thread a bit, but my friend group doesn't have the answer.

<comment><USER4> I think it's a reaction to programmers' particular tendency to focus on things that aren't best serving the goal of solving the problem at hand. Programmers often have a "pet" focus that relates to what they enjoy: performance optimizations, writing "clean" code, using some particular pattern or technology they like or want to try out, etc. None of those things are bad as long as they don't take precedent over solving the problem at hand.

<comment><USER5> > Programmers often have a "pet" focus that relates to what they enjoy: > performance optimizations, writing "clean" code

This seems like preventing new problems from happening. Which is indeed a wrong thing to do if the metric for evaluating employees is "number of problems solved".

If you create a fizzbuzz application with good performance and clean code, you have solved one problem. If you create a fizzbuzz application first, then fix three bugs in it, and then improve the horrible performance, you have solved five problems.

<comment><USER4> > If you create a fizzbuzz application with good performance and clean code, > you have solved one problem

You haven't necessarily solved a problem if the definition of "clean" is subjective and not actually associated with any real benefit to the client/user. In that case you've just scratched an itch or wasted time. Same goes for optimizing something that happens rarely or wasn't prohibitively slow to begin with. Crucially, it's not about what _you_ perceive to be a problem but what the _user_ perceives to be a problem.

Again, I'm not saying you shouldn't strive to write clean code that performs well but it's important to know what that actually means within the context of that particular project.

Some examples of a "pet" focus:

* The designer gets absolutely up in arms because something doesn't match the wireframes, but doing it as shown in the wireframes is much harder. You show it to the client and it makes absolutely no difference to them.

* A coworker spends time to refactor code to make it more Pythonic, aka rewrite look-before-you-leap code to ask forgiveness instead of permission. The code is now arguably worse.

* A user adds memoization to part of the code that doesn't have any particular performance issue. That code is now harder to understand.

The key is to focus on _real_ problems, not ones you want to work on.

</comment></comment></comment></comment></comment><comment><USER6> "You're not cooking meals, you're solving problems"

<comment><USER7> You're missing the point.

The goal of cooking meals is to have a meal at the end. Because people need to eat. The food is the solution to the problem you have.

People don't consume software, slurping up lines of code like ramen. Having a steaming bowl of software is not the end goal. The end goal is to solve some _other_ problem which may or may not, once you dig into it, require writing software, and if it does then still: more software doesn't mean more food.

<comment><USER8> You are missing the point. As is almost everyone else who says this stuff.

Most of us get paid to write software other people have requested in order to solve their problems. Every problem software solves can be solved by a sea of pencil pushers or factory line workers or human calculators or office clerks with filing cabinets or telephone switchboard operators or typists. The world used to run that way.

It no longer does because it is extremely cheap to program a computer to do repetitive actions. Compared to previous real-estate and labor-pool costs, paying even a thousand programmers to automate work done by people is incredibly inexpensive.

The problem is already solved. Your job is to translate the solution into a well-specified, easy to manipulate series of steps for a computer to execute that can be operated in production as cheaply as possible. You are literally the last step in the race to the bottom. You are literally payed to solve the problems of translating flexible human activities into code. That's the problem you are solving.

If someone asks you to program something that they don't already know how to do, then you are solving three problems - what to do, how to do it, and whether or not it is cheaper to do in software, which it ALMOST ALWAYS IS. You should be being paid three salaries - one as a business executive, one as a business analyst, and one as a software engineer.

The people pushing you to "solve problems, not code," are people pushing you to do more work in one job role to keep them from paying three people for those jobs. As a software engineer, you should be able to assume by the time something hits your task queue that others have decided that it will be cheaper to use software to solve the problem, they were competent in that assessment, and you can start executing.

As a consultant, I frequently take on all those roles for a client. But they pay me as a consultant to do those three roles. Remember that as an employee, in an extremely in-demand field, with specialized expertise compared to the rest of the work pool, you are a sole proprietorship trading time for resources. If that trade is lopsided, you need to push back and negotiate higher pay and a promotion. Don't give away work responsibilities for free because of culture hero points.

<comment><USER9> > _Every problem software solves can be solved by a sea of pencil pushers or > factory line workers or human calculators or office clerks with filing > cabinets or telephone switchboard operators or typists. The world used to > run that way._

I know what you mean, but this is the wrongest thing I've seen in quite a while!

Because it ignores performance.

Try implementing a video game with human clerks.

<comment><USER10> It's a good counterpoint; high-speed games like platformers and FPS are only really possible with a computer. Lots of other game types have analog analogs, though.

Pinball is certainly a precursor to video games; there's other low-impact games of manual dexterity like ring toss/bocce/..., darts/target shooting. Choose your own adventure books/pencil and paper role-playing/wargames obviously predate computer gaming -- the computer just runs a timer maybe and acts as the gamemaster.

People have been playing various forms of puzzle solitaire with cards for years; Bejewelled or whatever could be done with a custom deck. Minesweeper is not different in kind from the old logic game Mastermind. Even something like Tetris seems new, but I think is similar fundamentally to a tabletop game like Boggle: randomized input + a timer to find solutions -- the geometrical nature of Tetris is kinda just an implementation detail.

But I would venture that the number of problems that are only _quantitatively_ different -- i.e., faster -- because of computers utterly dwarfs the number that are qualitatively different, or even impossible without them.

</comment></comment></comment></comment></comment><comment><USER11> I liked this article, but one point it misses is that you should be solving problems in a way that makes it easy to keep solving problems in the future, and that's a tradeoff that even more people get wrong.

For instance, writing good, maintainable code only matters because if you don't, you might reduce your ability to solve more problems in the future when the problems you need to solve might change, due to learning new information about your users/customers, your users/customers changing, etc. For example: \- the code itself might be difficult to understand, reason about, and change, making it hard to make changes. \- the code might require time spent on maintenance, which reduces the time you can spend making forward progress.

<comment><USER12> This seems like an interesting generalization/characterization of technical debt.

</comment></comment><comment><USER13> Depends on the language. I find that in C++, I spend a lot of time working on figuring out the language, while in python I spend far more time solving the actual problem.

<comment><USER14> Hoh! I spend most of my time figuring out pipenv (not my design choice!) .

<comment><USER15> Python packaging is now a solved problem.

Use Poetry. Resolves all your dependencies and manages your virtual environments.

Also lets you build and publish your own projects with a few commands.

[https://python-poetry.org/](https://python-poetry.org/)

<comment><USER16> I'm excited to give this a shot, but I've heard this promise many times before.

</comment></comment></comment></comment><comment><USER17> Good software is a sequence of good ideas. Deep knowledge of computer science, the tools and frameworks, and the offline side of problem domain including the market mechanics expands the surface area of possible ideas.

</comment><comment><USER18> Pareto Principle... If some young person is at a loss for a science fair project, I humble suggest to attempt to replicate this experiment: Grow some peas. Count the number of peas in a pod. Verify that 20% of the pods contain 80% of the peas.

In case you prefer the thought experiment version, consider that you have 100 peas. 80% of 100 is 80 (I like easy math). That means that 20% of the pods contain 80 peas. It means that 80% of the pods contain the other 20 peas. If we have 10 pods total, it means that 2 of the pods have 40 peas each and the other 8 have 2.5 peas each on average. I ain't never seen no pea pods with 40 peas in them, so it must be more pods. I think the most peas I can imagine in a pod are 10, so let's say that 8 pods have 10 peas each and 32 pods share the remaining 20 peas. Since you can't have less than 1 pea, that means that you have at least 12 pods empty even if the other 20 pods only have 1 pea each. If you have a more reasonable distribution, you will find that more than 40% of the pods will be completely empty.

I've grown peas a lot. I've never, ever seen a distribution of peas like that in pods. What strange peas was Pareto growing? Is it just that we have better strains of peas now, or was Pareto just making stuff up? (small voice: just like practically every application of the Pareto principle I've ever seen...) ;-)

</comment><comment><USER19> This reads to me like the faux-deep inspirational, vaguely-self-help-ish platitudes that litter facebook.

Are there software engineers out there that don't know this?

You're there to solve a problem and/or create a product. Code is a liability.

<comment><USER20> There are a ton of engineers that don't know this. They like building things, and talking to users is hard. So they just build stuff and throw it over the wall.

And I get that. I have hobby projects because it's nice just to go wild and code for my own entertainment. My home lighting system is a custom Scala actor-model daemon, because 5 years ago I thought Scala was cool. (In retrospect: nope!) Building things is fun.

But when I'm on the clock, I've learned to be relentless in understanding actual users and their needs, and ruthless in pruning back the many things I'd _like_ to build down to what actually serves people.

That's not easy even in the best of cases. And in companies that have waterfall-ish leanings or command-and-control managers, it's often impossible. So a lot of programmers learn to build whatever they're told, regardless of whether it solves a problem. And a good chunk will do it in ways that entertain them, because when managers drain all meaning out of a job, we are forced to find ways to create some for ourselves.

<comment><USER21> Tesla are using Scala actors for their power distribution network.

[https://www.infoq.com/presentations/tesla- vpp/?utm_source=pr...](https://www.infoq.com/presentations/tesla- vpp/?utm_source=presentations&utm_medium=london&utm_campaign=qcon)

I guess cool is subjective.

</comment></comment></comment><comment><USER22> "You're not writing code, you're solving problems" is true, but in an appropriately bad company its also true and maybe much more important:

You are not solving problems, you are writing code.

That's when management or upper levels in hierarchy are not experts and have no idea what's the software and the particular problem is about and micromanage.

My point is that the warning the title refers to is real, but there is another (bigger) problem when people know they are not solving the problem the right way but they are forced to ship asap and "just code".

</comment><comment><USER23> This is golden advice and for me understanding this is one of the differentiators between junior and senior developers.

All too often developers seem to be bent on the idea that they have been hired to write code and so the solution to any problem they are asked to solve must be more code.

The truth (or at least the way I understand it) is that writing code should be something that happens when you have explored every other option possible.

Even if it is easy to write, code is expensive to maintain later on and the costs do not add linearly.

The larger the project the more it costs to maintain anything. Simple operations become huge projects.

The best bet, in my mind, is to try to have as little code as possible by treating the code as a liability and trying to curb the amount of it from the start.

Even if you need to add code to add a functionality, it is frequently possible to shift it from somewhere else. Refactoring as you add functionality is a good way to curb the size of the code base.

Another way I have noticed that seems to be frequently overlooked is to have the object model as close to your real problem. Any inconsistencies between real life and software object model seems to result in heaps of code in multiple components to deal with various exceptions, translations, mappings, etc. and this seems to grow exponentially with time. Sometimes there is no better way than just do it right from the start.

I work for a large bank on a system that deals with risk calculation. It seems every part of organization has a slightly different understanding of what a trade is or definitions of its properties. The net result is that, in my estimation, there is about 3 orders of magnitude more code that would be necessary if there was single shared definition of all those properties.

</comment><comment><USER24> I think this is important advice that needs to be repeated over and over and over again. The number of software developers who get caught up in the latest fashion choices, instead of carefully picking the right set of tools for the job, is absurd. Sometimes it's really important to use the latest thing because it solves a key part of your task; often it's better to use a "boring" technology that is well-understood and does the job without a lot of fuss.

I remember years ago, when I was in high school, reading advice that "customers don't want drills, they want holes". Software developers should constantly focus on what the customer actually _wants_ (that is, the problem the customer is trying to solve).

It sounds trite, but it's easy to get distracted when you're knee-deep in trying to solve the problem.

</comment><comment><USER25> "Creative people don't have a goal of wanting to be creative," Flaherty says. "Their goal is to solve a problem."

</comment><comment><USER26> Junior devs solve computer problems using computers. Senior devs solve business problems using computers.

<comment><USER27> And "ninjas" or whatever the term is for senior+ programmers know when to solve problems without a computer at all!

That's when you've reached enlightenment :)

And I don't mean that in a woowoo wishy washy way. I mean that when someone comes to you with a business problem, often the solution can be something as simple as "why not just change the text to say X" or "did you know that dept Y already do that thing? Let's ask if they will take on this task also"

A junior will have already coded 100 lines of "something". And some seniors I know of will be knee deep in microservices whiteboard sessions by now. The truly great programmers I've worked with prefer simplicity first and foremost.

<comment><USER26> I think you're describing the currently-terribly-unfashionable-but-still-vital role of architect.

</comment></comment></comment><comment><USER28> This is all very well and good until the code you've written to solve the problems becomes a bit too unwieldy, then you need to become better at writing code.

The problem you were solving was solved, but now you have a new problem to solve.

True then, the best code you can write, is indeed, no code at all.

<comment><USER29> It sounds like you are stating that solutions vary in effectiveness, especially across time.

This insight seems to making the framing even more useful, not less.

</comment></comment><comment><USER30> I've given a couple presentations along these lines and found it's important to make another point: _Code is just one tool in our toolbox._

We can make our interfaces more intuitive. We can make our documentation clearer and closer to the user's terminology. Our examples can be more explicit and tuned to people's common use cases. Our FAQ can address actual frequently asked questions instead of what we guess people will ask. We can treat FAQs as bug lists/things to improve so people stop asking.

If code is the only tool we use, we'll always write more code which comes with costs now and down the road.

</comment><comment><USER31> Code is a means, not an ends. Furthermore a sexy cool "solution" is no solution at all if it doesn't solve The Right Problem. Too many obsess over solving a problem, or a client want.

Unfortunately, that's not the same as solving for the actual biz need. This is a key reason why IT has a reputation for failed projects. What's delivered - even tho it was what the client wanted - turns out to not meet the (never defined) need. Wants are not the same as needs; sometimes the difference is significant.

Editorial: I had a semi heated exchange with a proj manager a couple weeks ago. He said, "The client like this (i.e., example from another site). This is what you need to build." I asked why the client liked it; what was the underlying biz need that the proposed solution satisfied? I never got an answer.

</comment><comment><USER32> Despite having used the "we're solving problems" argument myself on occasion, I think what we're really doing is identifying problems and assisting with possible solutions using particular knowledge of our domain.

Somebody wants something done within particular constraints, so our job is to identify potential issues that may occur, such as scalability problems, costing issues, UX concerns, etc. And help explain to that client such concerns and possible solutions or compromises, and let the client decide on the solution.

Once actually implementing some plan, we have some creative freedom on the implementation details, but I'd hardly call that solving a problem (apart from it being your own problem on how to get the design coded up).

</comment><comment><USER33> Yet another article on HN that reads as if the entirety of programming = making CRUD web apps. I make games, it has nothing to do with the real world, I'm not solving any real world problems. I'm making a new fantasy world.

<comment><USER34> Still, in my point of view, your viewpoint and the article's one can be aligned. Strictly speaking, converting your ideas about the fantasy world into code to run the game is "solving a problem". I'd argue that any creative process can be coined as a problem-solving exercise, except for the fact that in many such cases the problem isn't tangible and the outcome isn't measurable.

<comment><USER35> > I'd argue that any creative process can be coined as a problem-solving > exercise

Problem solving _with_ real-world constraints = engineering

Problem solving _without_ any constraints = art

<comment><USER36> This is reminiscent of the old divide between mathematics and philosophy:

true and useful = math

true and useless = philosophy

<comment><USER37> Which side does the practice of distinguishing between the useful and the useless fall on?

<comment><USER38> philosophy decides :)

</comment></comment></comment></comment></comment></comment><comment><USER39> As a literal example, I've occasionally been asked to put some process that was previously done physically "on the computer". That is, perhaps a paper log of some important activity that they'd now like to have a program for, or a physical token system for tracking a critical resource.

Often computerizing is useful, but sometimes it turns out that any conceivable software version would actually be significantly worse than what they're already doing.

In a case like that, you truly _can_ solve their problem by _not_ writing _any_ code.

(Obviously, this only works if they ultimately agree.)

</comment><comment><USER40> a question I like to ask to my reports is "are you solving a problem or are you solving a puzzle?"

puzzles are neat! They're a lot of fun! But we shouldn't mistake puzzles for problems. Just because something isn't right or doesn't fit together doesn't mean that it matters. You can do great engineering work coming up with beautiful solutions, making order and beauty out of something that doesn't work quite right but provide no value whatsoever if the thing you were working on solving wasn't actually a problem for anybody.

<comment><USER3> Aren't puzzles a subclass of problems? Isn't a problem simply a question that has a solution?

It made me think about the definition of the word problem. Here is one list: [https://www.merriam-webster.com/dictionary/problem](https://www.merriam- webster.com/dictionary/problem)

<comment><USER41> I don't think either word, "puzzle" or "problem", requires it to have a solution. I would say the distinction is that the purpose of a puzzle is in the act of solving, while the purpose of a (business) problem is to have the solution.

</comment></comment></comment><comment><USER42> NOTE: This is tongue-in-cheek (for the most part). However, I cannot help but feel that articles like this are a subtle form of social manipulation; especially for younger, less experienced programmers.

From the article:

* The software is not the purpose

Translation: your craft, how you do it, and why are not important. Going _meta_ for your profession is not valued and if people see you doing it, you're in trouble. Let the guilt wash over you, heathen!

* Understand the problem

Translation: going _meta_ (refactoring, egads!) is _wrong_. We're watching you and if you do this, you're in trouble. If you aren't feeling guilty yet, now is the appropriate time. In addition, you must feel shame for your irresponsibility!

* Perfect is the enemy of good enough

Translation: going _meta_ \-- unless it is to realize a clever kludge -- means you are a perfectionist. You're wrong! We're watching you and if you do this, you're in trouble. You're one of those _prima donna_ programmers, aren't you? We have no need for you!

* Choose your battles

Translation: Everyone starts off doing everything by hand, so -- you know -- the whole notion of writing software in the first place is kind of a Faustian Bargain. Hey, why did we hire you anyway? It's clear you're one of those whinging, prima donna, basement dwelling, perfectionist, programmer A-type people. I see we need more money in the "team building" budget. You're fired. Now is the appropriate time to feel like a loser, because you are!

* The best cod (sic) you can write, is no code at all

Translation: We can't even be bothered to spell "code" properly, which shows you how important it is to us. Truthfully, if there were a magic product we could buy that does what you do -- but better! -- we would. Don't you dare start thinking about weighing cost/benefit of buy-versus-build. We know you programmer types. You just want to build stuff and it's never the right stuff and you can't estimate for crap and your profession doesn't matter. Screw it, let's just put out an RFP and see if someone has a silver bullet so we can use it against you programmers! Lead bullets aren't working.

Postscript:

OK, now that I got all the snark out of my system, I feel better. It isn't that parts of this article are _wrong_ but rather it makes extremely broad assumptions that all programmers are doing the same thing, in the same context, for the same reasons.

The current gestalt around software development appears to be that only a select few are allowed to decide the "state of the art" in the profession. These anointed few enjoy autonomy and full creativity but the rest of us must check our brains at the door.

Maybe it's just me, but I find this attitude extremely risky and deleterious to the industry and the human race. Of course, I am a grey beard, basement- dwelling, prima donna, perfectionist, anti-social, programmer so nobody will be surprised.

<comment><USER43> > I cannot help but feel that articles like this are a subtle form of social > manipulation; especially for younger, less experienced programmers.

Indeed, I'd go as far as saying this is straight up managerial tautological BS like I've heard many times.

"If the software doesn't do what you need it to do, it's useless.", said Captain Obvious. Well, of course it must solve the problem, but that's not enough, far from it.

And then the article promotes things like wordpress and webflow... well, I for sure know what code base I won't have to deal with when a bad plugin will break the "best code is no code" mantra.

</comment></comment><comment><USER44> Funny thing is, coding today is mostly understanding how other devs solved a problem.

We're using frameworks and libraries that all come with very specific solutions.

<comment><USER45> Well it's more like using the tools other developed to help you solve your problems faster. If you're spending more time understanding the tools you're using, reconsider your tools.

<comment><USER44> Some tools are overengineer, true.

But more ofteb than not, people underestimate the problem AND the tools that were created to solve them.

Also, most devs aren't simply as smart as they think they are.

I worked with many devs that tried to force their mental model on an framework that worked completely different.

</comment></comment></comment><comment><USER46> Very well written article. But i dont agree you should always rely on someone elses solutions. I think we went too far with it. Too many dependencies is as bad as duplicating code. Also i would add that sometimes solving problems with software can create new problems. Problems that can be solved only by more software. And this is also a risk

</comment><comment><USER47> >>We're programmers, so writing code is what we do, is it not ? As the title suggests, our job is a bit more complicated than stroking keys on a keyboard in front of a screen all day.

I don't know what it is about the tech industry but it really seems to think highly of itself and is constantly self congratulatory.

</comment><comment><USER48> "Writing code is considered harmful"

<comment><USER22> lol

</comment></comment><comment><USER49> Title should be "If you don't work on software product, you're not writing code, you're solving business problems with code".

</comment><comment><USER50> If you write code to solve problems then you are a coder, just like if you drive trucks to solve a transportation problem. What's the point of getting into semantics?

What programmer on the face of this earth doesn't realize that they're hired to code up a solution to some problem? Is this article implying that there are programmers out there who believe they are employed to write beautiful code to be looked at and admired and never to solve a single problem?

<comment><USER51> From reading HN, it seems like there is a cultural outlook where everything other than the problem to be solved is first and foremost when choosing a place to work. Like, do they use the right tools, the right OS, the right management methodology, have the right perks.

And when I look at job ads, it seems clear that there is a fair amount of competition among employers to appeal to these sorts of employees, by following trends or appearing to.

I think it's obvious why - people who care about things other than problems for their own sake, if talented and self-motivated, are more versatile and therefore valuable, because they will do a more or less equally good job on _any_ problem.

This cultural dynamic is, I think, an obvious emergent dynamic that has made "don't be evil" a futile aspiration, not just for Google, but for the software industry in general.

<comment><USER52> Yeah, I never understood the HR reps approaching me and listing all of the technologies company uses. After reading that I still have no idea what company is doing and why they would need someone like me.

<comment><USER51> My last phone screen, I had a job and was pretty sure I didn't want to go anywhere, so I was free to express myself and talked about how much I liked the sort of problems I was dealing with at work. The feedback to the recruiter was "he didn't sound technical enough"...despite them not asking any technical questions.

Everybody wants to save the world of course, but it seems like the modal outlook is that _everything else_ comes first, including all the dealbreakers, and the substance of what you are doing is mostly pro forma.

</comment></comment></comment></comment><comment><USER53> I'm definitely not solving problems. I'm just writing code. And copying and pasting. And merging.</comment>


Everyone quotes command line arguments the wrong way - <AUTHOR> https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23/everyone-quotes-command-line-arguments-the-wrong-way/ <comment><USER2> Not everyone. Just windows developers.</comment>


What I Learned from Losing $200M - <AUTHOR> http://nautil.us/issue/31/stress/what-i-learned-from-losing-200-million <comment><USER2> The only thing worse than a non dismissible paywall overlay is a non dismissible paywall overlay that takes 90 seconds to paint.</comment>


Automatically Mark as watched your TV, Anime + Movies - <AUTHOR> https://www.kickstarter.com/projects/masyk/tv-tracker-auto-mark-as-watched-your-tv-anime-movi <comment><USER2> This is awful... "Automatically Mark as watched your TV" makes no sense to me, but I get what it's trying to do - automatically mark TV content as watched. But as far as I can tell, this doesn't work with a TV?

They totally lost me at "KNOW YOUR STATS - WASTED WATCHING TV SHOW". Excuse me, but when I'm watching a TV show, I'm not WASTING time. I enjoy my time when watching TV shows. There's a huge difference between watching TV and wasting time...

<comment><USER3> Thank you for your feedback, we did not meean it that way (thought it was funny ;). Changed it to SPENT

<comment><USER4> Still on the website though.. ;)

</comment></comment></comment><comment><USER5> I'm using Cliffhanger for Android, basically the same idea.

These guys should get together with the Popcorn Time guys, all in one package...just saying ;)

</comment><comment><USER6> Can someone please explain why there is a distinction between Anime and TV Shows? Its my understanding that Anime are either in a Movie Format (Standalone) or in a TV Format (Series).

<comment><USER3> Anime and TV shows are like series, but Anime is the style (Japanese most of the time) and Anime has Anime Movies and Anime TV Shows, Anime OVA, etc

<comment><USER6> but isnt that just a categorisation like Crime, Drama, Comedy? Anf if not: how are other (non japanese) animated movies/series (justice league etc) treated?

<comment><USER3> Anime has it's own categories like Angst Ecchi Battle Royale edit Bullet Time Calling Your Attacks Collateral Damage Gunfights and a lot more. There are multiple websites that only feature Anime, and zero websites with full content about all three TV, Anime, Movies

</comment></comment></comment></comment><comment><USER7> In the UK the best channels for new content are the ones provided by the BBC. However, invariably, what is on is a repeat. As for the rest of the channels, then it is hard not to watch a repeat.

The BBC don't sell advertising in the UK, the rest do. So, if I watch a movie 3/4 the way through before remembering I have seen it before, then that is all good to them and their advertisers, I have 'consumed' adverts, which is what TV is there for.

This project goes against the main goal of television which is to show as many repeats (and adverts) as possible. I cannot see Rupert Murdoch investing...

<comment><USER8> It will probably be easy to add the statistics of repeats watched, making the most favorite episodes of a show apparent. Would be useful imho.

</comment></comment><comment><USER9> Very interesting idea - the technology behind this sounds pretty neat! After skimming through the website, I'm still not 100% clear on what all this can do though. It looks like a way to keep a central list of everything you watch from different sources. I use my Chromecast for Netflix a lot - does this support that? Or is it more for tracking watching downloaded movies / tv / anime?

<comment><USER3> We're planing to create a Chrome plugin that will retrieve your watched history from Netflix. So it does not matter if you watch on ipad or tv or chrome, the plugin will still receive your complete watch history.

</comment></comment><comment><USER10> How is this different from [https://trakt.tv/](https://trakt.tv/) ?

Also, considering people watch on all kinds of devices (w.g. iPhone in the commute, laptop in afternoon, TV in evening), it's not very clear on how it will actually manage to track what I watched across those devices.

<comment><USER3> trakt does not have Anime and was always more designed for the API, not so much usable website. We're trying to make the web site more user friendly. We also already have our own software for detecting TV shows and Anime (success detection rates are currently 90%, which trakt does not have), trying to make it work with the large Movie detection databases as well. And we will have an open API as well just as trakt.

<comment><USER10> Ok, sounds good! Anime I can imagine is tricky.

</comment></comment></comment><comment><USER11> I love this idea. I toyed with the idea in the past, but it is very difficult to execute so it just works - I think it will take years.

I will not be backing, but when it is on the market and supports Plex, XMBC and Netflix, I will happily become a customer.

<comment><USER12> They do have already posted a prototype software for PC for TV Shows and Anime. I tried to watch some of my tv show files and saw a popup that I'm watching that episode (detected correctly)</comment></comment>


HTML5 And The Incredible Editable Web - <AUTHOR> http://www.kendoui.com/blogs/teamblog/posts/13-08-06/html5-and-the-incredible-editable-web.aspx

<comment><USER2> The Editable Web is definitely the next big thing, but this is too narrow scoped, I think.

There's a company called Tomodo (where I work) that allows you to modify any website and publish it as an independent one. Rellay cool stuff. Check it out - [http://tomodo.com/](http://tomodo.com/)

<comment><USER3> That is an interesting idea, but what is the value of doing so?

</comment></comment><comment><USER4> Sadly none of it works on iPad. Cool though. Telerik make some cool stuff.

</comment><comment><USER5> ckeditor.com</comment>


Improve HN: Home link on error pages - <AUTHOR>

I sometimes get an "Expired link" error. Alright. But then I have to go back to the cached page I came from, klick at the top (or ctrl+f5) to get back to the start page. Not good. I'd suggest putting a link to / on error pages. <comment><USER2> Though I would like to see this actually implemented you may have better luck in the official suggestions thread <http://news.ycombinator.com/item?id=363></comment>


Dirty object handling with Backbone.js - <AUTHOR> https://paydirtapp.com/blog/backbone-in-practice-dirty-object-handling/

<comment><USER2> well done. And congrats for paydirt!</comment>


Internet Explorer 11 getting SPDY support - <AUTHOR> http://withinwindows.com/within-windows/2013/4/1/blues-clues-internet-explorer-11-getting-spdy-support <comment><USER2> Better late than never I guess. It has taken 11 versions, but Microsoft is finally starting to catch-up and adopt established web standard protocols and features. The fact they implemented silent auto-updating a while ago hopefully helps with the uptake.

<comment><USER3> No, it won't be available for windows xp or vista or 7. However every other browser will be. I will still be coding towards IE8 for the next like 2-3 years till everyone leaves windows xp, which is currently the most popular version of IE, which means really simple css which makes life ridiculously easy like nth-child and last-child won't be available to me.</comment></comment>


Whose bug is this anyway? - <AUTHOR> http://www.codeofhonor.com/blog/whose-bug-is-this-anyway

<comment><USER2> "Incidentally, this is one of the reasons that crunch time is a failed development methodology, as I've mentioned in past posts on this blog; developers get tired and start making stupid mistakes."

Totally. Strangely enough, Founders at Work ([http://www.amazon.com/Founders- Work-Stories-Startups-Problem...](http://www.amazon.com/Founders-Work-Stories- Startups-Problem-Solution/dp/1430210788)) is chock full of startup founders extolling the virtues of overwork. Is this some survivorship bias or does overwork in startups really lead to shipping sooner and achieving product/market fit faster?

It's never been my experience that sustained overwork of software developers leads to actual, measurable productivity increases due to the "two steps forward, one step back" phenomenon. Yeah, you can ship a feature "sooner" but it'll be buggy and disappointing to the end users (probably causing them to hesitate to pay - are you really achieving product/market fit with a buggy product?)

We encourage every developer to find a sustainable pace (it's different for everyone) with the guidance that it's almost always less than 50 hours a week. Why is it that software companies think that overworking software developers is a net positive?

<comment><USER3> I think it's important not to reason in absolutes. Taking an obviously multi- person, multi-year project like Starcraft and arbitrarily setting a 2-month deadline "because some code is there from Warcraft II" is not good use of crunch-time. If you and a friend have an idea and can pull out a prototype in a week, then overworking that week may be not a bad thing (as long as it's not followed by another such week).

<comment><USER2> That's a good point. I believe the research (and my experience) suggests overwork can provide benefit in the short run (2-3 weeks) but much after that and you get diminishing and then negative marginal returns - followed by a "time off" recovery period.

Strategically used, overwork can provide benefit but it sounds like Starcraft was a year-long overwork, which is a disaster. Many of the "Founders at Work" stories glorify overwork and make it sound like it was part of the norm of the culture, so it seems like it was much longer than a few weeks.

Which is why I'm confused - either long-running overwork caused these companies to succeed, or it was not bad enough to cause them to fail?

</comment></comment></comment><comment><USER4> Whenever a fellow programmer or myself starts even considering that the OS, .NET-Framework, JVM etc. might be responsible for a bug, I have to smile.

In that moment, 2 things are almost certainly true:

1\. The bug is in _your_ code. 2\. You are too tired/stressed/overfocused to see it.

So when I find myself in this state, I instantly stop working and go for a walk (or go home when its late enough).

Then, when rested, I tackle the problem again. I will find my bug, or, for the very rare case, find a way to _prove_ that it really is the environment my code runs in.

But most importantly, I will have a sharp tool for the job.

<comment><USER5> I used to reason exactly like this, but then in last few months occurrences of this rare cases of bugs in OS, environment or even hardware started to be little to often. Although I might be biased by spending inordinate amounts of time on these bugs (like one day each). Various X11 related bugs (well, when X server crashes, you can be pretty sure that it is not bug in _your_ code), Windows driver bugs, Windows hotfixes fixing one bug and exacerbating impact of another bug from "minor annoyance" to "does not work", RTC chip with errata longer than datasheet, weird firmware<->kernel interactions, generally failing hardware and so on.

</comment></comment><comment><USER6> _"The bug was easily fixed by upgrading the build server, but in the end we decided to leave assertions enabled even for live builds. The anticipated cost-savings in CPU utilization (or more correctly, the anticipated savings from being able to purchase fewer computers in the future) were lost due to the programming effort required to identify the bug, so we felt it better to avoid similar issues in future."_

I'd like to ask: for anyone here who's ever worked on a large C++ codebase, were assertions ever actually observed to be a noticeable detriment to performance? I'm sort of naively assuming that a good branch predictor would make their impact negligible, but I ain't exactly a system programmer.

<comment><USER7> My primary experience with C++ involves game development, so my perspective is a bit skewed. The cheaper chipsets in consoles tend to have weaker branch prediction, so any branching can be a big hit in aggregate. And _everything_ is in aggregate because all your code is running in a tight frame loop at 30 or 60hz.

That said, the typical large C++ codebase is probably losing a lot more performance to bad algorithms than it is to problems that generally are only measurable in micro-benchmarks. There's just something about C++ that makes a lot of people obsess over performance to a degree that doesn't even affect the mindset of most C hackers. And because your brain is so preoccupied with performance in the small, you often miss opportunities for performance in the large.

Unless, of course, you're a AAA game, in which case you're fine tuning at the individual instruction and cache line levels for your most inner loops. I'm sure there are other, similar use cases for C++, but desktop software probably isn't on that list outside of a key component or two.

<comment><USER8> > There's just something about C++ that makes a lot of > people obsess over > performance to a degree that doesn't > even affect the mindset of most C > hackers.

Interesting observation. My first guess is that it is a lot easier in C++ to hide a stupid bottleneck, for example an object in a function call (which will call a copy constructor). So in the experience of a C++ dev, there are low hanging fruits. On the other hand in pure C it is a lot harder to hide this type of complexity and therefore C optimizations tend to be a lot more subtle.

<comment><USER5> It is also often pretty evident that C++ induces people to obsess over performance bottlenecks that were relevant on 80's hardware and while doing so introduce another (often more severe) bottlenecks relevant for modern CPU's. See for example C++ developers affinity for inline functions and templates expanding to huge amounts of inlined code, another common belief is that there is profound performance difference between virtual and non-virtual methods.

<comment><USER9> Do you have evidence that there is _not_ a profound performance difference between virtual and non-virtual methods? Virtual methods require two memory lookups (the vtable address, then the function address) and hence often two cache misses, compared to non-virtual methods which can be static addresses. If you've got a (common in games) loop like:

      for ( ..some list of 5000 objects.. ) {
        object.update();
      }

Then those cache misses will add up. That is my experience anyway, though I'll don't have statistics to back it up

</comment></comment></comment></comment></comment><comment><USER10> I really like the part on detection of hardware failure to guide users on a computer maintenance page.

Computer enthusiast, which are many amongst gamer, are just very eager of this kind of information, discovering it by a game you like that tells you 'check or do that to have a better gaming experience' must be a wonderful and exciting experience.

<comment><USER11> Yeah, that was brilliant.

One idea that struck me: given the classical role of the operating system, doesn't this sound like something an OS should be able to provide?

I imagine an OS service that, if requested, sits in the background and does what that game code did, in order to detect those kinds of errors. Does any OS have this? It really seems semi-obvious, now ...

<comment><USER12> Indeed. Having personally experienced power supply issues a few times (either due to malfunction or the mentioned problem of super-hungry GPU) and the resulting random crashes, I would have been greatly helped by this kind of detection in the OS.

It seems that in the PC world there is very little functionality in place to detect, isolate, and nail down hardware issues. Or if it exist somewhere deep in the firmware, at least no standardized way to access it.

On the positive side, I was recently very surprised when Linux started to give errors about a certain CPU core after programs started hanging. Somehow one of my cores had failed without crashing the OS(!). After disabling that core in the BIOS with the next reboot the issues went away.

So there is some level of hardware problem detection and robustness in modern OSes, but maybe not enough.

</comment></comment></comment><comment><USER13> The author mentions it in passing, and I do wish Starcraft/Broodwar and Warcraft III were open-sourced. Blizzard has understandably chosen to stop updating both games for newer Mac architectures (there is no build for Intel Macs for either, and thus no support for OSX 10.7+). The community would be happy to port the games to new platforms, increasing the popularity of the lucrative franchises.

<comment><USER14> I believe you meant the first Starcraft. I'd also love for these games to be open-sourced, along with the first Diablo, though I'm pretty sure WC3 and SC are still making money for them.

Also, here's a blog post I wrote on how to get these games working on OSX 10.7+ using Windows builds and Wineskin (shameless plug) [http://marzzbar.wordpress.com/2012/11/06/how-to-play- classic...](http://marzzbar.wordpress.com/2012/11/06/how-to-play-classic- blizzard-games-on-mac-os-x-mountain-lion/)

<comment><USER13> Yep! I meant SC/Broodwar. Also, throw in Diablo II to that list.

And great blog post! Thanks for that. I tried using wineskin for Starcraft before but got a little lost. I'll give your walkthrough a try. Sometimes I feel like playing a classic campaign to take a break from laddering on SC2.

</comment></comment></comment><comment><USER15> See also: "select" isn't broken:

<http://pragmatictips.com/26>

[http://www.codinghorror.com/blog/2008/03/the-first-rule- of-p...](http://www.codinghorror.com/blog/2008/03/the-first-rule-of- programming-its-always-your-fault.html)

There's nothing wrong with re-discovering things that other people had written about decades before. But discovering the wisdom of the ancients is also helpful.

</comment><comment> shawn-butler I think not having the build system match developer systems is a not uncommon source of production issues. It always starts out matching but no one ever updates the build machine (mostly out of fear of breaking something I think).

A good strategy I have used is that the first job of a new hire is to "make a build machine" on his or her own machine. Just having new eyes go through the steps on a semi-regular basis catches alot of stuff.

</comment><comment><USER16> My stackoverflow profile is a sad list of questions like "what's wrong with this library?" which have an answer 2 days later, often by me, saying "it was in _this_ bit of the code."

On several occasions I've actually left the bugged lines out of my initial submission, because I thought they weren't important...

</comment><comment><USER17> This is such an awesome post. When I think about the history of bug fixing it seems like we haven't gone very far in the last couple of years. Measuring how long a bug takes to fix is still voodoo.

</comment><comment> mark-r 99 times out of 100, the bug is yours. Sometimes you really do run into oddball stuff though. The most memorable for me was a bug that only surfaced after you printed something - the printer driver modified the floating point rounding mode and didn't restore it, resulting in some subtle failures of floating point calculations that followed.

</comment><comment><USER18> Interesting that both Guild Wars and Redis have reached similar conclusions about hardware failure.

</comment><comment><USER19> Maybe I'm just slow, but what _was_ the bug in that code?

<comment><USER20> He explains it right in the text.

      if (someBool)
        return A;

      ...

      if (!someBool)
        return B;

Now - both cases are covered. The result will be A or B, never anything else. Statements after the second return are unreachable.

<comment><USER19> Ah .. He _expected_ it to reach the unreachable code? I thought that it _did_ reach `return R`, which would be totally strange and could indeed be explained by a compiler bug. (Or more likely, by side effects in the code between the two checks)

</comment></comment></comment><comment><USER21> I just _love_ his articles: reminds me of the good old days playing these great games.

Just a note, he writes:

       "Overheating: Computers don't much like to be hot and malfunction more frequently in those conditions..."

One of the reason there are way less spurious crashes of desktop / game apps than back in these days is that now most CPUs have built-in temp sensor that automatically reduce the speed in the case of any kind of CPU overheating.

So the piece of code they wrote performing computation and comparing to know good results that could find as much as 1% of broken systems (!!!) would probably not find anywhere near close that number nowadays: the CPU simply slows down if it overheats.

Not sure what happens when GPU overheat and if these too have now built-in protection and not sure if they were trying to detect faulty GPUs too.

Another common "symptom" was an aunt, uncle, friend of parents, calling and explaining that : "my computer works fine for a while then it doesn't work anymore"... And you'd go check their system, open it, and find a CPU full of dust (which TFA mentions).

Nowadays I don't get these calls anymore from those people : they're still using computers, but once their fans get clogged the system simply works at a slower speed and don't overheat anymore.

<comment><USER22> Interesting. I recall how we had to decrease the clock speed of the processors on a high-performance machine in order to reduce errors - these were detected by simple reproducibility tests. With code optimised to sustain a huge percentage of peak speed and a thousand or so processors, such problems can become manifest, even in the chilly environment in which the machine was housed.</comment></comment>


Robotics company unveils toys that mix science, cool - <AUTHOR> http://www.post-gazette.com/pg/09191/982938-115.stm

<comment><USER2> Video of yellow ape robot "running" on treadmill.

Pretty disappointing. The "running" is just rolling on wheels shaped like arms.

[http://www.pocket-lint.com/news/news.phtml/21900/megawhat- pr...](http://www.pocket-lint.com/news/news.phtml/21900/megawhat- prime-8-running-robot-toy.phtml)

</comment><comment><USER3> I'd take a Lego set over this any day of the week. Modern toys take a lot of the creativity and imagination out of it.

</comment><comment><USER4> So far based on the article, I don't see any of the 'science' being mixed with cool.

What makes this more revolutionary or interesting than the toy robots that came out years ago?

</comment><comment><USER5> On top of not really seeming to help kids learn anything, these toys certainly push some gender stereotypes. What if a girl wants a penguin that shoots rockets and kicks soccer balls, or a boy wants a gorilla that hugs?

Call me when the robots let the kids program them.

</comment><comment><USER6> i couldn't help but feel a little bit sad as the creator explained all the features... i saw it as a typical example of an adult thinking "ooh ooh, a child would love this!!" and being miserably wrong. i don't doubt there's a lot of cool technology that went into that toy, but it seems the translation of that tech into something a child would want to play with was an afterthought (or quite misguided)...</comment>


Why I love "describing in the browser" with OOCSS-Inspired Microclasses - <AUTHOR> http://blog.12spokes.com/web-design-development/describing-in-the-browser-with-oocss-inspired-microclasses/ <comment><USER2> Wow. You're doing it wrong. You might as well use inline styling at this rate and dump stylesheets altogether.

If, tomorrow, you decide that all tooltips need to change their style the amount of work you have to do is O(N) in the number of tooltip elements you have, whereas if you did this correctly, you would only need to change .tooltip

In general, your CSS classes should relate to the semantic meaning of an element -- .important, .aside, .help -- and not the visual presentation of an element -- .blue, .padded etc. If all important elements need to change from blue to orange, it's easier if their class is .important (one change) and not .blue (where either you modify all important elements or you define .blue as being orange-colored).

<comment><USER3> I think the author failed to mention how this ties in with SASS/LESS mixins:

instead of writing obtuse HTML:

you could continue to write semantic HTML:

and then use mixins to separate the description of styling concepts and the implementation details:

        /*implementation details*/
        .corner-box {...}
        .brand-color-bg {...}

        /*style descriptions*/
        .sign-up-callout {
           .corner-box;
           .brand-color-bg;
        }

I suppose the downside of the approach is that you need to carefully maintain a dictionary that isn't too tied to implementation, e.g.

        .red {color:red;}

but also not too abstract, e.g.

        .box-callout {...}
        .box-call-to-action {...}

<comment><USER4> Essentially, a CSS DSL.

</comment></comment></comment><comment><USER5> This is massively mixing presentation with content. I know that doesn't matter to some (many?) people but I wonder if a compromise could be found with building up classes with SASS mixins that keeps your markup clean but gets some of the maintainability benefits of this approach?

Also - let's have the debate about the _practical_ drawbacks people are likely to discover when they use lots of presentational classes in their markup.

<comment><USER6> I think he's saying he does that at the end of the article:

> (These days most of my microclasses are tied to SASS variables or mixins.)

</comment></comment><comment><USER7> This is a great example of CSS becoming programming.

With preprocessors (mentioned at the end of the article), prototyping can finish with an element like

      <form class="content-box last mid-bg corner-box border-box bevel-box-light pad-box">
      ...
      </form>

then turn back to your application.less, throw in:

      .username-form {
        .content-box;
        .last;
        .mid-bg;
        .corner-box;
        .border-box;
        .bevel-box-light;
        .pad-box;
      }

and we're suddenly working with higher-level concepts in CSS, specifically _not_ the basics of the style attributes.

Working this way gives you room to play with in-browser prototyping in a strong way, using just the inspector and classes on elements to build up your visuals.

</comment><comment><USER8> Content should be separeted from presentation: css class names and ids, which are HTML attributes, should not be named after what types of content they mark, not how it should look like.

What the author is describing is like a shorthand for style attributes.

</comment><comment><USER9> This isn't even a valid example of DRYness; you're repeating yourself in your markup heavily to avoid it in your CSS. I hate to imagine ... every time I want to make a link.

</comment><comment><USER10> There was a similar article not so long ago about OOCSS + Sass. [http://ianstormtaylor.com/oocss-plus-sass-is-the-best-way- to...](http://ianstormtaylor.com/oocss-plus-sass-is-the-best-way-to-css/)

</comment><comment><USER11> I've moved in this direction also, and have found it's easier to maintain code this way. The one caveat I've noticed is that sometimes if you're working with two similar design elements and add a class to one, you have to go and remember to add the same class to the other. It's really not a big deal and it doesn't happen a ton, but it's enough to be mildly annoying.

</comment><comment><USER12> Working with jQuery UI that does this same thing is super painful and adds so much page weight when you see the same class over and over again. Using a SASS/Less solution would simplify it.

</comment><comment><USER13> This is not a win at all. I used to do this, until I realized that when I want to change something I have to edit all my template files.</comment>


Bytecoin (BTN): A cryptocurrency that is fun to mine - <AUTHOR> https://bytecoin.org/

<comment><USER2> it's BCN, actually

<comment><AUTHOR> Thanks for catching my typo!</comment></comment>