Blank slate

I’m a fan of the original Sherlock Holmes books, and there are a few things in them that talk about an enlightenment way of thinking that’s useful for a developer when gathering requirements (whether tomes, user stories, backlog ideas,etc), writing code or approaching debugging.

Today I want to talk a bit about A Study in Scarlet, and the early conversations between Holmes and Watson before their first case together, because they capture the essence of his enlightenment thinking very well.

Ignore Irrelevant detail

Watson tells Holmes that the sun rotates around the earth, as he is surprised that an educated man does not know this. In reply, Holmes says,
“That’s very interesting, I will now do my best to forget it”

It’s not an important factor in any of his cases, it doesn’t affect his work, so it’s not a fact he needs to record. He accepts it but has no way to act on that information, so he dismisses it.

It’s something that is often hard to do in requirements gathering and may need to be done retrospectively after you find out whether Andy from finance’s love for Richard Branson is just infatuation, or it means that every call to action across your site will need to be red.

It’s also something to apply more generally, choose what to ignore, don’t learn every new JS framework. Don’t expect to be an expert in everything. Be content with being T-shaped, and become an expert in solving problems and focusing on the right details.

The Book of Life

” it attempted to show how much an observant man might learn by an accurate and systematic examination of all that came in his way.”

The truth is never simple. Whatever you build will be part of an ecosystem comprised of other software, of manual processes, of fallible humans, and the winds of fate.

Gather whatever information you can, in whatever detail you can. Organise it and understand the bigger context.

The Phoenix Project has a great understanding of this in the discussion of the SOX-404 audit, where the IT department are busy worrying about controls on software without understanding the manual processes surrounding the software and how that fits into the compliance picture.

Speculation

On their journey to their first case together, Watson is keen to speculate about the motives and means that led to the crime, extrapolating from what little information they got from the initial introduction.

Holmes quickly and sternly cut Watson off from that line of thinking. He was clear that he would also base hypotheses on the causes and consequences once he had evidence before him to narrow down the possibilities, removing the impossible.

Speculate make hypotheses on why the system failed, on what will improve sales, on what the performance bottleneck is really going to be. Without data or a way to test them, they are useless for reaching understanding. Sometimes the beauty of a forest can only be appreciated by the birds.

Remove your preconceptions and bias from judgement by understanding what they are. Follow the data instead of your gut.

Advertisement

Inclusion is not a zero sum game

Look around your office. How many people look like you? How does that compare to the people you saw on your commute, or in the supermarket? How does that compare to your users? Do you even know?

Are you making space?

How many people are struggling with mental illness? How many have accessibility challenges? How many are white, straight, cis-gender, able bodied men?

Is there a mismatch? And if so, what are you doing to change it? Are your job adverts inclusive and on inclusive sites? (hint: look at the StackOverflow developer survey before posting your job there) Do you have a network outside work that you can tap into to find new candidates?

Are you creating a safe space for everyone? Are company events open to new parents, to non-drinkers, to vegans, to women? Do people have to out themselves to attend a family day, or to avoid travel to a certain customer site? Do you support staff who need to transition? Staff who need quiet spaces? Staff who are fasting, or need non-Christian holidays?

Can your staff find somewhere to learn to sign? Or to write simplified for language learners, for those who have struggled to attain or retain language?

Which three of these questions are the most important to achieve for you this year? And how will you do it?

If you need somewhere to start, have a look at Inclusive 101 from the Microsoft Inclusive Design Toolkit, and ask yourself if that’s you, or pick an episode from the Cause a Scene podcast and listen, especially if it makes you uncomfortable.

Things I don’t know as of 2018

At the end of last year, Dan Abramov talked about the things he doesn’t know. It’s a useful framework to reflect, and as a privileged, experienced developer, I am comfortable talking about this, in the hope it might help others understand that experienced developers don’t know everything.

I’ll echo what he says about Imposter Syndrome and Dunning-Kruger and how it absolutely sucks to see truly smart developers I know, or that I follow, having to constantly prove their credentials just because they’re not cis, straight, able-bodied white men. If I’m in a position to support you or amplify you, I will try to do so. Your experience is definitely a thing I don’t know, but I can listen.

I covered a few things I know enough to be confident in for my 2018 in Review post. I’ve had to care about DevOps and containers and pipelines because they solved real problems my team was having. I love graphics because trigonometry and fractals are why I got into programming, but I work in the network, looking at architecture, security, interfaces and data. That leaves a big wide world out there, and this doesn’t include the unknown unknowns.

