Categories
.net code development

Thoughts on Global Azure Bootcamp 2019

I’ve got a collaborative post coming up on the talks themselves on my employer’s blog but as a speaker and tech enthusiast, I wanted to share a few thoughts on the bootcamp as a whole.

Firstly, I’d like to thank Gregor Suttie who organised the Glasgow chapter under the Glasgow Azure User Group banner.

It’s an impressive feat getting so many speakers on so many topics around the world. Each city is going to be limited in the talks they can offer, but I was impressed by the distances some of the speakers at the Glasgow event traveled.

I would have liked to have been more of a global feel. I know the challenges of live video, especially interactive, but this is an event that would benefit from some of that (or indeed, more speakers participating the the online bootcamp via pre-recorded YouTube videos). I realize an event like Google I/O or Microsoft Build is different in focus, being company rather than community driven, but it felt like a set of parallel events rather than one, so it also feels as if some of the content is going to be lost, and there were a lot of interesting looking talks in other cities that turned up on the Twitter hashtags.

There’s obviously a lot to cover under the Azure umbrella, so it’s going to be hard to find talks that interest all the audience all the time, and it was hard to know where to pitch the content. I aimed for an overview for beginners which I think was the right CosmosDb pitch for the Glasgow audience, but I was helped by the serendipity of coming after an event sourcing talk so I could stand on the shoulders of that talk for some of my content.

I would maybe have liked to see more “virtual tracks” so that it was easier to track themes within the hashtags, whether it’s general themes like “data” or “serverless” or technology/tool focused like “CosmosDB”, “Azure DevOps” or “Office 365”, to help me connect with the other channels and see what content is must interesting to follow up. Although Twitter was a good basis for it, I think there’s scope to build a conversational overview on top, into which YouTube videos, Twitter content, Github links, blog posts, official documentation and slide content could be fed.

As a speaker, the biggest challenge was keeping my knowledge up to date with all the updates that are happening, and events like this do help, but as I’ve been on a project that’s Docker and SQL focused recently, it’s a lot of work on top of my day job to keep in touch with the latest updates to CosmosDb, especially as a few tickets on the project were picked up and moved to “In Progress” between submitting and delivering my talk, and a new C# SDK was released.

Categories
.net code data development

CosmosDb in The Real World : Azure Global Bootcamp 2019 (Glasgow)

Thank you to those who came to my talk today about CosmosDb. I hope you found it useful.

If you’d like to review the slides, you’ll find the presentation online here :

CosmosDb In The Real World – GitPitch

If you have any further questions please ask below and I’ll do my best to answer.

Categories
development ux

The Dark Mode of usability and accessibility

I saw an interesting thread by Laurie Voss where he takes issue with the universal shift to Dark Mode across apps and platforms as an option. I’m sure it’s mainly a weary jest about all the effort to make something not for him. (After all, I’ve heard similar takes from white men about why bother spending time and money catering for women or people of colour).

This tweet stood out though and me think about how I conceptualise usability and accessibility :

‘Dark Mode is “totally useless mode” for me.’

I like dark mode for many reasons, there’s a small nostalgia element, but I do get big problems with eye strain. I started programming when we didn’t hook computers up to monitors, we used TVs, and sitting arms length from a bright flickering CRT is no good for anyone’s eyes. Modern LCD and OLED screens are much better (and I particularly like how well my Sony phone handles direct sunlight), but even then, I can get sore eyes and headaches looking at something too bright for too long. Dark mode allows me to use a screen longer without losing contrast. Although I am now more wary of wrist strain.

That’s how I often think of interfaces, as something which makes things easier. Something that reduces strain. And I sometimes forget that the point of accessibility cues is to make things possible. It’s not so I can stare at the screen for longer, it’s so that Laurie Voss has a screen where he can see the words.

So yes, I tag my images in Twitter. I use colour schemes with high contrast. I use structured HTML that ties inputs to their labels so that the accessibility tools have the best possible chance of doing their job.

So today, take a step back and think about what would make it impossible for a potential user to access what you’re building. Be that user. What do you need to add for them? If you’re not sure, enable the screen reader on your device and turn the screen over or off. Grab a screenshot and add a color-blindness filter. Fill out a form by voice, or use your onscreen keyboard to simulate a switch input.

How are you going to walk your software in someone else’s shoes today?

Categories
development leadership

Leadership by example

Are you a manager or a leader?

What behaviour are you modelling for your team? Do you send many emails out of hours? Do you multitask in meetings? Do you project frustration and disagreement with C-suite?

