Super Volatile

And, there is no standard way to do things. Sure, there are conventions and patterns, but often good developers don’t agree on the right way to build something. How often do you think two plumbers argue over the right way to plumb a bathroom? Almost never!

While on the surface the article poses intriguing questions, it misses out the fact that all software is by nature unique. The only programs worth writing are the ones that have never been written before – anything else can be reused or bought. That's why writing software is still a craft and not an automated production line.

So as I sat there today for several minutes watching maven download jars, I realised I want the pain that its shielding me from back in my face. Don’t medicate me away from pain with these abstractions. In the human body pain is feedback calling attention to something that needs to be fixed. The wise response is to pay attention, not to medicate. So this is why I am against maven and spring and the like. They attempt to cover over things that I want direct contact with, things that I want to feel, things that give me feedback. If my app is hard to configure, I want the feedback. If my app is a 50MB war with a ton of dependencies, I want the feedback.

Experiencing the pain of development makes sense only if something will be done about it, otherwise it's just masochism.

The human principles of software are truly timeless; The Psychology of Computer Programming was written way back in 1971, a year after I was born!

Another example of how little we know and appreciate about programming's history, in the constant pursuit for The New.

My friend says, well, we've gone 40 miles in 4 days, it is at least a 600 mile trip, so that's 60 days, probably 70 to be safe. I say, "no f--ing way... yes, I've never done this walk before, but I *know* it does not take 70 days to walk from San Francisco to Los Angeles. Our friends are going to laugh at us if we call and tell them we won't see them until Easter!

This metaphor for software estimation is so accurate it's not even funny.

What if you were on the Starship Enterprise and the warp coil was seconds away from an anti-matter explosion and all you needed to do was invert one IF statement to save the ship. Would you use TDD for that?: Yes.

The article embodies what I see as the biggest problem with Test Driven Development's evangelism: it's full of religious zeal, but short on real-world numbers.

Which situation would your rather be in: risking $100,000 investment for a $200,000 return, or risking $1,000,000 investment for a $50,000,000 return? This might seem like a self-answering question, but virtually all programming hires fall into the first category.

The rebuttal from the first comment is by far more interesting that the article itself:

I will counter with this -- what if I could invest 1 dollar to get a possible return of 206,000,000 ... the lottery is an AWESOME INVESTMENT... wait, odds of success matter, dam

I settled on combining all forms of input into a single system event queue, similar to the windows message queue. My original intention was to just rigorously define where certain functions were called and cut down the number of required system entry points, but it turned out to have much stronger benefits.

With all events coming through one point (The return values from system calls, including the filesystem contents, are "hidden" inputs that I make no attempt at capturing, ), it was easy to set up a journalling system that recorded everything the game received. This is very different than demo recording, which just simulates a network level connection and lets time move at its own rate. Realtime applications have a number of unique development difficulties because of the interaction of time with inputs and outputs.

Transient flaw debugging. If a bug can be reproduced, it can be fixed. The nasty bugs are the ones that only happen every once in a while after playing randomly, like occasionally getting stuck on a corner. Often when you break in and investigate it, you find that something important happened the frame before the event, and you have no way of backing up. Even worse are realtime smoothness issues - was that jerk of his arm a bad animation frame, a network interpolation error, or my imagination?

Reading the archive of John Carmack's aaaa.plan files files a bit like archeology of programming and game design. I still remember playing the games he was writing at the time.

Frequent insights about programming are intertwined with boring parts concerning tuning and racing with his Ferrari cars.

In order to help identify these hot spots and warn developers, we looked at bug prediction. Bug prediction uses machine-learning and statistical analysis to try to guess whether a piece of code is potentially buggy or not, usually within some confidence range.

How Google uses statistics to find troublesome places in the code.

After we committed to the decision, we handled the move to Git slowly and delicately for a few reasons. One is that we deploy around 30 times a day across an engineering organization that was about 80 people at the time. We didn’t want to lose any of that velocity (we knew we might lose some in the beginning, but wanted it to be as seamless as possible). Another was that we had a varying range of Git familiarity across the team. From Git experts to people who had never touched it. Education played a huge part in our successful transition. It was also important for us to continue the use of flagging code on/off and having a continuously deployed trunk mentality even after the switch to git.

It's seems that people at Etsy know what they're doing. The blog is worth subscribing, if you're a software engineer.