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.

Advertisement

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.

 

 

Little UX wins #littlejoys

I’m no expert in user experience. So I’ll let others talk about the personas, the end to end journey and bringing joy. I want to talk about the details.

Those papercuts that slice away at you, that just make things a bit more work. The things that spending 15 minutes watching users makes you scream at yourself for putting your users through it.

But it doesn’t just affect technology. Here’s a list of papercuts I’ve noticed, either because one company has fixed them, highlighting the pain that everyone else puts you through, or because they annoy me. Reflect on your experiences as a user. What delights you and annoys you?

Things I like

• Waitrose Meat in foil trays store the sachet in the cardboard cover, outside the foil tray, so no meat juice on them. This is a great example of separating concerns so that the raw, unsafe meat never comes in contact with the sauce until it has been cooked to make it safe.
• Double tap to wake. The on button on many phones is small, and often hard to reach when on the table. Phones that allow a full screen action to wake take advantage of Fitts Law and their large screens to make that common action much quicker.
• Lenovo N22 carrying handle. Many people carry their laptops without a bag. When you have a cheap, light, knockabout laptop, embrace it, and give it a handle. Bonus: teachers can carry many at once.
• There’s also a bundle of wonderful examples here: UX out of electronic spaces http://uxpa.org/upasiteredirect/index.html/uxmagazine/lets-get-physical/?utm_content=bufferea7eb&utm_source=buffer&utm_medium=twitter&utm_campaign=Buffer

Less good

• In my house, there are some lockable windows and some button operated (for fire safety upstairs)). On the button windows, you push and then turn. On the lockable ones, you turn the key to release the button, then turn. Every time, I push the button to open those windows, see the locked window depressed and think it’s unlocked. Every. Bloody. Time.
• Something that needs better feedback rather than relying on transferable knowledge that many people are bad at : estimating size. Why does no microwave rice have a visual indicator of 2cm for the tear? So many packets have “tear here” and printed perforation. Why not “stop here”?

What papercuts have you seen, and what user experience interactions give you joy?

Cloud is ephemeral

The Cloud is just someone else’s servers, or a portion thereof. Use the cloud because you want to scale quickly, only pay for what you use, and put someone else, with a global team, on the hook for recovering from outages. You’d also like a safety net, somewhere out there with the data you cannot afford to lose. But whatever is important to you, don’t keep it exclusively somewhere out of your control. Don’t keep your one copy “out there”. Back it up, replicate it. Put your configuration and infrastructure in source control. Distributed. Cloud thinking is about not relying on a machine. Eliminate Single Points of Failure, where you can, although there’s little you can do about a single domain name.

Understand your provider. Don’t let bad UI or configuration lose your data : Slack lost 800,000 messages.

Your cloud provider is a dependency. That makes it your responsibility. Each will give you features you can’t get on your own. They give you an ecosystem you can’t get from your desktop, and a platform to collaborate with others. They give you federated logins, global backups and recovery, content delivery networks, load balancing on a vast scale. But if the worst happens, know how to recover. “It’s in the cloud” is not a disaster recovery strategy, just ask the GitLab customers (although well played to them on their honesty so the rest of us can learn). Have your own backup. And remember, it’s not a backup unless you’ve verified you can restore.

It takes you 60 seconds to deploy to your current provider. How long does it take to deploy if that service goes dark?

Good developers learn

When I interview people for a job, I look for their skills, but most of all, I need people on my team who love to learn. I was thinking about this when I listened to Rick Strahl talking on .Net Rocks

When I started developing, there was a lot of talk about certifications and becoming a language expert, or even an expert in one aspect of a language. C# for web applications, for example.

Now, it’s no longer a matter of learning a technology. Good developers learn to learn. Understanding enough to detect smells in languages and frameworks and knowing how to trial and evaluate them. In an agile world, there’s no architecture team to dictate to you. You need to be brave enough and supported enough to make a good decision. Not necessarily the best, but at least not a wrong decision.

More than ever, with the architect hat on, we need to make quick decisions based on incomplete information and be willing and able to change if and when new information invalidates those decisions.

I have no doubt that .Net core is the future for the platform, but having made the decision to try it on a project, we had to change back to .Net framework because core isn’t ready yet. We needed experience to tell us that.

If you’re going to do something new this year, learn to learn. Invest in knowledge, experiment with new ideas and technologies, and document your discoveries, in a journal, a blog, a video, a presentation or a dictaphone, to give you the chance to reflect on what you’ve learned.

