Sorting algorithms can be difficult, but I gave it a crack and here’s what I produced

I find sorting algorithms difficult. I also find recursion algorithms difficult (that’s another story). My brain isn’t really wired very well for algorithmic thinking, which is probably an odd thing for a software developer to say.

My day job today required me to write a reasonably complex sorting algorithm in JavaScript on a data set that required grouping and multiple layers of sub-sorting. Conceptually it’s actually relatively easy – as this answer on StackOverflow suggests – but reality is never that simple.

In order to focus on just the algorithm during development, I coded it in StackBlitz. Below is my running example, developed in TypeScript. All up it took me about 5 hours (including understanding the requirements, a couple of missteps, and cleaning up the code).

If the data names seem strange that’s because it’s for biological data in a web application we’re developing.

Running Example

NOTE: You can pop the editor open in a new window by selecting “Edit On StackBlitz” in the bottom-left of the inserted window.
Select the folded-page icon at the top of the left column (below the StackBlizt blue/white icon) to see the list of files.
index.ts contains the sorting code

Find top people to follow

Find the top people and organisations – the thinkers, leaders and “doers” – in areas of interest to you, and follow them.

Good people and organisations write regular blogs.

As bad as Twitter can be it’s a great place to find leaders in technology and software development. Twitter can also give you a closer to real-time flow of information and some good conversation to get you thinking.

Also, check if your favourite people are authors on Pluralsight.

“Users” are real people

And we have an ethical responsibility as software developers – and, for some, “hackers” – to consider the implications of what we create and do.

Users are people. Real people, like us, living real lives.

What we do has a real effect on people’s life. Now, and in the future.

Example: and Troy has also noted some people have committed suicide over this breach.


If you were a software developer “just writing code” and created something that, how you feel if I:

  • Collected all your data, collated it and create a “profile” of you to sell to others for the profit of others?
  • Could learn so much about you it could create a “virtual you” that over an actor that could make you say and do things you never did?
  • Allowed your identity to be stolen?
  • Allowed your most personal information to be stolen?

How would you feel?

Well, all these scenarios have happened over the last couple of years, and all thanks to just 2 reasons:

  1. Developers who did not think about the implications of what they were asked to do;
  2. Vulnerabilities in the code they wrote.

Users do stupid things

No, they don’t.

Twice today I’ve heard the exact phrase or a comment equalling it: users do stupid things.

One instance was in relation to registering scores for the CrossFit Open. The second time relating to storing passwords on Post-It Notes.

Sure, it’s easy to say the person was stupid. They should have read the instructions. They should have understood the rules. They should know better.

But let’s understand 2 things:

  1. Every single one of us is guilty of being a “stupid user”.
  2. People simply take the easiest path to completing a task. It’s not their fault the path is wrong or insecure according to someone else’s standards – they just want to complete their task and get on with the day.

So no, I don’t believe there is such a thing as a stupid user.

In every instance, it’s a case of a poorly constructed interface or system, bad policy, or lack of good tooling that allows poor users to select the wrong easy path to completion.

Write comments in your code

I recommend adding these types of comments when writing code:

  • Classes: A brief description of the class purpose.
  • Functions/methods: A brief description of what the method does. It’s also good where possible to provide descriptions of the expected parameters and return value if applicable.
  • Properties: A brief description of what the property is for.
  • Most code has some logical grouping as it flows. Add a one or 2 line comment before each section describing what’s happening.
  • If you write a complex piece of code/algorithm/fluent method chaining, add a description of what’s happening. Sometimes it’s difficult to determine what’s happening from the code alone.

Why is commenting code good?

  • Put yourself in the does of someone who has to change the code later. Comments help other developers (and often yourself) understand what is happening, and what is supposed to happen.
  • Comments are helpful in debugging errors, where the logic of the code may not match the expectations set out in the comment.
  • Comments help other developers determine if a method or class is something they can use in their own code.

Do software courses with “advanced” in the title mean we’re making the subject too complicated?

Looking over some developer blogs of Pluralsight authors I was seeing their course titles and I realised something:

When a course has “advanced” in the title does that usually mean the subject matter is more complicated than it should be?

For example, “Advanced Dependency Injection”. Surely Dependency Injection is something we want to keep simple (though to be fair I argue everything should be kept as simple as possible)?
Can’t we just wire it up then get on with the real job at hand? What make’s it so complex there must be an “advanced” component?

It leads me to wonder why we even need a sliding scale of “easy” to “advanced” topics in software development?
What causes such complexity in a subject?
Is the topic truly large and complex?
Or are we, the developers, so lazy in our approach to implementation – or teaching – that we over complicate it (almost certainly unintentionally)?