Ruby

I’ve tried to get into it a few times, but it still just looks like old-school Perl to me. Lots of punctuation occasionally interrupted by domain language. This actually sounds like a good idea to me – an almost complete separation of concerns – but I keep finding the learning curve too steep and so I retreat back to Python and C#.

CSS

I’ve been building websites since Mosaic was a browser. I can style things with CSS. It’s not hard to put red text on a green background (you monster), or fix a navigation bar to the top of the screen, but look at the fancy grid layouts, or parallax scrolling effects, or CSS icons, and I couldn’t tell you where to start. I don’t know how to unit test it, so my tools don’t work here. Just as well I work with some very smart CSS developers.

Markdown

I use Markdown a lot. For README, for Architecture Decisions, and for drafting blog posts, but I always need to google how to insert a link, or a table, or an image. And I feel like an idiot each time.

gulp, npm and webpack

I know these are essential tools when I’m building React. I know they turn my code into something the the browser runs. I know how dependency management works (I can bore you about HORN over a drink if you like), but I’ve only ever used these JavaScript tools preconfigured in a template or an existing codebase, so I could not create a JS or TypeScript build pipeline from scratch, or fix a broken one.

I really couldn’t tell you anything intelligent about how those fit into the ecosystem alongside Grunt, Yarn, bower, sass, scss or anything else. So long as I can write a script to install and run them, I’m happy not to have to dig into them. All I care about is if it runs and if the dependencies are secure.

I suspect I’ll need to learn more about these tools this year though.

You don’t need to know everything

You’ll have your resolutions to learn more, whether weekly or yearly. There’s more to learn than you will ever get the time to – that’s why we work in terms. Pick one thing to learn next because it’s important to you, because it’s interesting, because your project requires it, or because thats where the money is. Forget the rest until you’re over the Dunning-Kruger curve and you know enough about that new thing to see all the possible next things to learn.

I’d rather be proved wrong than miss the chance to improve

One of my favourite books is Nightfall by Isaac Asimov and Robert Silverberg. The setup for the sorry is an old astronomy professor who has won his planet’s equivalent of the Nobel Prize for proving that the six suns in his solar system would never set on his planet at the same time. And night couldn’t fall.

And then his students did some calculations and realized he was wrong, and for a time every few thousand years there would be night.

They didn’t want to tell him thinking it would ruin his life’s work and leave him feeling dejected and worthless.

He got angry with them because he didn’t want to miss the chance to learn something new, and the thrill of discovery had the opposite effect to what the students expected and renewed his enthusiasm in the subject.

Renewed enthusiasm

I’m not a Nobel winner by a long shot, but the professor’s attitude embodies the way I want to work. Doing the same thing and thinking there’s nothing left to learn would demotivate me.

I love mentoring because I love learning.

When I build a team, I want people who aren’t afraid to tell me I’m wrong, when I am, because that’s what makes the team stronger. I know not everyone is confident at this at first but if I can find people who are confident in their opinions, my job is to nurture that.

If I’m not being challenged, I’m not learning. I know my experience has helped me get where I am, but I need to know where me and my team are going.

Tasks for you

If you are a leader or a mentor, embrace the opportunity to learn that you get from being wrong. Be vulnerable, sometimes, so that everyone knows it’s ok to be wrong, if you acknowledge it and make amends. Keep learning.

If you’re not, embrace your mistakes. (Link – my mistake) Next time you find yourself in that position, you’ll call it experience. Learn by doing as well as by reading. The most interesting challenges you’ll face won’t have a manual. Keep learning.

Don’t let your career go dark.

Debugging Asp.Net Core 2 apps in Azure

I’ve been getting under the skin of Asp.Net Core 2 following a failed experiment with Asp.Net Core v1. I certainly found .Net standard and the associated framework support to be very welcome, and unlike my previous project we didn’t need to support GDI or SignalR libraries, so it’s much more in the Core sweet spot.

I’ll talk about the project and the technologies involved in some follow up posts, so if you’ve got any real-world questions on Asp.Net core, React/Redux with Typescript, or CosmosDb in C#. let me know and I’ll try and address them as I get to those technologies.

For now, though, I want to start with the basics. Asp.Net core on Azure works great, mostly, but if something goes wrong in Startup.cs, there’s no Application Insights, a generic 502.5 IIS error – which just means it can’t talk to Kestrel, and no web logs to help you. So before you deploy to Azure, do yourself a favour and add the following to web.config so you’ve got logs to help you.

