The state of software development accreditation (and why technical tests are needed)

The need for technical tests when hiring software developers (of mid-junior experience) is a sign of 2 things:

1) The industry is not regulated and does not have the backing of professional certification authorities to enter the industry, which would largely negate the need for the rudimentary testing we see across the board today.

2) Our education institutions (e.g. universities) are failing when their name and reputation is not enough to get the “average” candidate through the door without the need for additional testing (not talking about the FAANGs of the world).

(Speaking primarily from observation in Australia.)

Do we need regulation and accredited certification in the software industry? Hell yeah!

The software industry might only be a a handful of decades old at this point, but the exponential impact software developers have on the world means we can’t wait the 500 years other accredited industries have had to see people requiring accreditation before they can practise the craft.

Software Developer Priorities

Reading threads on Twitter, it’s a telling sign that almost all discussions from software developers/engineers I follow revolve around code, software architecture and technical stuff.

Very few think to mention customers or the greater impact on people from what do.

My priorities are:
1) People. Our customers.
2) Security and data privacy.
3) People. Our customers.
4) Code.

(The only reason security isn’t #1 is because without people, security isn’t a concern in the first place.)

But to be clear, I do spend a hefty amount of time thinking about code and software architecture. They’re just not my priority.

Dark Matter Software Developers

Let’s not forget, for every software developer who is active on social media, blogging or the speaking circuit – there are at least 100,000 developers working 9-to-5 jobs and keeping the world running. People you’ve never heard of and don’t have open source projects.

These people are the backbone of our economy.
They do their best while living full, balanced lives.
And a lot of them are as wise, if not wiser, than the big names and voices in our industry.

Let’s also consider: there are no Einstein’s in software development yet – only people who have written books, made their name on social media, or got lucky building a publicised software company.

Software development is an industry founded primarily on collaboration, incremental development, and more failure than success.

So, remember the quiet person who does their contractual hours every week and contributes to a product that affects thousands of people.

These are the people we must celebrate.

“Doing Cloud Software” – Since Before It Was Fashionable

I’ve been doing “cloud software” since 2007 – the year I registered my first domain.

I built and hosted my first website on https://discountasp.net/.
And I’ve since built WordPress websites that run in cPanel on system managed by https://www.digitalpacific.com.au/.

I’ve never had to create a network or a virtual machine.
Every software product I’ve designed and build has run on platforms other people mange, and service I can just deploy into.

DiscountASP.net gave me an ASP.NET platform and SQL Server.
Digital Pacific gave me PHP, WordPress and MySQL.

I never had to worry about infrastructure – just my application code. The rest was APIs.

Since then I’ve moved to Microsoft Azure and used only their serverless offerings – what is now Azure App Services, Azure SQL, Functions, Table Storage, Blog Storage and now Cosmos DB.
All “API” based.

I’ve never had to worry about infrastructure or anything I couldn’t access and control via a dashboard.

And to be honest, any time someone talks about Docker or Kubernetes, I can’t help but think “that sounds like too much work”.

.NET Linq .Select() often means “project”

I’m old school so I haven’t worked much with Linq (Language-Integrated Query (LINQ) (C#) | Microsoft Docs) – beyond the absolute basics – until this year.

One of the methods I’ve needed to use quite a bit is the Enumerable.Select Method. Which has been hard to wrap my head around until I realised something:

The method name doesn’t fit my mental model.

And the reason is in the first line on the Microsoft documentation page:

Projects each element of a sequence into a new form.

The key word being “projects” (as in, a “projection”). Which in cody-cody speak means “take the data I’m giving it and turn it into something else”.

See, when I see “select” I think of SQL “SELECT”, and in most cases we’re just picking data columns you want to return. Though, to be far, now I think about it you can also “project” with it.

But still, when I think “select” in the context of data it’s “you’re going to give me some data, and I’m going to pick the bits I want”. Whereas with “project” – particular in the context of the code I’m working with – means we’re “transforming” the data and often pulling in other data peripherally linked to it (in a way acting as a join). This is often doing by calling another method that takes the current item in the data and does something with it – e.g. used some value from it to lookup or generate other data structures.

The Microsoft docs page Projection Operations (C#) | Microsoft Docs start with the following which explains it well:

Projection refers to the operation of transforming an object into a new form that often consists only of those properties that will be subsequently used. By using projection, you can construct a new type that is built from each object. You can project a property and perform a mathematical function on it. You can also project the original object without changing it.

So what I need to do in a lot of cases for the code I’m dealing with is mentally swap .Select( x => x. ... ) for .Project( x => x. ... ) and it makes much more sense.

My “Days in Each Month” Mnemonic

The “well known” mnemonic to remember the number of days in each month is:

Thirty days hath September,
April, June, and November,
All the rest have thirty-one,
But February’s twenty-eight,
The leap year, which comes once in four,
Gives February one day more.

But I have a shit memory, especially for nouns, so after 40 years in this world I still don’t remember it. Fuck it, I don’t even try.

But I have another mnemonic I made up many years ago that’s much shorter:

4, 6, 9, 11 have 30.

Yeah, it’s that simple.

So, here’s how it works for me.

  1. February is easy pickings to remember. I know it has 28 days, and 29 in a leap year. I’m not going to forget that. So I basically ignore it because it’s easy.
  2. “30” means 30 days. Therefore, all the rest have 31 days.
  3. “4, 6, 9, 11” are the numbers of the months with 30 days (April, June, September and November).

The thing about 4, 6, 9, 11 is:
4 + 6 = 10.
9 + 11 = 20.
Both are divisible by 10. Which I easily remember. (I’m probably a bit better with numbers and number patterns).
So that makes the first pair (4 and 6) and the second pair (9 and 11) easy to remember for me.

But this is a very personal thing.
The numbers and the divisions and the bits I can remember… they all work together in my brain.

It’s not for everyone. But if you have trouble remembering the days in each month then maybe this will help you trigger a way to remember something that is personal to you.

And that’s all it needs to be.
You don’t need to remember the common mnemonic at the top.
You just need to find something that works for you.
That’s what I did (and created).

Presumptions vs Questions

I’m re-watching “Godzilla: King of the Monsters” and (spoiler) came to the scene with the sunken city.

Having not thought about it before I searched “godzilla king of the monsters is that atlantis”.

And then I realised my mistake.
I started with a presumption rather than a question.

What I should have – and subsequently did – search is “what is the sunken city in godzilla king of the monsters”.

This highlights what I believe most of us to a lot of the time: start with a presumption before we ask a question.
In other words: it’s a leading question, looking for a response that supports a preconceived position.

True discovery comes from asking questions without any presumption.