Why I prefer pessimistic merging

Even though I trust my team.

As a technical lead, I think code reviews are essential to ensuring the quality of the code. On a project I worked on, due to changes in Project Management, I ended up switching between code reviews as standard and code reviews by exception, and in every case, releases delivered with code reviews baked in had fewer bugs, and were far more likely to meet deadlines.

I believe that code reviews done after integration have roughly the same benefit on these metrics as no code reviews at all. Although this guy prefers optimistic merging, I’m not convinced, and I think pessimistic merging is the only way to review code, especially when automated testing and static analysis are part of the review process.

However, my experience is with working with small-ish, cohesive teams, rather than open source projects seeking new contributors, so please bear that context in mind.

• It’s easier to fix problems pre-merge;
• Blockages pre-merge are far easier to detect (kanban!) – fix the bottleneck, don’t break the process;
• Code reviews are the process by which the team takes ownership of the code;
• The code remains continuously shippable;
• Each code review is a checkpoint for discussion, and segways into refactoring and other improvements.

12 reasons why I love software development

1 Automation means fixing it once.

Although please note that fixing it once doesn’t mean always fixed. I’ve got a 20 year old Mandelbrot generator that still works but I’ve had to tweak as the C compiler evolved. The algorithm is the same, but I had to modify the implementation slightly as GCC changed how it handled the standard library.

2 Working with smart people.

If you’re scared of learning, this isn’t the job for you. Experienced people will show you solutions you’d never thought of, everyone will ask you questions that cause you to re-evaluate your decisions, and you’ll find yourself saying “I don’t know” more often than not. If you think you know everything, you haven’t even started.

3 Variety

Once a problem is fixed you move on to new domains and new problems. You need to grok new domains, learn new technology, analyse how you work and adapt.

4 Alternative perspective

Software development reaches into many aspects, and covers a variety of topics, so allows healthy discussions across disciplines. (commit strip cartoon?) How you see a process or a program is likely not how the users see it. Human processes are messy and full of holes. Sometimes we can fill them, sometimes we just have to let the users work around them.

5 Meritocracy

(Disclaimer: I realise I’m talking from a position of privilege, and this may not reflect everyone’s experience)

All the teams I’ve worked in are judged on their ability to deliver good software, not colour, gender, age, disability or otherwise. People are praised on their ability to deliver and to work worth others, and criticised when they fall short. I realise I only see a small proportion though, and I did work as a STEM ambassador and a youth club volunteer to help broaden the pool. There’s a lot of work to be done, but good teams benefit from the diversity, and recognise that. If your team doesn’t, fix it. And help get out there to fix it for all teams.

6 Pride in seeing our work being used.

I’ve worked on projects to distribute EU funds to projects around the country, to track prisoner learning to make sure they could get qualifications, to model factories and save companies millions, to help people navigate their bankruptcy, to help nurses and managers find inefficiencies in hospitals. The software I’ve worked on its being used by people for whom it makes a real difference. There’s few jobs that allow you to impact so many people, in so many different ways.

7 Multi-disciplinary

Software development touches on many disciplines, and successful software projects provide opportunities to discuss ethics, psychology, politics, law and other areas. There’s a lot of specialism, but if you want to understand your users, and understand security, and understand the requirements, you often need to dig in and uncover answers from many disciplines to truly understand what you’re building.

8 Satisfaction

It’s clear when a problem is solved. It might not be clear when a project is finished, but each step on the way should be a clear, this is Done. If you don’t have that on your team, define Done. That’s your route markers so you know you’re making progress.

9 Mentoring

It’s great to see others catch on. See them awaken to the fact that there’s so much more to learn, that software development is a rich, diverse discipline, and then see them run in a direction to become the expert you seek advice from in their chosen area.

10 Challenge

Sometimes the satisfaction from development comes from tackling hard problems with no easy answer. Knowing that no-one has solved it before. Land on your own moon.

11 Communication

There’s always someone interested in what you’re doing, and there’s multiple international communities. There’s websites and forums, user groups, conferences. Lots of opportunities to engage with others and learn and teach outwith your company circle.

12 Changing the world

Software has become the driver for most of our daily lives. Without it, there would be no smartphones, no Internet, no social media, no video calling, no Uber. If you want to change the world, first you must understand it.

Killing legacy code