Do your team copy you?

If you send emails that late, an expectation will be set that everyone needs to check, unless you are clear why. Tell them you have to leave a hour early to do the school run every day, so you do your emails after bedtime for everyone to pick up in the morning. Even better, write at night but don’t send until the morning. There are plenty of tools to schedule that for you.

If you’re not focussed on a meeting, how can you expect your team to be. If you don’t need to be there, don’t be. If you trust your team and you won’t add value, step back. If you can change the meeting so it’s not boring, do that. When you’re in the meeting, be present, even if it’s just too watch the body language, and engage with that, use that feedback.

Are your team frustrated by decisions and often blaming others? Is that because you do it too? You’re not going to agree to every decision, but if you were on the room when it was made, or it’s your job to disseminate it, be at peace with the decision. If you can’t live with it, there’s other channels, up to and including leaving, but on your team decisions should be respected. They can be debated, reviewed and changed when circumstances change, but if decisions can’t be respected collectively, you don’t have a team.

Are you being the leading the team in the way you want them to work?

Categories
code

Live coding during a presentation

I’ve done a few talks in my time, and some of them have involved live coding to help take the audience on a journey to understand the lesson I want to teach. It’s a technique I use rarely however as it can easily get problematic.

Live coding for a presentation is not the same thing as coding for your job or a mob session. Live coding for a presentation has to be as slick and as polished as the rest of the talk. No googling the API docs, no stumbling over syntax errors (although don’t worry if you don’t spot them, someone will.)

If you’re nervous with slides, live coding can help relieve some of the pressure. It certainly helped me when I was starting out, as I could pretend I was having a conversation with my computer for some of the talk. Fortunately, it was a conference with microphones.

Live coding is also great for presenting something novel (or at least novel for most of the audience) as it gets to demonstrate that it’s real and it works. I used it, in one presentation, to demonstrate TDD.

Be careful though. Technology can let you down, so have a think about how you might demonstrate another way. Do you have a video you can show on someone else’s laptop? Can you demonstrate with screenshots? Could you whiteboard a solution?

If you don’t feel comfortable writing code in front of an audience, don’t. Can the code (I use VS code snippets, but there’s plenty of macro choices), so you can reveal it gradually. Or pre-build it and uncomment as you go.

If you are preparing code in advance, to distribute with the slides, heavily comment the code so that when people download it afterwards they understand the context.

I do love to see live coding done well in a presentation, but unless you’ve prepared it meticulously, it won’t go well. Think about the story, and how and when you’re introducing new concepts. Don’t be afraid to go back to something later (“Here’s how to connect, but I want to show you search first. I’ll come back to the parameters here once you’ve seen the search results.”) It’s OK to refer to your notes, especially if you’ve just thrown up a screenful of code for the audience to read. Make every interaction useful.

It’s OK to backtrack. Show the mistakes you made, the error messages you saw, and how you corrected them. You won’t be the last person to make that mistake.

Relax and enjoy it. If code is what you do, be comfortable with it, even if the nerves are trying to turn you inside out from your stomach.

Categories
development

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.

Categories
code development

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.

Categories
Blogroll

2018 in review

Loch Lomond

It’s been a big, small year for me. Big personally with a new job, but smaller publicly, although I’m now in a position to make more time for conferences following DDD Scotland and CodeCraftConf this year.

I’m still adjusting to agency life, but that might be because it’s been a big, amazing year for Screenmedia.

Looking at my stats, it’s good to see web dev and security are high in my logs, as that’s where this blog started, although there’s a bit more tech leadership content these days as well.

I’ve also got an account over at dev.to, which is a community of developer bloggers, and a couple of posts got some interest over there, so I’ll keep cross-posting to there, please say hi 🙂

I passed my CosmosDb exam last year, so expect to hear a bit more about that. I also have some thoughts on technical architecture and team building I want to explore further. If there’s anything else you’d like to hear about, please let me know.

I’m looking at a technical leads meetup/support group in Glasgow. More details to follow, but ping me if you want to make sure you don’t miss the details.

I’m looking forward to the new year. Thanks to all of you for reading.

Here are my highlights from 2018.

Top older posts

Top 3 written this year (WordPress Stats):

Top on dev.to:

Categories
code development programming

Software Development as a Christmas Story

Gingerbread Christmas Tree
Oh Tanenbaum

We decorated the house for Christmas. A smaller project than most of the software I’ve worked on, but a useful reflection.

The Cost of context switching

