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.

DX: Developer UX

I’ve finally given it a name.

It is the consideration of UX – usability and accessibility – for software developer.

It is my passion. More to come.

As a veteran software developer who understands both how software developers think and operate, as well as the positioning of business folk, I often seen the following situations arise and the disconnect that never seems to be addressed.

This article is written for business folks who work with software developers.

When a software developer says something is “easy”.

Software development is not easy. Ever!

It is a complex, complicated, time consuming process. This is the truth.
Any developer who disagrees with it is either a savant genius (doubtful), lying (not very likely), doesn’t yet have enough experience to understand (likely), or hasn’t “stepped out of their shoes” to properly think about it (most likely).

So when a developer says something is “easy”, what they really mean is:

Based on what you’ve told me, it sounds like I need to do something I’ve previously done, or it’s something I’ve learnt about, which I’m confident I can do without a much extra learning or mental effort.
And I’m just going to ignore for now anything that can trip me up in the process.

A couple of things to know about the “common software developer” and the software development process:

• Developers are optimistic. Personally I think it’s part of the nature that makes them a developer. It’s a “can do” and “anything is solvable” attitude that drives them to find solutions and innovate.
• There many of unpredictable things that can, and quite often do, go wrong. Such as:
  • A single character typo that takes half a day or a good night’s sleep to find.
  • A software dependency changes and breaks everything.
  • What seemed like a simple approach doesn’t work.
  • Implementing it is more complex than first thought.
    There are many, many more variables and conditions that need to be considered than were evident in the initial brief.
  • After building the thing it doesn’t work as expected. Or performance is nothing like expected.

And we also have to keep in mind if the person saying “it’s easy” is also the person who has to do the actual work.
Are you asking an architect with 20 years in the industry (and who may also be out of touch with the actual tooling and development process) while a developer just out of university is the one tasked with implementation?
Conversely, are you asking junior developer without experience yet?

Finally, many developers don’t like to say “no”, disappoint a boss/senior, or appear to not know what they are doing.
Many developers also fear for the security of their jobs, and by extension saying something is “not easy” can show weakness in their ability.

It is my belief that “it’s easy” is one of the primary reasons software development projects fail, in part because the question of “how hard is it?” is also the foundation for my next point.

When a software developer gives you a time estimate.

The golden rule of software development estimation is:

Multiple by 2.5

This is not in any way a joke or exaggeration.

Software developers are optimistic, shit at estimates (see the discussion above) and, my personal belief, we very quickly learn to estimate based on what we learn the business “wants to hear” vs what we really know to be true (let’s face it, most of the time the business is going to be pushing for an externally driven deadline regardless).

I’ve been estimating for 20 years and I still regularly get it wrong. Estimation is hard. There are so many unknowns and unpredictable external influences we have to contend with.

Unless you are absolutely confident the person you ask padded the estimate, then as a business person any estimate you receive from a developer should be multiplied by 2.5 for an accurate idea of how long it will take to implement.

Now, a crucial point on this is the word “implement”, which means “the time required to spend working on the task” (i.e. working hours).
It does not mean “it will be finished in that amount of time after it is started”.
It is not a delivery time.

When working on a task, a huge chunk of software development is more than just writing new code. It is:

• Thinking.
• Scrapping or changing what’s already been built.
• Integrating into a larger project (and often having to make cascading changes across the project).
• Testing.
• Researching.
• Discussing with colleagues.

A note on “testing”: Developers will not factor in time for testing in estimates, almost guaranteed.

On top of that, anything but the smallest task cannot be completed in one sitting.
Even a task that can be finished in 4 hours will need to split split over multiple days, to take into account time to think, time to test (especially if other teams are involved), general interruptions, and meetings that come with working in a business.

One final tangential but related point is around asking for progress updates.
There are a few of things to think about when asking for an update:

• Be clear about whether you are asking “how much of the expected time is taken” vs “how much of the feature is complete“?
  Unless you ask specifically for a time based answer, assume the answer will be in terms of feature completeness and expressed as a relative value, either a percentage (e.g. 80%) or a vague “almost done”, “half way”, “only just started”.