<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="dotnet" arguments=".\web.api.dll" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="true" />
</system.webServer>

That way, if you do see a 502.5 error on your site, you can jump into Kudu and start reading the logs. They can grow quite quickly, depending on your web app lifecycle settings, so you may benefit from a regular cleanout of your logs folder.

If the logs still aren’t helping, or you don’t understand what you’re seeing, there’s a nice Asp.Net core 2 troubleshooting guide over at MSDN, but not all of it applies to Azure.

Ddd.scot, diversity, and your career

I had a great day at DDD Scotland, thanks to everyone who came along for the discussions. Apart from the panel sessions I chaired and participated in, Joe Wright ran a great mob programming session, Gary Fleming led a lean coffee session, and we had a couple of great lightning talks about recruitment at Skyscanner and Becoming a Technical Lead From Tugberk Ugurlu of Redgrave.

There were a few recurring themes that I want to highlight.

Diversity

This was a strong recurrent theme throughout the sessions in the community room. Whilst the focus was on gender due mostly to the makeup of the attendees, a few people pointed out the need to respect diversity for LGBT, age (graduates don’t have 5 years experience), family circumstances (single parents and others don’t have time in the evenings to do coding interviews), dyslexia and autism. To which I’d also add physical disabilities, skin colour, religion, any of which can and have been used intentionally or otherwise to limit the pool of candidates brought to interview, or created a hostile environment once in the job.

If you want to hire on merit, don’t just give the job to the white guy because he’s “a culture fit” and recognise that your recruitment may be biased. When I put an ad on Stackoverflow, all the replies were men, but working with a couple of recruiters we found a better mix of candidates, including the woman who we ended up hiring.

No problem at all, great to hear that people are keen to learn about it! The link for the next WiTS event is here. It would be great to see more of you there! https://t.co/BJvYmdNmbO #DDDScotland

— Becca Liddle 🏴󠁧󠁢󠁳󠁣󠁴󠁿 (@The_Liddler) February 10, 2018

Job hunting and moving on in your career

There was a scary graph that suggests that computer scientists are less employable that other graduates, and yet of all the STEM subjects, there are more vacancies in software (where the stem jobs are ).

Computer Science graduates can't get jobs, but employers are desperately looking for developers. What's causing the gap?

Trying to find answers at @dddscot #dddScotland pic.twitter.com/W498p0DNgy

— craignicol (@craignicol) February 10, 2018

The job market is broken. There’s a lot of smart people out there, and for my last 2 jobs I had no experience in one of the key technologies they were advertising for, so the job adverts in many ways are meaningless. I want to work with people who have the skills to evaluate the next JavaScript framework, not 10 years experience in Vue. Nothing I work on today existed when I graduated. No ASP.NET MVC, no REST, JavaScript was for image rollovers, no Swift, no Xamarin. But job adverts don’t care about ability to learn. They’re a checklist.

I know recruitment agents get a bad reputation, and for some it’s well deserved, but a good one will help you get past the keyword gate, because they can sell you on your potential. If a company isn’t interested in your potential, choose another one. If you don’t want to deal with an agent, you need to be bold, demonstrate what you can for the requirements, and find examples to help them see that you can learn the rest quickly.

But have examples. You don’t want to be the clueless braggard who can’t even FizzBuzz.

Culture of learning, and mentorship

If you want to continue to be successful, you need to learn. Some of it you can do on your own, some you’ll need help with. If you’re working for the right company, they’ll provide you with a mentor, but even if they do, it’s worth finding others to help, whether it’s a formal process, or just someone to discuss if all companies make you deal with that stressful thing that’s getting you down.

Write a blog, volunteer for projects outside your comfort zone that help you improve those skills you’re lacking. Seek feedback. Accept that you won’t know everything and the learning experience is littered with failures. Learn by doing. Pair, mob, spike ideas.

When you’re tired of learning, find a new job.

New Job : Welcome to Screenmedia

Following my request across my network looking for a new job, I started at Screenmedia 3 weeks ago. For those who don’t know, it’s a digital design practice, which means I’m back to consulting, and I get to work with a lot of smart people, covering technology and design. I’m a Technical Architect in the integrations team, so that’s APIs, voice assistants, serverless, analytics, so should be a good wee adventure. I’ve got a few thoughts on the job hunt which I’m sure will come up at ddd.scot and future blog posts. But if you’re currently looking, we’re hiring. If you’ve got any burning career questions, the DDD Scotland panel survey is still open.

