I see this sign on the noticeboard in the staff kitchen every day, and thought I ought to share the wry little WTF it invokes, every last time.
sorry i redacted it slightly; i think the guilty deserve some protection too; they're just hard working kids in the end)
 |
 in cartoon form too! |
I really love this timeless Tom Van Vleck article from 1989.
It teaches us to ask ourselves:
Those questions being:
When I first read these rules, I was foolish enough to think:
'Cute, But Too Obvious! i do this intuitively all the time.'
But watch yourself closely! I've caught myself out on occasion, and maybe you will too.
I'm making an effort to be more explicit about the three questions. Maybe i'll end up fixing related problems at first hint more often than i do now.
 don't got time to shave. |
I keep hearing rather a bit too much about this Pareto Principle.
Apparently, with just 20% effort, correctly applied, I can achieve 80% of the desired effect. Marvellous stuff!
I was about to go ahead and do this when it occurred to me:
"Why waste all that time, doing a whole 20%?
"If I only did 20% of that 20%, then surely I could achieve 80% of the 80%?"
Then with a little more head scratching, and the help of an excel spreadsheet, I determined that with just 0.8% of the effort I could achieve 51.2% of the result -- which is a PASS in anyone's books.
So from now on, you will excuse me while I spend 99.2% of my time:
Lounging around, drunk, in a pool bar and
Determining exactly which 0.8% of the effort to apply myself to.
Unless, of course, it takes 80% of the effort to work out exactly which 20% will achieve the desired effect. And it takes...
A couple of weeks ago I put out a twitter post I've been meaning to come back and explain:
"the habits of a good programmer are not simply orthogonal to good communication -- frequently they're in direct opposition."
http://twitter.com/secretGeek/status/1870937085
This is a pretty startling and upsetting result: I'd like to think that the heart of good programming is crisp and direct communication. That all of my efforts to be better at programming will, somehow, make me a better all-round person. If only it were true.
Here's a bunch of ways that good programming practices are directly opposed to good communication practices.
In bullet form:
And in detail:
The golden rule of programming is D.R.Y. -- don't repeat yourself. This is the heart of effective programming. But this is the opposite of effective communication.
Let me say that again:
The golden rule of programming, DRY, is the opposite of effective communication. ;-)
Say everything once and only once -- go ahead -- then be amazed as everyone misses your point!
Humans are not machines. Memories made of this gooey, spongy stuff called a brain are nothing like memories made of silicon.
With Humans, nothing sinks in the first time. And furthermore, you may be surprised to hear that NOTHING sinks in the first time.
 Nietzsche preferred the company of a good compiler over that of a human. "Compilers never make fun of one's moustache," --Ibid., pg 293. |