• A percentage of feature completeness is not proportional to the time taken.
  • A task that is 80% complete does not mean “80% of the time is used”.
    Nor does it mean the remaining work should take only 25% more time (math lesson: 20% of 100% is 25% of 80%).
    Many tasks can reach 80% complete in just 20% of the estimated time (and some can take 250% of the remaining time to complete).

Above all, NEVER hold a software developer to an estimate!

It’s a well known joke in the industry, but it’s also a reality (I’ve been subjected to this many times over my career) and it is, to put it quite bluntly, a fucking toxic approach at will destroy your credibility with the very people you rely on.

Hopefully by now you realise why an estimate cannot be considered a deadline.

On the matter of estimates vs deadlines, here’s the best approach to take:

If you have a deadline that must be met, set it upfront and only use estimated for approximate planning.
Estimates are otherwise worthless in this scenario.
Instead, make a call on “feature completeness”, “quality”, resources working on the solution, budget, and what other work can be dropped.
And always assume when hitting deadlines developers are going to work at least 25% more hours than a standard work day.
(The only think more stressful to a developer than an estimate, is a deadline.)

Otherwise, if you want an estimate then treat is as a “rough idea”.
Assume the plan and schedule will change.
Don’t create any business critical plans against it.
And ensure the work is not part of something that has deadlines.

Bonus: How many hours can a software developer work behind a keyboard?

Software development is hard work.
It’s mentally and physically exhausting and requires a lot of stamina, especially over a long term, and especially of a term of sustained effort.

My rule of thumb is:

In a standard 8 hours work day, assume a maximum of 6 hours behind the keyboard.

That’s an absolute maximum. It’s not going to be every day. And that’s if you want quality work.

Remember to factor in things that take people away from the keyboard:

• Meetings
• Planning sessions (eg. at a whiteboard).
• Coffee breaks and water cooler chats (essential for workplace productivity, and often a source of ideas and inspiration).
• General break to clear the mind.

But software development is not about being behind a keyword and writing code. A huge percentage of it is thinking and learning/research.

Software development is not factory line work and cannot be thought of the same way in terms of output. It is creative and analytical.

And not every day is going to be the same.
Some days a developer will be in “flow” (a mental state when they are churning out code in a easy, satisfying way).
Some days personal life may be making them a bit flat.
Some days they will be battling technology gremlins.
Some days in their flow they will punch out a solid 10 hours of work.
The next day they’re fried and admin tasks or a bit of learning is the best you can hope for.

Software developers are people.
Not machines.
Not “resources”.
People with brains and bodies and lives like everyone else, who have the same ebbs and flows and worries and energy as everyone else.

I just posted a Twitter thread (a short rant, really) about software architecture, patterns and practices, and the “right” and “wrong” way.

You can find it at https://twitter.com/GDayJason/status/1359409433521004547.

But here it is in it’s entirety as well. Double-line spaces show the break between each Tweet.

I’m doing some .NET Core training on Pluralsight and along the way diving into REST API architecture and other related topics.

The thing that really shits be about architecture discussion and training is all the “you should do X” but no one EVER explains WHY!

If you’re going to write a document or build a training course that states a right way and wrong way, then explain why.

Why should I listen to you otherwise?

Give me pros and cons and concrete examples I can learn from. Help me “understand” to make good decisions.

But once again, I come back to a point I often make: “Most patterns and practices in software development are just MARKETING.”

They’re the opinion of one or a handful of people who decided how something should be done and wrote a book (or thesis) on it.

Oh, the ideas might have merit, but don’t been fooled by a flashy cover or title known to all.

These ideas are conceived and written by people just like you and me.

The danger we then face is new and good ideas are poo-pooed with “that’s not how it’s done according to X”.

Here’s the thing: “Today’s best practise is often tomorrow’s anti-pattern”.

Or it might still be a good practise, but other ideas have come to play as technology evolves.

Here’s the thing: “Today’s best practise is often tomorrow’s anti-pattern”.

Or it might still be a good practise, but other better practices have come to play that reflect the evolving technology.

There’s space enough for different ideas. Including ideas the CHERRY PICK from multiple practices to best fit the situation.

There’s space enough for different ideas.

Including ideas that can be picked from multiple practices to best fit the situation.

