Hiring Jon Skeet

Do you want to know a secret? I can help you headhunt and hire Jon Skeet. Yup! I guarantee you with 100% certainty even that I can make Jon work for free for you too. You don’t even need to pay Jon a single dollar to have him write most of your company’s C# code.

It’s really quite simple indeed, just hire any junior .Net/C# software developer, and 5 months down the road, Jon Skeet has probably produced most of your company’s code. Simply because most junior developers are copying and pasting code off from StackOverflow.com – Where of course Mr. Skeet has answered most of the accepted answers about anything relating to .Net and C#, implying Jon’s effectively already written most of your current code base. Resulting in that Jon is probably the by far most productive C# software developer alive today, having possibly written as much as trillions of lines of code, in millions of software companies, all over the world. Pretty impressive feat too may I add, considering the average developer is able to produce roughly 10 lines of code per day, according to the Mythical Man Month …

Doing statistical analysis on this, would probably purely from a scientific point of view, result in realising that Jon Skeet is creating some roughly 10-20 millions of lines of code, every single day, in thousands of companies, on an average day – Compared to the roughly 10 lines of code the average developer is able to produce, for one single company per day.

I think there might be some kind of Andy Warhol/Xerox Copy joke in there somewhere, but it’s too late for me to pull it out. But feel free to fill in the blanks if you feel creative … 😉

Making babies

If one woman and one man can make a baby in 9 months, how much faster then can’t 100 women and 100 men make a baby?

The above might sound like a joke, but is actually an “urban myth” when it comes to software development. Most non-technical managers believes that 100 software developers can move 100 times as fast as 2 software developers – However, as we can clearly understand by the above joke, this is clearly not the case. Even after experiencing this hands on for themselves, often several times may I add, they still seem to cling to their past delusions of that adding more software developers to a project shall somehow make it faster this time. Fact are: “Adding more software developers to an already late project only makes it later!” Or to say it with different words: “One software developer can do in one month what two software developers can do in two months!” – Etc …

In fact, the above statements, are backed up by 50+ years of solid research and science. So why are managers so deluded? Why do non-technical staff seem to believe it’ll go faster if they simply add more manpower to the problem?

Well, because they compare it to traditional work, such as for instance moving furniture, or harvesting potatoes – Where if we add more people to the problem, it obviously goes faster. However, software development simply doesn’t obey by this traditional way of seeing things, and it probably never will either. To explain why, let me ask you a question …

If Michelangelo could paint the Sixteenth Chapel in 4 years, how much faster wouldn’t the chapel be finished if Michelangelo had asked Da Vinci to help him out? If you don’t understand why the previous sentence is funny, may I suggest a book? Literally any book. Then read it for x-mas. When you’re done with your book, buy another one, read it too, and continue until you “get it”

… because it’s actually quite funny in fact 😉

Alternatively, read the header of this article once more, if you’d like to digest the funny parts faster … 😀

The Art of Efficiency

Every now and then in our journey through life, we meet some amazing individual, able to astound us, either because of their resolve, stamina, knowledge or wisdom – Tim Ivaikin is one of those individuals for me. When Tim became my colleague, I immediately understood that he’s an extraordinarily skilled software developer. And as we started talking about Buddhism and Philosophy, I also realized that he’s much deeper than what you would normally expect from a “mere software developer”. However, what I didn’t know, before today in fact – Was that he had written a book – Which perfectly illustrates his meek nature may I add 🙂

Tim’s book, where he combines his software development theories with Philosophy and the ideas of Buddhist Enlightenment

In the first chapter of the book, he manages to use analogies of “never ending loops” to illustrate bad habits, scrum as a process to achieve entering the now, and software development theory as the means to improve how your brain works. I am not sure what to say really, I am simply stunned! But one thing I do know, I now know what I want for x-mas!

Buy his book here

My DZone articles

I remember DZone from more than a decade ago, when it was a small website, where if you went viral, at most you’d get some 3-4.000 page views. Today even a “flunked” article often gets 10-15.000 views, and it’s everything but a small website, but rather one of the primary sources of information for aspiring developers, looking to learn the tricks of the trade.