I’ve been working on lots of interesting projects already, so groking multiple domains, sometimes multiple for the same customer, Checking the checklists, and reviewing the onboarding process. Sometimes the best change is the one that lets you re-evaluate what you think you know.

 

 

The first rule of dog training

(EDIT : whilst the below line is an old joke, part of putting information out in public is making sure your facts are correct. So, for the dog trainers out there, as Christiaan Baes  🇧🇪‏ @chrissie1 points out, the first rule is Be Consistent, which means I can’t break this URL, but I will leave this note in place.)

The first rule of dog training is : know more than the dog.

If you pass that level, you’re ready to give a talk. Have you used node.js on a real project, or evaluated it properly against another framework? Have you failed badly on a project that would serve as a warning to others? Did you learn something important from your mentor or boss that they’re happy for you to share? What do you know now that you wish someone had told you last year?

When I first gave a talk in public, I was very nervous. I still get that way.

My first talk wasn’t an original idea. At the first DDD Scotland, I saw Ben Hall talking about Red, Green, Refactor and took the ideas away to try it properly, without fully understanding it (sorry, Ben). The following year, at the next DDD Scotland, I did a live coding session entitled “TDD? I don’t have time” that revisited the highlights of that talk, then filled in some of the lessons I learned from applying it. There was a bigger audience, and lots of fresh faces who found the idea interesting, but I didn’t plan it enough and it was very rough.

I started giving talks as a way to improve my communication skills. And on my first attempt, I failed badly. And I had to make the choice. Do I write it off, and retreat, or do I keep doing it so I can learn to do it better? It was a talk about agile principles, so I had to take the latter route.

So I did some user group talks, 20 minutes, instead of an hour. Some pikka machu talks, 6 minutes. I’ve since done workshops and guided conversations, where I let other people talk. I’ve paired with others to talk. I’ve talked about technology, people, other talks I’ve seen and the near future. I learned some tricks along the way, but Scott Hanselman (check out the related links too) and Christos Matskas summarise them much better than I could.

There are good reasons to speak at user group events, or conferences, or in your office. Don’t be afraid of being noticed. And if you want any more advice or encouragement, leave a comment or find me on Twitter or LinkedIn.

And don’t forget, DDD Scotland is back. Submit.

User Experience : A quick introduction for developers

The following is an internal summary I wrote for a team that no longer exists, summarising a number of references from UXScotland, various book and blog posts. It extends the thoughts from my Pecha Kucha talk. For more details, please refer to the links throughout and the references at the bottom. The context here is consulting and long-term B2B projects, but some of these discussions are more widely relevant.

User Experience : Project considerations

User experience is about making sure we are solving the right problems in the right way. It is the intersection of design, users, and context. Context here is a combination of one or more of the device in use, the user’s location, any social cues such as nearby friends, and anything else that may be available from sensors or historical information.

In many cases, the requirements we have are assumptions (e.g. what users want is Facebook integration). Where the benefits of a requirement are unclear, we should treat it as an assumption to be tested. Embrace data, and analyse it.

At the requirements stage, we need to make sure we are solving the right problem (pretotyping : “building the right *it*”), and that our chosen design helps the user to solve the problem without frustration (i.e. prototyping the design, rather than the implementation, with wireframes/sketches).

In user testing, particularly in an agile development, we can refine those ideas by seeing how well the implementation solves the problem, by testing with users. We can also test deployed code by analysing heat maps and http logs to see what users are doing to inform further tests and the assumptions that feed into further design cycles.

In a Lean/Agile project, we need to be explicit about our assumptions about the user and test them at every stage of the development to ensure that we always meet user needs.

How does UX fit in our process?

Stakeholders

A system that supports user’s need effectively will need to understand that the user is a Stakeholder in the process. Whilst the users themselves may not be directly involved in the generation or review of design artefacts, there should be a user representative, either a super-user on the customer side, or a 3rd party researcher who has determined user needs, and has authority to verify any proposed solution and high-level requirements against those needs.

Functional Requirements

Personas / Typical Users

A persona is an abstraction of a system user. In a simple system, there may be only one type of user, but more sophisticated systems will typically have users and administrators, and may have multiple classes of each. A persona is defined to encapsulate the types of tasks a specific user may wish to perform, and any limitations that may be imposed (for example, administrators may be able to install specific browsers or client software, but members of the public using the system must be supported across multiple browsers at multiple screen sizes).

User Journeys

