The famous quote goes: Success is 10 percent inspiration and 90 percent perspiration. I’m going to paraphrase it as: Software development is 10 percent programming and 90 percent perspiration. Consider the cost of a single if that introduces some new feature (e.g. a new flag): Write the if and the new branch. Write the comment on the reasoning (right?) Possibly add a metric to know how often the new branch it’s used.

Per connascence.io: Connascence of execution is when the order of execution of multiple components is important. In connascence of value one of the dynamic solution I proposed was: a Kubernetes service that subscribes to etcd and that on received changes redeploys a set of all the other Kubernetes services that depend on the updated values But such a service, as specified in the post, doesn’t solve the dependancy of order of redeploys.

Per connascence.io: Connascence is a software quality metric & a taxonomy for different types of coupling. I use it as a taxonomy and the mere concept is, to me, of huge help in both building and maintaining systems. Understanding and actively tracking connascence surfaces dependencies between components that sometimes never even touch directly. I use it to track values, names and algorithm dependencies between components written in different languages and that are developed in different development lifecycles.

NOTE: These are rough notes imported from… Notes on the book “A Philosophy of Software Design”. Btw - love the title and the use of “a philosophy”. Too many folks believe that their philosophy is the philosophy. Solving pass-through variables through global - Paul and I talked just about that recently. Globals solve the original problem but introduce other problems: harder to understand, harder to unit test, higher dependency on the surrounding process state.

At the end of 2016 one of my ex-managers approached me to see if I wanted to do a series of lectures for one of the courses on software development that he was designing at the time. The purpose, if I recall correctly, was to enable engineers from other professions to transition to working software developers in 6 months. At the end nothing came out of it but I just stumbled on the list of lecture themes that I wrote at the time so here it is - with warts and all (it clearly becomes rather sparse at the end).

Reading this article: Software Architects: Do We Need ’em? Great quote and often the hardest thing to do: “I wasn’t the one pushing things in the wrong direction, but I should have been the one to stop it.” – Chad Fowler The way I see it, the technical problems are mostly easy and it’s the people problems that are predominantly hard: communication, coordination, dominance games, different levels of commitment, likes/dislikes biases and so on.

Note: an early draft imported from heavily broken LinkedIn draft (they must have done a lossy migration in the past 10 years). Leaving it pretty much as it is with light edits for clarity and formatting. I’ve been programming for more than 25 years now, almost 20 of it professionally. As with many of us it started as a hobby and then somebody offered to pay me for it and here I am.

I’ve been thinking on HTTP API versioning lately. Troy Hunt’s Your API versioning is wrong… is the 1st hit when googling “HTTP API versioning” but I think it’s limited in its scope to dealing just with GET verb in public non-authenticated APIs. This isn’t explicit in the article but Troy was writing about the API to his Have I Been Pwned public service which only serves GET requests. I want to extend this discussion to other HTTP verbs and also authenticated APIs.

For when nothing else will to place a warning, in your code, to your future self or your fellow developers paste this: // // NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE // NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE // NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE // NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE // NOTE NOTE NOTE NOTE NOTE NOTE NOTE // It looks like hell here but trust me - after you copy/paste it into your editor, it will look something like this:

In the wild I sometimes see the following as implementation of NSCopying:copyWithZone: -(id)copyWithZone:(NSZone*)zone { MYClass* copy = [MYClass new]; copy.property1 = self.property1; ... copy.propertyN = self.propertyN; return copy; } This is wrong as accessing the copy and the original objects through . during the copying process itself must be avoided as each of those . may actually introduce side-effects. We are copying data here and the resulting copied object should faithfully reflect the state of the original object, not invoke methods on either of these objects.