I’m a member of their core team, which implies I get early access to having my articles published, and I get invited to attend meet-ups and gatherings. In addition I get access to exclusive statistical material, giving me hints and clues about trending subjects, such that I know more accurately what I should write about, to increase the likelihood of gaining lots of page views. I have followed DZone on this journey now for more than a decade. Just some few years ago, Mike was little more than an avatar with a photo. Today him and Blake, their community manager, are living people, whom I can relate to, and have private conversations with – Sometimes face to face. And with this change, came the opportunity to be heard, be listened to, and raise my voice in regards to how they develop and maintain their site. I love it.

Below are some of my articles for those that’s interested in what the “weird Hyperlambda dude” has been writing about over there for the last couple of years.

There are many more, but you can probably find them from my breadcrumbs above I presume. However, a popular article of mine today, easily gets more than 20K readers. 10 years ago, I was lucky if I would get 4K readers. I congratulate DZone, Mike, Blake and the others on this growth, and I hope to be able to follow them for many more years. Thank you #DZone 🙂

The things you cannot reach for

A couple of days ago, I was invited to Tim and Sergey’s podcast. We were supposed to speak about Magic and automation in software development – But ended up speaking more about Buddhism, Spirituality, Art and life in general. Feel free to listen to it if you wish.

Buddhism, I, Myself, the Now, and the Buddha

Please like it and leave a review if you can 🙂

Magic getting started

We have just now created a new getting started video, since the process of getting started has been significantly simplified. Follow it below, and get started with Magic in less than 10 minutes.

Our new Getting Started Video

Aligned incentives

I once read a story about an airliner that internally timed when takeoff started according to when all passengers were on board, and not when the plane actually started flying. I think the idea was that from the point in time that all passengers were inside of the airplane, it was no longer the employees fault if the plane become late. Then they paid bonus to their employees according to how “punctually” the plane was, and how fast the employees could fill up the plane. So basically, all employees had financial incentives towards making sure the plane would fill up as fast as possible.

The guy who wrote the story down spent 8 hours sitting inside of one of these planes before the plane took of from the runway, because the plane wasn’t allow to take of from flight control. Him and several of the other customers asked several times if they could be let of the plane, to grab some fresh air, and move around a little bit – Since they had been told it would be several hours before the actual flight would start. The cabin personal said “no”, because they didn’t want to loose their own bonus, which was due, simply because all passengers was physically sitting inside of the plane. Needless to say, but I doubt many of those passengers ever flew with that airliner again.

If your company’s incentives, or your employees incentives, are in direct opposition to your client’s needs and desires, you will probably wake up hard one of these days, realizing your clients have simply gone to the competition …

Just my 2 cents here … 😉

Modern Web application architecture

I just recently participated in a discussion at Reddit about which architecture to use when creating Web applications. My personal opinion is that when creating a Web application, is that there are no real alternatives to pure Web APIs, combined with something such as Angular, React or Vue. The reasons is that it’s the only method we know about to create a clean separation of your application’s logic and its UI.

If you create an MVC application, the view is rendered on the server side. This results in an unhealthy mixture of view and logic, tied together, making it much more difficult to do modifications to one of these parts, without affecting the other side of the equation.

As to Blazor, don’t even get me started. I am not even sure about if I want to publicly raise my opinion about it.

If you’re looking to get into Web application development today, do yourself a favour, and drop all ideas of everything that does not contain the words JSON, API and HTTP REST in them somehow – It’s simply not worth the time!

Validators, transformers and injectors

Most software developers tends to inflate the complexity of their own business logic, to the point where the cognitive context required to understanding their product, becomes so overwhelming, that maintaining their code base becomes literally impossible. When this happens, it is referred to as “the big ball of mud”.

If the GoF taught us one thing in their famous book “Design Patterns”, it was that language helps us understand and categorize problems, which again results in better structure, due to making the code more easily recognized, and possible to speak about, within a common terminology, easily understood by everyone agreeing upon the vocabulary – Hence, I propose the following language additions to our vocabulary as we create methods taking input intended to be somehow stored.

  • Validators, validates input data before the data is stored
  • Transformers, mutates data before the data is stored
  • Injectors, adds to the input data before it is being stored

Most developers have probably heard of validators. These are for instance objects that prevents us from registering at some website unless we provide a valid email address, etc. However, I don’t think anyone have proposed the other two elements previously. Hence I will explain them below.