Sometimes, in the middle of one task, you need to do another. Either because you were interrupted, or because you weren’t prepared. Consider the tree, a tall tree, one you need a ladder to decorate. But you left the 🌟 in the attic.

You don’t just have the cost of picking up the star, you need to get down the ladder, fold it up, carry it upstairs, open the attic, unfold the ladder, climb to the attic, find the star, then pick it up and unwind all the other steps just to get back where you stated before you can continue the task of putting the Star on the tree.

It’s just a minute to get the star…

Yak shaving

Sometimes it’s more than just one thing. Sometimes to get to where you need to go, there’s a cascade of other tasks.

You want to put the tree up, but it’s the first time you’ve had a real tree, so you need a new base. It’s bigger than last year’s tree, so your lights don’t fit. So you need to go to the shops. But you need to fill up your car. And the tyre pressure warning light comes on so you need to top them up. And you need to check the tread depth whilst you’re there, and so on.

Programming in a nutshell

Performance at scale

Our tree stood up fine when it was delivered. But as it scaled out and the branches widened, it pushed against the wall, making it unstable in the condensed space. It fell over.

Luckily no lights or baubles were using it at the time, but it’s an interesting challenge holding up a heavy tree in one hand, trying to adjust it’s position with the other hand, as I avoided the puddles of water in the floor as my wife mopped them up. If you’ve ever worked support, this may sound familiar.

Turns out that it was harder to stabilise than I anticipated.

The branches were unevenly partitioned, providing more load on one side, so I had to stabilise it against the wall. And the tree was almost a foot taller than expected, which turned it out to be 2 foot taller than the base was rated for.

We upgraded the base to handle the load. It’s bigger than we need.

Technical debt

I have some old pre-LED tree lights and they slowly fail so each year I replace the unlit ones from the packet of spares but I haven’t been replacing the spares. Eventually, they will run out, and the spares will no longer be available. I’ll have to throw them all out and start again.

The new led ones don’t let me replace them individually. But they last longer and are cheaper to run.

Which debt is easier to live with?

With a big tree, those old lights aren’t long enough. So, do I buy another set for the rest of the tree that doesn’t match them, or throw out the existing ones and buy a longer set? The latter looks better, but throws out the sunk cost along with the lights.

You know computers, can you look at this for me?

No, I can’t fix your tree. I can navigate a garden centre. I know enough physics to keep a tree upright, eventually, and safely put the angel on, but I’ve no Idea how to grow one, or what that weird stand with 17 gears you bought does, or how to assemble your plastic one. And I’ve no idea what that bug in the tree is.

Merry Christmas. Catch you all in the New Year.

Categories
code development programming

How I approach coding challenges

This time last year I was doing a lots of tests for job interviews, and I was practicing with https://adventofcode.com

I know there’s various data structures and algorithms you can learn to make these easier (and I hope to come back to some of my favourites in a later post), but there’s a general approach I take to these that helps me, and might help some of you too.

Use TDD

I’ve always been a fan of Test-Driven Development, and these type of puzzles lend themselves well to TDD thinking. Often examples are provided that will form the initial test suite. The algorithm is often broken into steps (sometimes explicitly “On every clock tick…”)

Get into the habit of checking as you go to make the most of the information provided to you. Think about the problem first, and the mapping between the input and the output, before you write any code.

Check everything on simple solutions.

Have templates

Most challenges involve a few common tasks. Read input from a file (ignoring blank lines), create a list of…, output as CSV, etc.

Some of these will have standardised patterns in your chosen language, and you should use them. Some will likely require some error handling. Some will require loading from standard or 3rd party libraries. And all will require a test framework.

As you go, build up a utilities list of functions, classes and packages that you know how to use, are robust enough and have minimal clutter. They’re not meant to be usable by anyone but you, but you will use them a lot. Collect and cherish them.

Think simple

Technical tests and coding challenges, in general, are designed to have short, easy solutions. If you need to solve P == NP to make your code fast, it’s likely you’re using an algorithm that’s a poor fit. Find 2 other ways to solve the problem, and pick the simpler one.

Simpler than that

Think about the simplest solution that could possibly work and write it simply.
Make the code readable. This is not the time for clever solutions. When it fails on an input, make it easy to change.

But not that simple

You still need to think about edge cases, and memory usage, and a myriad of other resource constraints. Think about what could go wrong, within the confines of the puzzle. Advent of Code has a particular knack for detecting edge cases in your code for Part 2 of each day’s challenge.

Think fast

Beware of premature optimisation, but expect long inputs and many loops if you use the naive implementation. Learn new algorithms and data structures.