Compilers are of course perfectly literal. They don't care at all what you mean, they are always hung up on precisely what you say.
Even if you didn't start off life as an anal-retentive git, you'll slowly gain the requisite faculties over years of trying to please a compiler.
The art of trying to please a compiler consists of the ability to logically, dispassionately, analyse what you've said, to discover and remove any mistake or ambiguity -- to always produce an output that is perfectly comprehensible to the strictest of master.
Try being like that around real people. Just try it.
People are barely literal at all. If you take them literally when their meaning differs from their words -- they will get quite irate with you. They won't see that the mistake is theirs.
When the words they use differ from their intent, you may feel an overwhelming desire to 'correct' their mistake. You may even think you are doing them a favour.
This is a natural feeling, amongst programmers, who would be happily spared the torture of spending time trying to remove all ambiguity from the words they provide to a parser.
But please (please) hold back. You might score a small point in the 'intelligence' column for pointing out their 'mistake'. But you'll also score about a bajillion points in the 'what a freaking dork' column.
Explain a function to a compiler, and it will be able to calculate the answer.
Explain a function to a human... and then give them an example, and draw them a picture, and give two counter examples, and draw another picture, plus provide an interpretive dance on the topic of functions -- and maybe, just maybe, if you've danced very nicely, they will begin to see "what you're trying to say."
"What I'm trying to say?" I'm saying it damn clear! I'm saying it directly, concisely and with perfectly constructed phrases! I'm not trying to say anything! I'm succeeding, you're just not listening, you freaking imbecile!
And don't take that tone with me. With humans I mean. There's no point yelling. Their rational mind shuts down, their sympathetic nervous system takes over. They get ready to fight or flee. Your point is lost when you get them angry.
Computers don't mind if you type angry. Humans think the anger is more important than the words themselves.
When you have the customer in a headlock, knocking their face against the ground with every syllable: the syllables themselves are no longer of tremendous consequence.
True: that bit about beating up the customer may not be a typical trait amongst great programmers. Perhaps I included it just for entertainment purposes. Continuing...
In programming we define new terms all day long. We define class names or function names or variable names.
We immediately attach a specific definition to them -- and then we use that definition throughout our code.
I imagine that some part of the brain is associated with the ability to define a new term and then hold onto its definition. That part of the brain would be monstrous in programmers. Very over-developed. Gigantic -- a tiger amongst kittens.
But define a new term in front of an audience of non-programmers: watch as the eyes glaze over. Heads slump forward. They start planning their weekend.
Let's call this our Neologismic Synaptic Aptitude, or NSA. Actually: let's not call it our NSA, because if we do, then programmers will start bandying the terminology around like it's something we've known about all their life. And the normal people will just look at us with that 'freak' expression, and we'll be even further from ever making it into the boardroom.
I think this aptitude for new terms is what makes TLA's so abundant in the IT world. I do hope you realise it scares everyone else.
Stop defining new terms. Stop expecting non-programmers to understand the specific and concrete definitions you attach to funny little abbreviations.
Stop striving for brevity and conciseness.
Stop correcting other people.
Stop expecting people to understand you first time around.
Start giving examples -- real examples, earthy examples.
Let people be people -- let them be vague and a little incorrect -- listen more for the gist of what they're saying than the exact terminology.
Be a compassionate speaker, a compassionate listener. Embrace the 'all too human' aspects of the strange bipeds you interact with.
Then drop me an email and please, for the love of god, tell me how you managed it.
I feel sorry for the programmer who was forced, no doubt after endless emails, meetings, focus-groups and think-tanks to check this obscure non-warning warning message into the Windows source tree...
"The amount of physical memory in your system has increased. This typically does NOT indicate a hardware failure. Contact your Help Desk if you did not personally change your system's physical memory configuration."
Why didn't they say "Congratulations!" or "Good news" or "Ahhhh! thanks for feeding me those yummy ram chips!" or best of all:
"Well, how about that! The tight bastards in IT must've approved that RAM upgrade request we noticed you writing in MS-Word, all those months ago.
"Now let's see if we can get the cowards to consider upgrading the browser to IE 7."
There is a hidden network of bloggers (all around you), a kind of secret brotherhood...
These are the 'ghost bloggers'.
'Ghost-blogging' is the practice of sharing true stories about your own working life, true stories too cutting, too poignant and too true to share on your own blog.
The following is an example of a ghost blog entry, sent to me by someone I know, appalled at some of the Kafkaesque behaviour they've been subjected to inside the kind of enterprise everyone should find familiar.
(I've ghost-blogged my own personal stories on other blogs, at times...)
Here goes...
 Requirements Tracking and Deployments |
In the enterprise when they say: "don't worry about that, another team will do that for us" what they mean is: "you just took on a dependency that you have no control over".
In the enterprise when they say "we want you to re-use this standard asset" what they mean is "we want you to hold on to this gold-plated, diamond encrusted anchor while we throw you over the side".
In the enterprise, the group allegedly responsible for 'provisioning developer desktops' will, in actual fact, be the group who expends every effort imaginable to stop developers from being able to actually install developer tools onto their desktops.
In the enterprise when there are three separate groups, allegedly responsible for version control, requirements tracking and deployments, you'll find in practice the requirements are documented through excel spreadsheets over email, the source code won't build, and the deployments take everyone by surprise, including the deployment team.
In the enterprise when they talk about 'strategic direction', they mean 'strategy tax'.
In the enterprise when they ask you to "simply call a web service", what they mean is, "use ftp to push a fixed-width file onto a queue that feeds the mainframe which routes another file to a web service that calls you back on a random port". With a completely straight face.
Follow this simple three step guide to become a proud member of the awesome club of people who loudly proclaim:
"I too am cool! I too have an iphone!"
Go to the settings area of the mail client you use on your regular PC
Change your email signature to read 'Sent from my iPhone'
Send short, pointless emails to everyone you know
Okay, you won't technically have an iPhone. But for the most part, other iPhone users will *want* to believe that you have joined their "team" -- hence, they will be convinced.
And -- as a final twist -- once you're thought to be a member of their team, you'll find that acquiring an actual free iPhone will be easy. Other iPhone owners will be more than happy to let you borrow one of their iPhones next time you see them, if you claim to have momentarily misplaced yours, for example in the pocket of "your other white leather trousers".
--lb
Sent from my iPhone
Well, It turns out that the 80's geek classic, 'War Games' has inspired a sequel, the film
'War Games: the dead code' was released in 2008. Though, perhaps the correct term is 'foisted.'
WG: TDC is such a deliberately bad film that you can only begin to enjoy it once you grok that it's a comedic satire.
For the first hour and a half I assumed it was trying to be a cool, teenage-targetted tech-savvy thriller, like the original. This had me wincing in agony at every bad line and predictable twist. Only then did I realize it was all a joke: a parody of the teenage-targetted tech-savvy thriller. A kind of 'scary-movie' style satire of the entire genre. Hopefully?
Well, I've just finished watching it and it's inspired me to share a few helpful tips for up and coming programmers.
As one of today's young parents, I can tell you what concerns us. Not swine flu, or global economic disasters and so forth. What really keeps us terrified at night is a desperate hope that we, as parents, take all of the right steps to ensure that our sons and daughters grow up to be thoughtful, well-meaning, much loved people. In short: How Can We Be Certain Our Children Will Become Programmers.
And a lot of hard work (err, blog posts) have gone into that endeavour, but as usual I like to look beyond the obvious problem, and into the deeper realms or possibility:
If you're child does (thank god!) grow up to be a Programmer -- what simple lessons can you provide to ensure they don't inadvertently destroy the planet?
Programming is a powerful profession, and as you well know, global apocalypse is but a keystroke away. We want to give our kids the right tips to ward off such misadventures -- to learn from our wisdom, as it were.
Fortunately, like all global catastrophes, this one can be averted with another 3 minute guide from secretGeek.
Please, sit back, breath a deep sigh of relief for the salvation of your measly planet, and drink deep of this crucial lesson to imprint upon your younglings:
(I have included links to information about Government-Approved documentary films on each of these points. I only pray you heed my warnings and enforce these lessons before we are all routinely destroyed.)
If, after pre-supposing a minimal competency level in your opponent, a game's inevitable state upon termination is mutually-assured destruction, then the only winning move is not to play.
My personal contiuous integration suite won't let me commit any code until I can demonstrate 100% code-coverage with remote-shutdown killer viruses.
This is s.o.p. (...that's standard operating practice, if you're not a super-spy type like me, who knows all the jargon). Never discuss shutting down your software until you have found a locked, sound-proof chamber, where the computer system cannot hear your discussion. Also, in case there is a remote possibility that your software has learnt to read lips, let me suggest you cover your mouth.
Simple, every day precautions.
[side note: a parody of this famous Kubrick scene was included in 'the dead code'. nice.]
Grandiose, open-ended philosophical questions tend to have a compute time in the order of millions of years.
Similarly, when given a dilemma (e.g. "This sentence contains a lie") a self-aware program will tend to explode spectacularly. A competent programmer will keep a few of these handy.
You may need to send someone back in time to protect the mother of the person who leads the rebellion against the self-aware software in the future.
Maybe you're not very creative, and don't have the time to give your machine a stunningly inventive new exterior. So you fall into the tired old pattern of mimicking the human body.
That way, badness lies.
Fairly self-evident that one.
Scissors for example, are not recommended, even if they are 'just for now'.
Switch off all electrical equipment during thunder storms.
Hardwire 3 clear and unambiguous rules into the program's positronic brain that will ensure all humans are safe from harm.
Hopefully, if you follow my advice, we can avoid any more major disasters. But please: always be nice to your inventions. Hopefully then, should the unthinkable happen, your self-aware creations will take pity on us and keep us barely alive in liquid chambers so they can gorge on our brains.[reference]
Oh, and if you don't believe in self-aware robots... (cough cough) here's some i prepared earlier.
See also (important information in similar vein)
titled 'Lower' and 'Upper'. |
(or add a new one) |
document's main textbox is exposed as txt.) |
everything's extenisble... everything. |
I've open-sourced a side project of mine, MetaNote.
Here's the gist of it...
MetaNote is a text editor. Ultimately, MetaNote intends to be the most versatile editor imaginable.
See that button in the toolbar? Right click on it, and edit the code behind it.
Don't like the way 'Find' works? -- right click on it, and edit the code.
Need a new button in the toolbar? So add it already, with a single click.
Share packs of extensions and macros with other users.
Everything in MetaNote is under your control, effortlessly, at runtime.
It's easier to show than to describe -- maybe the pictures on the right give you the idea.
The source code is available to browse or download. This is very much pre-alpha. It is explorative and non-commercial.
binaries are also available to download.
The project is written in C#, and I need your help getting it done.
I've got many of the basics done, but I'm only at the tip of what's needed.
I'm looking for clever kids like you, willing to help out.
What do you think? Can you take a look at the code, and lend your fellow programmer a few minutes of your time?
I'm not doing it for any commercial gain, i just want a text editor that I can bend to the whims of whatever writing task I come across.
There's a great many features still in need of implementing, and already there are wrong turns to be corrected.
Down the track I really want to find some way to embed the WPF-based Text Editor Control from VS2010. It's the same one used in intellipad (part of Oslo) and in Powershell 2.0's (awesome) Integrated Scripting Environment -- I didn't have any success bringing it to life just yet. So, for now the text is plain text, and features like syntax highlighting and intellisense will have to wait.
One of my mentors tells me the smart approach would be to bring in MEF for giving a really powerful plugin model, where plugins can have plugins and so on.
The intermediate goal though, is just to make the tool sweet enough that I'd use it for my own day to day text editing needs.
And one day, hopefully one day soon, this thing won't suck at all.
Couple of days ago I wrote a C# function for a colleague and emailed it to him.
This is the function:
secretGeek.net
private static string EscapeCsv(string value)
{
//Double all quote characters
value = value.Replace("\"", "\"\"");
//If it contains a comma or a quote char -- qualify it with quotes.
if (value.IndexOf('"') > -1 || value.IndexOf(',') > -1)
{
value = "\"" + value + "\"";
}
return value;
}
The syntax highlighting looks very strange, because I wrote it in sql server management studio. It just happened that the only text editor i had open at the time was SQL server, so that's what i used.
(Real developers don't use any particular editor -- they just use whatever's open at the time. Even the act of opening notepad is too cumbersome for the ubergeek.)
After I emailed it to my colleague I had a moment of weakness, when I suffered the tiniest smidgen of self doubt.
"Perhaps I should've tested the code in some way. Or -- at least -- compiled it?"
Scott Bellware and the cool alt.net kids are always banging on about this sort of stuff, so I wrote an awesome console app to test it.
namespace tests_are_for_wusses
{
class Program
{
static void Main(string[] args)
{
System.Console.WriteLine(EscapeCsv("fred") == "fred");
System.Console.WriteLine(EscapeCsv("fre,d") == "\"fre,d\"");
System.Console.WriteLine(EscapeCsv("fre\"d") == "\"fre\"\"d\"");
System.Console.ReadLine();
}
private static string EscapeCsv(string value)
{
//Double all quote characters
value = value.Replace("\"", "\"\"");
//If it contains a comma or a quote char -- qualify it with quotes.
if (value.IndexOf('"') > -1 || value.IndexOf(',') > -1)
{
value = "\"" + value + "\"";
}
return value;
}
}
}
Naturally, the awesome code passed my awesome tests first go.
Thus I have once again shown that testing is a waste of time if you are awesome like me.
And the so-called cool kids from alt.net are just bad programmers.
Thank you.
Wait a second... I still feel I'm missing the point. Care to enlighten me?
(By the way -- pretty much every sentence in this post was sarcastic... while the story is true, my real interpretation is that i just got lucky this time. There's definitely some bugs still hidden even in a simple function like this)