Month: March 2018

Categories
code data development free speech security

Ethics in technology

This is an extension of a twitter thread I wrote in response to this tweet, and thread about the Cambridge Analytica revelations.

One of the key modern problems is how easy it is to access these tools. You don’t need professional training to string these together.

It’s as dangerous as if someone invented a weapon that could kill 10s or 100s of people, light enough to carry anywhere, and available in any store, without training. And expecting owners to police themselves.

People are terrified of AI. We know we don’t need AI to disable hospitals. We don’t need AI to intercept Facebook logins (although FireSheep and the pineapple are less effective now). We don’t need AI to send a drone into a crowded market.

Make a website the only place for government applications, such as medicare or millennials railcards and it’s easy to remove access for all citizens.

But combine all that with data and you can fuck up someone’s life without trying. You can give 2 people the same national insurance number or other id. You can flag them on the no fly list.

You can encode prejudice into the algorithm and incarcerate someone because they grew up in a black neighborhood.

The algorithm is God. The algorithm is infallible. Trust the algorithm.

Even when it tells you someone is more capable than the humans says she is, and punishes them.

(unless you’re under GDPR where you have the right to question the algorithm)

But tell anyone that people will use data for purposes they hadn’t considered (like using RIPA anti-terror legislation to see if someone’s in the school catchment area) then you’re paranoid.

Be paranoid. People will always stick crowbars in the seams. Whatever your worst case scenario for your code is, you’re probably not even close.

You can see my original tweet, and the repies, here:

The Guardian has a great interview on AI, existential threats and ethics on their podcast here.

Advertisement
Categories
development leadership

Becoming a technical lead: Trust your team

When I first became a technical lead, one of my biggest challenges was giving up control. It wasn’t a matter of not trusting my team technically but I didn’t want to overload them, so I took on all the planning, all the customer interaction, and all the other jobs that I felt had distracted me from the job of writing code.

I was wrong.

I needed to let my team in, because they had ideas that I didn’t, they had capacity whereas I was a bottleneck. I was holding up my team.

But I needed to be sure that coding standards were followed and quality was maintained. You know who else cares about that? My team. I made it their responsibility to ensure that the code met standards, and pushed out code reviews. I put internal documents at the same level as code. Anyone can edit, but everyone can review, or veto.

I asked for honest feedback in retrospectives, and implemented changes, so they could trust that I was looking out for them, and I set them goals to improve, alongside the feature work : “can we release twice a week?” (challenge – automate the pain points); “can we halve the bugs found in testing” (challenge – better unit tests)

And the more I trusted them, with support, and understanding their limits, the better they performed. I’ve also worked with managers who don’t trust their teams. Those teams don’t work so well.

If you don’t trust your team, they’re not your team. They’re just people who work beside you. What are you doing today to foster trust?

Categories
development

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.

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 ).

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.