At the end of the day there is one, and only one, thing that truly matters:

The software solves a business problem.

Yes – maintenance, testing, readability, etc. But none of that matters if the product isn’t solving a problem AND being used.

But this is just my opinion.

I don’t do conference talks. I haven’t written a book.

I just have 20 years working with a lot of projects and solutions – some mine, many inherited.

And if I had a dollar for every time I saw something done the “wrong” I’d be well retired now.

And the #1 thing every single “wrong” solution I worked with did right?

It solved a real business need.

(And most developers could happily keep it running.)

I’m reminded once again, as I run the same to check and monitor data in our database:

If developers have to regularly run a query to check the same data in the database, it deserves a sysadmin page/view in a portal/dashboard/the software sitting in front of the data.

Today, someone I’ve never met, whose name I don’t know, rated and told me I’m not a good software developer.

It wasn’t someone on Twitter or social media. It wasn’t an industry expert.

No, it was feedback I received from coding challenge I did for a job application.

As a general rule I refuse all technical tests and code challenges (even if it means not being able to apply for a job).
I’m not sure why I took this challenge. I guess I let my better judgement slip.

Coding tests in job applications have their place, but having been on both sides of the table (and I’ve never made some do a test) they’re more for assessing entry level developers than people nearing 2 decades of in-the-trenches experience.

In this post I want to share my thoughts on the process I went though by using the actual test, sharing my solution and the exact feedback I gave the recruiter I went through.

I’m not name dropping the particular company that required the test. But, their requirements are in a public GitHub repository.
I don’t know the department, team or people I was applying for (there’s a warning sign for you) so I can’t name drop individuals.
I also didn’t sign a waiver with the company against sharing my experience.

To be clear: This is not an attack on any one person or the organisation. I’ve been through almost exactly this instance multiple other times in the past.
This instance simply provides a perfect example to share.

One final thing: this was for just a 4 month contact. I’ve done a lot of contracting over the years and have never been asked to perform a code challenge.

This whole situation says a number of things to me about:

1. The persona assessing me (I can infer their experience as well as their personal motivations).
2. What the organisation is potentially looking for,
3. Laziness in the organisation’s recruitment process. Say what you want about “efficiency” in hiring, but this speaks to laziness.
4. Recruiters are still not doing their job in terms of understanding their industry; understanding the people they represent; educating their hiring clients.

The Code Challenge Requirements

The complete requirements of the code challenge were provided via a link to a public GitHub repository at https://github.com/medibank-digital/coding. I’ve also included it below.

# Medibank Coding Challenge

## Overview

A web service has been setup at the following URL: 
-	https://gist.githubusercontent.com/medibank-digital/a1fc81a93200a7b9d5f8b7eae0fac6f8/raw/de10a4fcf717e6c431e88c965072c784808fd6b2/people.json

## Requirements
You need to:
- Write some code to consume the json hosted on the above web service.
- Output a list of all the cats in alphabetical order under a heading of the gender of their owner.
- Output must be presentable on a web browser.
- Submissions will only be accepted via GitHub or Bitbucket.

Please note:
- It can be written in any language you like.
- Use any libraries/frameworks/SDKs you choose.
- Use industry best practices.
- Use the code to showcase your skill and what you value in a software application.

## Example

```
Male

Angel
Molly
Tigger


Female

Gizmo
Jasper
Notes

```

2 things immediately came to mind:

1. “Use industry best practices” is a MASSIVE alarm bell for me.
   For 2 reasons:
   a) there is no such thing as “industry best practice” in software development. Developers like to use that phrase but in reality it doesn’t exist and we all know it.
   b) What it really says is “some person wants you to write the specific style of code and architecture that they think is best, and we’re not going to tell you what it is”.
2. There’s no guidance in terms of what they are looking for.
   Do I need to create a full app?
   Can I create just a helper?
   Are there code standards they’re looking for (and what are they)?
   Are they interested in UI design?
   What if I’ve written it in a language they don’t use?
   What if I wrote it in a language they couldn’t compile and run (they did say “It can be written in any language you like”)?
   Ultimately: how does this represent what they are looking for in the work the candidate will do on the job?
   And what the fuck is the actual goal of this test anyway?

The people.json file contained the following:

