Bookmarks

...no matter how much I spun, nothing about my situation ever changed. I worked my week, got to the end of it, and had nothing to show. The next week there would be more emails and more tickets, exactly like the week before. The week after that would be more of the same. And absolutely nothing about my life would change. I'd end the week with nothing.

We’ve been led into a culture that has been engineered to leave us tired, hungry for indulgence, willing to pay a lot for convenience and entertainment, and most importantly, vaguely dissatisfied with our lives so that we continue wanting things we don’t have.

In this post, I’m going to introduce you to the concept of Linux network namespaces.

Please Don't Say Just Hello In Chat

The other trouble with the promise that you can be anything is that you can spend a lifetime trying to be anything, forgetting that you actually already are something.

In this post, I’m going to set the stage by describing how individuals opt into permanent mediocrity and reap rewards for doing so.

You should write because when you know that you’re going to write, it changes the way you live...you will live more curiously if you write

This is pretty much how I feel every time I talk to my engineering friends about salary negotiation. We overwhelmingly suck at it. We have turned sucking at it into a perverse badge of virtue. We make no affirmative efforts to un-suck ourselves and, to the extent we read about it at all, we read bad advice and repeat it, pretending that this makes us wise.

'How much did we create today?' is not a relevant question to ask. Even if it could be measured, productivity in software does not approximate business value in any meaningful way.

Fail fast = quit and give up easy = spaghetti against the wall = no clear strategy going into your business = no ability / willingness to try and pivot as market conditions change = easy way out = today’s management mantra that will be laughed at in 10 years.

The Peter Principle is wrong for the simple reason that executives aren’t that stupid, and because there isn’t that much room in an upward-narrowing pyramid. They know what it takes for a promotion candidate to perform at the to level. So if they are promoting people beyond their competence anyway, under conditions of opportunity scarcity, there must be a good reason.

Because my shell script names tended to be short and pithy collections of lowercase characters, just like the default system commands, there was no telling when Linux would add a new command that would happen to have the same name as one of mine.

The nothing to hide argument and its variants are quite prevalent, and thus are worth addressing. In this essay, Solove critiques the nothing to hide argument and exposes its faulty underpinnings.

In a fight between user inertia and anything else, bet on user inertia.

The 'software crisis' was first identified in 1968and in the intervening decades has deepened rather than abated... but the purpose of this paper is to give some cause for optimism.

Look for coding conventions that make wrong code look wrong. Getting the right information collocated all together in the same place on screen in your code lets you see certain types of problems and fix them right away.

This paper proposes there are a number of seminal differences between data inside a service and data sent into the space outside of the service boundary.

When somebody tells you about methodology, think about how it applies to the work you’re doing. Think about where the person is coming from.

...since we're awash in this contemporary ocean of speculation, we forget that things can be known with certainty, and that we need not live in a fearful world of interminable unsupported opinion. But the gulf that separates hard fact from speculation is by now so unfamiliar that most people can't comprehend it

We’re programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We’re not excited by incremental renovation: tinkering, improving, planting flower beds.

The truths described in this memo result from extensive study over an extended period of time by many people, some of whom did not intend to contribute to this work. The editor merely has collected these truths, and would like to thank the networking community for originally illuminating these truths.

Please don't bother me with small details right now. Your job is to develop the overall plans for the house: get the big picture. At this time, for example, it is not appropriate to be choosing the color of the carpet. However, keep in mind that my wife likes blue.

Thus spake the Master Programmer: 'Though a program be but three lines long, someday it will have to be maintained.'

There is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement in productivity, in reliability, in simplicity. In this paper we shall try to see why, by examining both the nature of the software problem and the properties of the bullets proposed.

A program lives in the minds of the people who work on it. The code is merely a written representation of the program, and it's lossy, so you can't reconstruct a program from its code.

In my work, I probably spend about ninety-nine percent of my time on what others may call petty details. Most managers would rather focus on lofty policy matters. But when the details are ignored, the project fails. No infusion of policy or lofty ideals can then correct the situation.

...is this honest? Is not our prolonged silence fretting away Computing Science's intellectual integrity? Are we decent by remaining silent? If not, how do we speak up?