A transformer is something that takes one of your input fields, and somehow mutates it, to become something different. The typical use case is storing a password from some website. You never want to store the password in plain text though, typically you want to hash it using for instance BlowFish or something similar. This is just one example, and there exists hundreds of other similar concepts, such as for instance always storing data as UPPER CASE or only lower case for that matter. Cleaning up sentences with correct punctuation and sentence capitalization, or making sure names are stored correctly with capital letters. The creative mind can probably come up with dozens of additional similar constructs, but they can all be categorized into the “transformer” category.

Injectors are not part of the input data, but somehow retrieved from some other source, yet still needs to be associated with the data you want to store. From my own industry, which is FinTech and trading systems, a typical example is the trading accounts. When a user registers as a trader in my system, I often want to create a trading account and associate with the user record somehow. This process is typically done by an external system, often the trading platform itself, and then as I persist the user, it becomes associated with that user. Other examples might include storing the IP address during a registration process, or using the IP address to lookup the country of origin the user is registering from, and storing its three letter abbreviated code. All of these can be referred to as “injectors”. Basically, an injectors adds data to the existing input before the object is stored.

The point of this exercise, is that once you realize that the above three simple concepts and words probably includes 95% of your existing business logic, you have a language to use as you speak about your logic, making it much easier to convey your meaning. Basically, it becomes the software development equivalent of what Domain Driven Design refers to as “bounded context”. Or, to be more specific, it becomes the bounded context for storing data from input given by another client somehow.

As you realize that these are generic constructs, you can start dividing your business logic into reusable blocks of code, where 95% of your existing business logic is replaced by three simple interfaces, with some 3-5 different implementations each.

  • IValidate (field)
  • ITransformer (field)
  • object IInjectable ()

At which point everyone can easily see what your code does, and the cognitive requirement to understanding it, is significantly reduced – Making it much more maintainable and easy to debug. In fact, one could even imagine constructs such as these.

class Client
   [Validator(Type = typeof(EmailValidator))]
   public string Username { get; set; }

   [Transformer(Type = typeof(BlowFishTransformer))]
   public Username { get; set; }

   [Injectable(Type = typeof(TradingAccountInjectable))]
   public string TradingAccount { get; set; }

Allowing you to 100% declaratively see what happens to the data by simply inspecting your model. The above of course illustrates how logic can be associated with your data, to increase data integrity, using an AOP type of syntax – While making the code 100 times more easily understood and maintainable – At which point your specialized business logic implementation is effectively reduced to ZERO lines of code!

Business logic you said? Sorry, we don’t do that here … 😉


BlowFish will inevitably at some point in your near future become the most important word in your life as a software developer. The reasons are simply because the only thing governments knows how to do, is to legislate, regulate, and restrict – And as they realize that the GDPR only addressed the tip of the iceberg, they will start digging deeper, looking for more ways to protect their constituents from other malicious activities online. At which point BlowFish will be shoved down your throat as a software vendor, either you like it or not.

BlowFish allows us to cryptographically secure our passwords, and no, any hashing algorithm does not do that – Because BlowFish have some special characteristics, which implies that when combined with individual salts, creating a rainbow dictionary attack, becomes purely mathematically impossible. The reasons is that it is slooooooooooooow! So slow in fact, that for a computer to generate trillions of BlowFish values, based upon a random guess, combined with a random generated salt, becomes theoretical impossible – Even for NSA’s and the CIA’s super computers. Which of course is its purpose.

With any other hashing algorithm, its main feature is that it’s fast. This allows a computer to generate trillions of hash values, in minutes, allowing for it to “guess” your users’ passwords, even though you have done your best to hide them as hashed values in your database. Once they have the password for your little app, regardless of what it is, ranging from “Puppy counting games website” to your “internet banking system”, they’ll also (probably) have your passwords for most other websites too – Including any public website, allowing them to impersonate you in front of your government, removing all liability from you, and completely pulverizing all responsibility from the individual, effectively resulting in Anarchy – Simply because most people use the same passwords on most of their sites.

Hence, at some point in the future, even stupid governments, which knows about as much about software development, as a kitten knows about rocket science – Will be forced to creating legislations, shoving it down software development companies throats, making them forced to implementing it. So there are no reasons to wait for it to happen. You might as well implement BlowFish today, before it becomes a problem for you …

FYI, Magic (of course) stores its passwords as BlowFish hashes, with individual salts, making brute forcing the passwords become literally impossible. Just sayin’ … 😉

How many seconds do you need to secure your app’s passwords …?