[
  {
    "name": "Bob",
    "gender": "Male",
    "age": 23,
    "pets": [{"name": "Garfield", "type": "Cat"}, {"name": "Fido", "type": "Dog"}]
  },
  {"name": "Jennifer", "gender": "Female", "age": 18, "pets": [{"name": "Garfield", "type": "Cat"}]},
  {"name": "Steve", "gender": "Male", "age": 45, "pets": null},
  {
    "name": "Fred",
    "gender": "Male",
    "age": 40,
    "pets": [
      {"name": "Tom", "type": "Cat"},
      {"name": "Max", "type": "Cat"},
      {"name": "Sam", "type": "Dog"},
      {"name": "Jim", "type": "Cat"}
    ]
  },
  {"name": "Samantha", "gender": "Female", "age": 40, "pets": [{"name": "Tabby", "type": "Cat"}]},
  {
    "name": "Alice",
    "gender": "Female",
    "age": 64,
    "pets": [{"name": "Simba", "type": "Cat"}, {"name": "Nemo", "type": "Fish"}]
  }
]

My Solution

I completed my solution in using React (it was good to practice for something I’m currently learning) and I published it to a public GitHub repository at https://github.com/jsnelders/medibank-coding-challenge.

All up it took me about 4-ish hours. I actually started it while watching TV the night I received the request and finished it the next morning between other tasks. In all I think it was about 4 hours of my time.

Now, that may seem like a lot of time for a simple task like this, and I’m sure there are better programmers than me that can spit it out in half the time or less, but consider the following:

1. I had to guess at the “hidden” agenda and requirements they were assessing me against. So, I have to spend a bit of time trying to get inside their heads.
2. It’s a complete React app. Even with create-react-app it still takes time to build one.
3. I’m new to React and only just [finally] getting into ES2015, so I spent some time with reference material open.
4. I’ve never worked with the Jest test framework.
5. I’m an OG developer trying to keep up with “modern” ways of development. In this case, converting my old school (by which I mean more than 5 years) approach to programming JavaScript and use ES2015 approaches. Which, is no more “correct” or “better” than the old way.

The Feedback

The feedback I received via the recruiter is exactly as follows:

Here is some further feedback for you.

Positive

• • Used ES6 filter method for sorting list
  • Used config file for url

Negative

• • Didn’t break up React components (one for entire app)
  • Very long methods instead of breaking logic up into smaller chunks
  • Could have used constants for JSON response types instead of repeating string literals throughout class
  • Many of the ‘let’s could have been ‘const’
  • Had a unit test but when try to execute it had a syntax error, so couldn’t execute
  • Inconsistent and Unconventional naming conventions (didn’t use service, utility, some declared with lower case others, while other upper case)

To which I replied:

And my responses to the Positive and Negative Feedback:

Positive

• • Used ES6 filter method for sorting list [I only did this because I exepcted that’s what they were looking for. A loop is still a perfectly reasonable option too.]
  • Used config file for url

Negative

• • Didn’t break up React components (one for entire app) [Not required on an application of suck low complexity. This should have been stated as something they were looking for.]
  • Very long methods instead of breaking logic up into smaller chunks [Which method are they referring to. I’ve checked all my code and I just can’t see a function I would think necessitates chunking or shortening.]
  • Could have used constants for JSON response types instead of repeating string literals throughout class [Not even sure exactly which code this referring to? If I was to guess, then I’d say I understand their thinking but don’t think it’s reasonable without pre-defining it as a coding standard they use (what I did was “not” unreasonable and would cause not maintenance problems).]
  • Many of the ‘let’s could have been ‘const’ [I’ll concede this “to a very small degree”, bit this is really low-level nitpicking. Both are perfectly valid, and no dev who’s been working front-end web more than 5 years would even consider this a problem.]
  • Had a unit test but when try to execute it had a syntax error, so couldn’t execute [Fair enough. I must have renamed a function and not re-run the test. And technically, it’s not a “synatx” error.]
  • Inconsistent and Unconventional naming conventions (didn’t use service, utility, some declared with lower case others, while other upper case) [I totally disagree (and just saying this one line is not enough feedback). In fact, I used conventions I’ve just learnt that are taught by one of the industry leading teachers of React! And they didn’t set any expected conventions (there is no single one in our industry).]

