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 life is never that simple.

In order to focus on just the algorithm during development, I coded it in StackBlitz, a relatively new online IDE/sandpit for JavaScript based projects.
Below is my running example, developed with TypeScript. All up it took me about 6 hours (including understanding the requirements, a couple of missteps, and cleaning up the code, then refactoring into modules/files).

If the data names seem strange that’s because it’s for biological data. I’ve left out all the unnecessary fields and focused purely on the fields that need sorting (except for the ID and Rnd fields).

I’ve added the sorting requirements into the code, but here’s what we needed (exactly as received):

  • Group by DSA Category (Specific first, Potential next)
  • Then Group by Locus, get the highest MFI for each locus, and sort locus by highest MFI to lowest
  • Then sort antibody (the same antibody should be grouped together) by MFI highest to lowest.
    [JS: Another way of looking at it: Group by locus, and find the highest MFI for each locus. Then within each locus group by antibody. Then sort antibody within each locus by MFI, highest to lowest. Then step back up to locus and based on the highest MFI found within the locus, sort each locus “group” by that MFI, from highest to lowest.]
  • Then sample date


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.
The code is split over multiple .ts (TypeScript) files, and index.ts is the starting point.

If you’re using Internet Explorer or there’s just a black window below, here’s the link to the code (and I suggest using a “modern” browser – Chrome and Edge both work):

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 heard this exact phrase or a comment equaling 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)?