Each persona will have one or more tasks they wish to perform in the system. A User Journey describes the tasks as a series of steps that a specific persona will follow in order to achieve that task.

Consider the tasks that a user wants to perform. See also BDD – design from user in.

E.g.

User wants to process a case:

• User logs in to the system
• User selects case from their task list
• User reviews latest document
• User finds agent for case, and calls to discuss
• User adds comments to case
• User saves case and returns to their task list

This process may identify a new use case (“Display task list”), and specific actions that need to be defined within a use case (“Display latest document” and “Display agent contact details”)

The User Journeys provide the context between the Stakeholders (and User Types therein) and the Use Cases. Each User Journey will link to one or more Use Cases, but some Use Cases may not have an associated User Journey (nightly payment processing, for example).

User feedback

If the solution is replacing or improving an existing system, the best source of information on the current system are the users. The requirements capture process should take into account both the tasks that the users perform and gather feedback on any areas of frustration. The prioritization exercise should consider these improvements as well as new functionality.

Testing

As well as testing the Use Cases for functional acceptance, the FAT/UAT process should also test that the final system supports the User Journeys defined up front.

On-going support

Where projects have regular support meetings, the input of users has been valuable in identifying problems areas and possible changes. When on-going service delivery contracts are defined, SDMs should consider whether ongoing user feedback is appropriate as part of the planning and scoping of releases within that framework.

Questions to ask

• Have the requirements been tested on users? If not, why not? (Are these the right requirements?)
• Will users be given the opportunity to provide feedback on these through the development? (And if so, how, when and where?)
• What user outcomes are we trying to achieve with the release? These may not be requirements that we put a cost on, but an expectation that we can measure against to show improvement – we would need to communicate this appropriately.
  • E.g. minimise clicks to access the 5 main functions
  • E.g. reduce time-to-complete for function x, y and z by 10%
  • E.g. Align existing UI with iOS and Android norms
  • E.g. Increase usage of function z by 5%
  • E.g. 99% AAA compliance
• Who represents users on the project team?
  • How many user types do we need?
  • Can normal users and administrators share UX, or are their goals divergent? – different apps, different ASP Areas, different branding, …
• What platforms and form factors need to be supported/tested?
  • Does each platform need a native UX? If native app, probably yes, if web app, maybe.
  • If mobile, do we need to adapt to context : location/orientation/communication with nearby devices/…
  • If social, do we need to adapt to context : can I approve my own work?/who’s online/recommendations/who’s nearby/…
• Do we, as developers, have any input to the UI design? If not, why not?
• Have the designs been tested on users? If not, why not? (Does the UI fit user expectations?)
• Do we have appropriate guidelines for the appropriate platform, and are they listed in the requirements and estimates?
  • iOS : Mobile Human Interface Guidelines
  • Android : Design principles
  • Windows

Potentially useful resources

 

• Lean UX by Jeff Gothelf and Josh Seiden
• Steve Krug presentation : Usability – One more thing you don’t have time for
  • Also check out his books, including Don’t make me think
• UX Scotland
• UX Professionals communities
• UXPA-Scotland (mainly Edinburgh)
• Government Digital Service (Agile, UX and a few other real-world discussions)
• A List Apart
• .net magazine
• Ask Tog
• HTML5 Rocks
• Color Me Impressed: 3 Tools For Effortlessly Finding Beautiful Color Schemes For Any Project

Clockwise : suggestions for managing your time

• Plan ahead (with contingency)
  • Whatever works for you – personal JIRA, Trello, stacked sticky notes, dead tree notebook
• Stay focussed
  • Specify windows to check your email (e.g. first thing in AM and after lunch) and ignore emails until that window
  • Rather than letting new tasks distract you, write them down, then continue on your current task – and have a time to review and prioritize those tasks during the day.
  • Avoid context switching – humans are very bad at multitasking and your brain is highly prone to disk-thrashing, especially if you think you’re good at multitasking. See this TIME article for a summary of the research.
  • Some people work best with time-boxing : concentrate on a single task for a fixed period of time. Read about the Pomodoro technique.
• Say No if you need to – or you’ll disappoint
  • If someone asks you to do something, get a deadline for it to help you decide if you have time
• Track as you go
  • 6 minutes are a good building block of time to decimalise your day, especially if you’re filling out timesheets.
  • If you’re working on more than 1 project, you’re going to forget very quickly what you’ve done by the end of the week
• Review your time – find ways to optimise
  • Personal retrospectives. Are you spending your time on what you should be spending it on?
• Learn when to delegate, both to management and within your team.