My Thoughts

I’m an very experienced developer. No boasting – that’s just how it is. Almost 20 years in the industry. Many roles. Over 8 languages and variants. I’ve worked with countless different tools, technologies, platforms, patterns, and code from probably hundreds of other developers.

I’m also still a programming software developer after almost 2 decades on the jobs. The number of people with more than 15 years in the industry who can say that is a dwindling number.
I’ve done everything from code Excel to website interfaces, setup and manage deployments to debug production issues, hire and manage staff to run a business.

What that means is I’ve seen and experienced a lot, in an industry that has no certification and governing bodies, and the only thing I can tell you is: there’s no right or wrong way to do things – just someone’s opinion.

All that said, I’m an “average” programmer.I know that. I get shit done and solve business problems – that’s my job. I’ve been through the school of hard knocks more than once in life. And this not the first time I’ve received feedback like this on a coding challenge (most times I never received feedback).

Even so, it’s still a kick to the stomach to be criticised like this, from someone I’ve never met, without a chance for discussion, which is what you would reasonably expect in an actual workplace.

I’ve had exactly one decent technical test in my career as an interviewee. It was about 10-15 lines of  JavaScript printed on a piece of paper. Handed to me during the interview and I was asked to describe how it worked. Speak it out aloud. No right or wrong answers. And we discussed it as we went. 5 minutes taking across a table. I missed something and we discussed it.

That’s how you test someone.

I’ve been thinking about code architecture in consumer grade software solutions and what I believe matters most.

As a result I came up with:

SMaRT Code Architecture

Which stands for Simple. Maintainable. Readable. Testable.

Simple: It’s easy to find (discover), understand and trace code during debugging and or enhancements. The simplest code is no code. Not always feasible. But reducing layers and reducing decomposition can help.

Maintainable: Developers should be able to (and not scared to) fix bugs and introduce enhancements. An unmaintained system suffers from entropy and can become “toxic” within the larger ecosystem.

Readable: Code is written for people to read, not computers. Everyone should be able to easily read and understand the code you wrote yesterday – from a 1st year novice to a 20 year veteran. Fancy or shorthand code works against the next person. Use white space. Write comments to assist in understanding intent. Old school statements are still valid.

Testable: Developers need to easily test their changes. If they cannot there is a lower likelihood of changes being made, and a higher chance of errors when they are.

Notice I haven’t mentioned anything about patterns or practices, APIs or languages features. Those are implementation details – how you implement as opposed to what is important.

What is important is code that makes it easy for people in the future to learn and touch the system.

How easy is it to learn React and practise at the same time?

1. Start with this course on Pluralsight (https://app.pluralsight.com/library/courses/react-fundamentals-update/table-of-contents).
   Can’t afford Pluralsight (it is expensive for many developers)? You should be able to find something on freeCodeCamp or YouTube (search for something like “React fundamentals or “Learn React”).
2. Create a GitHub account (every developer should have one for their work and portfolio).
3. Create an account on StackBlitz – a Visual Studio Code “in the browser” development environment – and link it to your GitHub account so you can start committing (saving) your work as you go.

See the project I’m building as I learn React at https://stackblitz.com/edit/test-react-playground/ (GitHub repo https://github.com/jsnelders/test-react-playground).

I’m putting together a new website today and implemented the classic web developer test: I set a background color of red on a div to check my build system was refreshing.

It worked. But with an odd side effect.

The red I saw looked pink on one screen (my laptop screen, in fact) and different shades of red-ish on my other 2 screens.

I have a 3-display setup at home – my laptop screen with 2 connected monitors on either side. I also run an application called F.lux all the time which essentially sets a night light (reduces blue light and runs a softer colour). But even with that turned off I still had colour variations across all three screens.

Unfortunately I couldn’t take a good enough picture to show the contrast clearly, but hopefully the following 2 photos give some idea:

Regardless, the moral of this story is:

No matter how precisely you design the colour of software or websites to look, there is no guarantee users will see what you expect them to see.

Keep your designs simple, focus on contrast and hope for the best.

And remember, there’s always grey scale to fall back on.