Michael C. Feathers defines legacy code as code without tests. I find it’s also likely, as a consequence, to be heavily coupled, with deep tendrils interconnecting multiple components. Indeed, many of the patterns in his Working Effectively With Legacy Code are about how to sever those tendrils safely in order to test the components individually.

But sometimes it’s about cutting out dead wood, that once-central code that’s outlived its usefulness and whose self-importance is infecting global configuration and the architecture.

The code that has special conditions in the API and would likely be more stable if it was split into smaller chunks.

Many of the techniques are the same as you’d use to get the system under test, add wrappers so you can redirect to null implementations, ready to remove all the calling code; replace global variables with more appropriate scoping.

So you get the code working, and passing the tests, so you’re comfortable that it’s removed, but then you have to deal with the orphans. The homeless configurations, the stateless variables, the untouched methods, that look like they should be free to go, and aren’t referenced anywhere. Except there’s some stringly typed calls, or rendering of inputs, that might, just might, use that code.

And they sit and rot.

Until you profile, and analyse, and kill off some more.

And you rewrite the input handlers to ensure nothing can be constructed to hit them, and kill off some more.

And then something breaks, and you’re too scared to touch any more, because of quantum effects.

And then you add new generic error handling so you can remove some more.

And then you rewrite it.

Cloud thinking : efficiency as a requirement

In the old world, you bought as big a machine as you could afford, and threw some code at it. If it could fit in memory and the disk I/O wasn’t a bottleneck, everything was golden.

In the cloud, however, CPU cycles and disk storage cost real money. Optimisation is key, so long as it’s not premature. Monitor it.

In cloud thinking, it’s less about the O(N), it’s relatively easy to scale to the input, as long as you’re not exponential. In the cloud, it’s about O($) – how well does your code scale to the amount of money you throw at your servers (or inversely, what’s the code increase per user).

Fixed costs are vanishingly small in the cloud, but incremental costs can change quickly, depending on your base platform. Not the provider, as costs between them are racing to the bottom, but the platform of your architecture.

Quite simply, the more control you ask for, the more you pay in time, and the bigger the ramp-up steps. Get metal, and you’ll pay for everything you don’t use, get a VM and you can scale quicker to match demand, get a container, get an Electric Beanstalk or an Azure website and give up the OS, get a Lambda or a Function.

I can’t recommend to you how much you should abstract. I don’t know how big your ops team are, or how much computation you need to do for each user. I suspect you might not know either. Stop optimising for things you don’t care about. Optimise for user experience and optimise for cost per user, and measure everything.

How to grok a new domain

One of the under appreciated aspects of software development is the number of different domains many of us work in over our careers, especially those working in consultancy. Software, generally, is straightforward, especially for the majority writing text boxes over databases. Not necessarily easy, but if you’re able to understand logical thought, and decomposition, picking up new languages and technologies is simply a matter of time.

The challenge is when things aren’t logical. When you have to use languages designed for humans, rather than machines, and when you have to understand processes that aren’t necessarily logical, or decomposed, and turn them into something a machine can understand.

Understanding the domain

The followers of domain driven design, and anyone who values use cases or user stories, will tell you that the first thing you have to understand is the user. What are they trying to do, and what nouns and verbs do they use to describe it?

These are the words you need to use. Whatever the system does, it should use those words to describe its state and to reflect that state back to the user.

Understanding the process

Software always models processes. Without understanding the processes, the software will model the wrong workflow, leading to a frustrating user experience. The real skill in learning these processes is understanding which are immutable and which are open to modification.

Once you start digging in, you’ll start to hear phrases like “we’ve always done it this way” or “we know that’s a bit clunky” or “here’s the workaround” which are big hints that there’s something to be improved.

Understanding the motivation

Key to understanding a new domain is understanding why. Why are people doing what they are doing – what is their goal? Why does the current software or process work the way it does? Why are you being asked to change it – what can you do to make things better?

It’s the most important question you can ask, and also the one most likely to be forgotten. Finding the right motivation for the software to exist is the key difference between successful and unsuccessful projects. One of the core tenets of agile is to keep checking that the software is meeting the needs of the users, gathering feedback and responding to it.

The logic of the illogical

For those of you that have never tried to turn the chaos of human language and rules into a logical digital narrative, I’d recommend listening to this explanation of timezones, and asking yourself how you’d go about learning all the rules and exceptions you’d need to be able to write this yourself.