Tech-inzichten door Niek de Greef. Reflecties op technologie, software development en de impact van digitale innovaties op cultuur en maatschappij.

Google’s Documentation Style Guide – helping the writer in the developer

Google have published a style guide for their developers.

It’s a nice guide for all writers of non-fiction.

Some cute things:

On semicolons (I never know when to use) not much help (https://developers.google.com/style/semicolons)

Where to use semicolons is often a matter of judgment. Use them judiciously.

In the resources section the style guide refers to Apple’s and Microsoft’s style guides. (https://developers.google.com/style/resources)

Other companies’ style guides, such as the Apple Style Guide or the Microsoft Manual of Style.

Anthropomorphisms, which I like especially in documentation (makes them read like a novel, if done well), however not recommended by Google (https://developers.google.com/style/anthropomorphism):

Examples

Not recommended: A Delimiter object tells the splitter where a string should be broken.

Recommended: A Delimiter object specifies where to split a string.

Just one I did not understand (https://developers.google.com/style/headings):

Things to avoid in headings

Don’t use the following in headings:

Enjoyable.

Should you learn how to code?

Everyone in IT should know the basics of programming. (Also you should have installed some Linux distribution on your laptop. Even if its your laptop, it increases your understanding of the complexities of managing a platform.)

Program something

Program a crappy little program, you will understand more about the challenges of the programmer.

Derek Sivers wrote a nice article about why you should learn programming. https://sivers.org/prog
For him learning to code means self reliance and basic understanding are the main reasons.

Also experience the joy of building you own computer. I helped my son when he built his gaming computer. I learned at least as much as he did.

What language to start with

Derek recommends to start with HTML and CSS. Well, yes, agree of if you are interested in programming web sites. But HTML is such an ugly programming language. It’s like staring programming with BASIC. Before you know you think GOTO is a great flexible feature. While it actually is kitsch. I would rather start with Python, php or Java.

Build something useful in a very short time. Make it ugly. It doesn’t matter. Improve it step by step. Or start something new.

I like exploring programming languages.

 

I recently played with php. Built a small website showing photo’s from google images using random keywords.
Using MAMP.

Then played with python, programming an interface between Kindle and Evernote. Used Pydev.

Did some Javascript and node-RED.

A lot of Rexx programming. 

And Erlang.  That’s a hard one if you are not familiar with functional programming languages.

I learned a ton. I am always amazed what you can learn FOR FREE on the Internet.

Programming: a profession

Programming, a profession not a monkey task

A few years ago an IT manager said to me: for this programming job, I should be able to hire any monkey from the street.

I told him such an attitude would very quickly ruin his application, if not his entire business.

For an organisation that relies on software so heavily, allowing unmaintainable code to enter your applications is like accepting a loan your will never be able to pay off. You are building up an insurmountable technical debt. You can only hope you have some superb programmers around when the bugs hit the fan.

Programming profession

But for us programmers the problem is also about professionalism.

Coding is a profession. Good programming is a skill.

Some organisations want to have code done for 5$ per hour. Or so. Less than you would pay for a plumber. You would trust a plumber for that rate, why leave a programming job to someone for that rate? You are simply not serious about the problem at hand if you hire like that.

Democratization – the amateur and the pro

There is a tendency to underestimate the importance of skill.
Programming is democratized. That is good. Coding is not something mythical either. Amateurs can do it. Do it well. And enjoy it.

But for the problem in my organisation I need a pro.

Photographing is democratized. But for my wedding photos or for my business brochure I hire a professional photographer. Because he has a number of things extra, which I would summarize a craftsmanship and experience.

If you want stuff done you want good craftsmanship. A specialist you can talk to.

And by the way, ideally they should be at your desk and you at their’s. This is where outsourcing often goes off the track. Too little interaction.

Go pro

Cheap programming may work for throw-away apps. But not for high quality solutions that need to work be maintained for a couple of years or more. That stuff is built for the future. For maintainability.

By an expert.

The roots of modern computing explained in EWD51 – Multiprogramming and the X8

Dijkstra’s EWD 51 is a structured educational coverage of the workings of semaphores in communicating processes and with IO devices. It is the first part in a series of three articles called MULTIPROGAMMERING EN DE X8″ (Multiprogramming and the X8), EWD54 and 57 describe part 2 and 3.

if then else

The X8 is the Dutch research computer for which Dijkstra and hos team developed the operating system, and he was able to test his now famous concepts for multiprogramming. 
In a way it is the formal part of the talk that Dijkstra held and was transcribed in EWD 35.

EWD 51 extensively discusses the mechanisms of semaphores, the conditions, and (hardware) implications. That is the summary. To give more would be pointless, and you’d rather read the entire article. (The article is in Dutch – I could provide a quick translation if you are interested. Please let me know through a comment on this post, or send me an email)

The Dutch language used in this article is highly interesting. Dijkstra invents concepts for which no words existed before (seinpaal/semaphore as computing concept to start with) the abbreviations P (prolaag/pass – probeer te verlagen) and V (verhoog/increase), critieke secties / critical sections, ingreep-flip-flop / interrupt-flip-flops, luisterbit / listener bit, doof-horend bit.

The article could still  function as a modern introduction into the topic and still be applicable to today’s computers.

So far ahead, so clear, so up to date still.

Singularity Is Near – Kurzweil meets Dijkstra

the singularity is near Ray Kurzweil book cover

While reading Ray Kurzweil’s The Singularity Is Near, I stumbled upon a quote attributed to computer scientist Edsger W. Dijkstra that made me pause, not because of what it said, but because of how it was used.

The Disputed Quote

Kurzweil cites Dijkstra as saying: “Computer Science is no more about computers than astronomy is about telescopes.”

It’s a clever aphorism that sounds exactly like something Dijkstra would say. There’s just one problem: the attribution is disputed, and the original source remains elusive.

Searching for the Source

I dove into the Dijkstra archive at the University of Texas, which contains his extensive collection of EWD manuscripts. Despite searching through his papers, I couldn’t find this exact quote. Wikiquote also lists the attribution as disputed.

Could Dijkstra have said it? Absolutely. Despite being a world-renowned computer scientist, he famously avoided using computers for his work, reportedly owning one only to read email and browse the web. For him, computer science truly was about ideas, not machines.

But the lack of a verifiable source matters—especially in a book making grand claims about the future.

Context Matters: Why This Quote Feels Out of Place

Kurzweil places this quote in a chapter discussing exponential growth, Moore’s Law, and paradigm shifts. But the connection feels forced. The Dijkstra quote speaks to the philosophical nature of computer science as a discipline. It doesn’t illuminate anything about exponential technological progress or the coming singularity.

This seemingly minor misplacement reveals a larger issue with The Singularity Is Near: the blending of rigorous scientific facts with personal predictions that lack the same level of substantiation.

Two Visionaries, Two Approaches

The contrast between Dijkstra and Kurzweil is instructive:

Edsger Dijkstra: An unconventional theoretical scientist known for mathematical rigor and precision. Every statement in his EWD manuscripts was carefully reasoned and documented.

Ray Kurzweil: An unconventional futuristic engineer and inventor. His predictions are bold, optimistic, and often based on extrapolating current trends.

You might expect Dijkstra to be dry and academic, while Kurzweil would be the more engaging personality. But here’s the surprise: the biggest difference between their work isn’t their subject matter or their ambition—it’s humor.

The Missing Ingredient: Humor

Dijkstra’s writings are filled with wit, self-awareness, and intellectual playfulness. He could be cutting in his criticism, but always with a touch of humor that acknowledged the absurdity of certain positions. This humor wasn’t just stylistic. It was a sign of intellectual honesty and humility.

Kurzweil’s The Singularity Is Near, despite its grand vision and fascinating ideas, takes itself entirely seriously. Every prediction is presented with confidence. Every trend will continue. Every obstacle will be overcome. There’s little room for doubt, irony, or the acknowledgment that futurism is, by nature, speculative.

The Problem with Unquestioning Optimism

This lack of humor—and the self-awareness it represents—makes Kurzweil’s predictions less credible, not more. When you can’t laugh at yourself or acknowledge the limits of your knowledge, you risk becoming a prophet rather than a scientist.

Dijkstra understood that computer science required both rigor and humility. He documented his sources, admitted when he was speculating, and never confused his hopes with inevitability.

Kurzweil’s work would be stronger if it borrowed more from Dijkstra’s approach: not just his ideas, but his intellectual honesty.

What We Can Learn

The misattribution (or at least unverified attribution) of the Dijkstra quote is a small detail, but it’s emblematic. It suggests a book that prioritizes narrative momentum over scholarly precision. That’s not necessarily wrong for a work of futurism, but readers should understand what they’re getting: a compelling vision more than a rigorous prediction.

When reading about the future of technology, it’s worth asking: Is this backed by verifiable evidence, or is this someone’s optimistic extrapolation? Are the sources documented? Is there room for doubt?

Dijkstra would have insisted on all three.


Further Reading:

Related posts: