Tag: politics

Categories
free speech leadership

No politics at work

A public library, with the sign "Please do not touch the books, thank you"

No politics at work.

We’ve got these tabulating machines to send to Hitler.

Talking politics doesn’t get us paid.

There are plenty of companies withdrawing into their shells of privilege because the founders are scared of getting uncomfortable.

If you want a more uplifting picture of what happens when you talk politics at work : you save lives.

Whatever the antecedents of the recent wave of decisions to ignore people’s lives by “not talking politics”, the effects are defiantly anti-union, anti-women, anti-BLM, anti-trans and pro-christian-conservatism.

Even at companies who may have introduced these policies as a reaction against actual fascist viewpoints on their internal discussion boards (which I haven’t seen is the case, but I have heard some justify it that way), banning all politics supports the fascists.

It chills the speech of the oppressed, and gives fascists ammunition that “our free speech is under attack”.

There’s plenty of policies that allow you to talk about maternity leave and single payer healthcare without allowing blood and soul nationalism.

Companies that ban all politics are companies that have weak leadership who only want to align with the prevailing winds, in the most conservative way possible.

Companies, especially tech companies, can change the world. But too often they just reinforce the status quo.

Even companies that want to liberate us from the office, or liberate us from fossil fuels, or liberate us from Earth, still reinforce the power structures that led to the problems they claim to want to solve.

To summarise this, and other points,

“we’re uncomfortable with you having a life outside work”

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

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.

Categories
data development free speech security

Government insecurity agencies

A green screen of a glitched image
Encryption or corruption

Given the SSL attacks that could be traced back to classing secure encryption as weapons subject to export restrictions, it’s clear that government security agencies have a deep conflict of interest that has led to significantly reduced security protection for their own citizens.

It’s clear that the Ransomware (or Ransomware as diversion) attacks on UK and US hospitals and many other sites are directly due to the NSA backdoor toolkit that was stolen earlier this year. Because if the government has a back door into a system, or an encryption platform, everyone has a backdoor, even if they don’t have access to it yet.

Which is why it’s great to see the EU outlawing backdoors in order to protect us as patients, service users, and data subjects, and I completely expect this will apply, like GDPR, to any system holding EU citizens data. So when the UK puts on its “we need a back door” legislation, companies need to choose to trade with the UK and compromise their security, or trade with the much bigger EU and protect their customers.

Encryption is like a lock, but it isn’t. It’s like a safe door, but it isn’t. Abstractions help to frame the problem, but they can obscure the issues. They make lawmakers think that what applies to banks applies to data.

(note: bank processes are optimised to replace credit cards because security works best when you can throw away a channel and start again if it’s compromised; this includes reversing transactions – which is hard to do when it’s the release of your personal data that needs reverted, rather than a row in a ledger than can be corrected by an additional row).

Encryption isn’t the problem. The San Bernardino iPhone had no useful intel. All the recent attackers in the UK were known, reported, and could have been tracked if they were prioritised. Banning encryption will have about as much impact as banning white vans. Breaking encryption weakens our security, threatens international trade especially with the EU, and when security holes lead to attacks on our hospitals and other infrastructure, bad security threatens our lives.

But so long as we’re afraid of terrorism, it’s OK for the populous to suffer?

Categories
development programming ux

Non-functional requirements and terrific testers

Cut that cake

There’s a ongoing debate about non-functional requirements: Non-Functional Requirements Are Not Nonsense and it’s a debate I’ve had within my teams as well.

In most consulting projects I’ve seen, non-functional requirements are listed as a nice to have, rather than a must have. It’s not a matter of business logic vs. performance either. In one rare exception, I’ve had a requirement for an import function to load and validate millions of records within a 48 hour period. If the import wasn’t correct and wasn’t fast enough, the requirement was not met. We made it with room to spare.

I think one of the key problems developers have with non-functional requirements is that they aren’t tasks to be achieved then ticked off, they’re cross cutting concerns, and are often best effort, so don’t need to be 100% complete to be ready to ship. They can be continually refined.

This can be hard for binary developers to grasp. Tests pass or fail, requirements are complete or not. And in a pre-devops world, many of the factors affecting them are outside the control of the developers. You can’t have 99% uptime on a VM that’s off for 30 minutes a day to be backed up.

Good testers help to bridge the gap by turning an aspiration into a target. They hear the customer wants the website to be fast, and they write 95% of requests return in under 250ms. Browser compatibility goes in the test log, because “the current version of…” is a moving target.

Not that we pass responsibility for meeting the requirements from developers to testers, but we get the testers to turn something vague and system wide into something tangible and testable that the business owners and developers can agree on. After all, if it can’t be tested, there’s no way to measure of it’s done.

Most of all, it’s about explaining to business owners that an aspiration is not a requirement.

Categories
development leadership

Handling disagreements as a team

happy sliced bread

Following my code review post, I added some more thoughts regarding code reviews, but there was one comment that I wanted to come back to later:

“Social aspect: How do we handle disagreements? As a team.” – peitor

There are a number of aspects to successfully dealing with disagreements, some of which are about mitigation and avoiding the problem in advance, and others about how you deal with the problem once the disagreement has started to grow, after all, it’s hard to avoid the vim vs emacs, “that’s not RESTful”, brace placement, or other developer arguments.

Collective Ownership

The first key to avoiding unnecessary disagreements is to leave your ego at the door, because teams full of egos will fight each other to be seen. As Peopleware: Productive Projects and Teams so elegantly describes, any situation that asks developers to compete against each other, whether under performance review,or by dividing functional teams geographically, will inevitably lead to conflict and a blame culture. If you are all on the same team, with the same goal, it’s in everyone’s interest to resolve disagreements before they become conflicts.

Constructive Criticism

One of my colleagues has been writing a series on becoming a technical lead, it’s all worth a read, but his latest post, about constructive criticism, is particularly relevant to this discussion.

Constructive Criticism is a reality of doing code reviews, it’s arguably the whole point of doing them, but make sure that you are able to articulate clearly what you expected in a friendly manner, a Blame Culture is bad.

This doesn’t just apply to code reviews, but that’s an important example of where code is judged. Firstly, constructive criticism should be about the behaviour or the outcome, rather than the person (although even at that level, it’s wise to avoid abusive language if you want to avoid alienating your team, just ask Linux Torvalds), and secondly it should offer practical, achievable improvements, so that the person receiving them can use them as an opportunity to improve.

Lone Wolf

There are 2 main categories for individuals who have a detrimental effect on the team. One is the black hole who needs additional support or encouragement and sucks time away from the rest of the team, and any work they produce is marginal. They might be just a poor team player, or a square peg in a round hole (maybe they’d be great in another job on the team or in the company), but they breed resentment in the rest of the team having to compensate.

As a leader, you either need to find a way to help the person to improve and fit into the role they are doing, via mentoring, training or other means; or you need to find a role they are better suited to, by looking at other tasks that need doing.

If you can’t do either of these things, you will need to make the tough decision to get that person off your team so that the rest of the team become more productive and do not degenerate into dysfunction.

Rockstar

The other key individual threat to team coherence is the rockstar developer. The one who plays by their own rules, and always knows best. Unlike the black hole, they get the job done, but they often do so at the expense of the team.

Key traits of Rockstar code is code that doesn’t fit the rest of the team, code that is too clever for its own good, and therefore much harder to test and debug.

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?

Just like the black hole, the rockstar developer causes addition work for the rest of the team, but often leaves behind code that the rest of the team don’t understand in order to be able to refactor it. This resentment can be seen by the rockstar developer as jealousy, as their non-stick ego prevents them from taking responsibility for dysfunctions in the team, and it is clear, particularly to those outside the team, that the individual is achieving results (indeed, the rockstar often makes it very clear).

A rockstar does have many of the qualities needed to be a good developer, so long as they can be convinced to simplify and work with the team rather than steamrolling past. Unlike black holes, they are probably doing the right tasks, but need help to understand their impact on the rest of the team and any problems that result from their code, as they may have trouble accepting it.

Duelling banjos

Sometimes, there are individuals that work well with the rest of the team but not each other. Sometimes this can be caused by jealousy or resentment, particularly if one was recently promoted or given extra responsibility when they were previously equal, or one of them is more likely to have their ideas accepted by the team.

The slighted individual in this scenario needs support from the other individual and the rest of the team to accept the situation, and build resilience so they can move on, and, where appropriate, a clear explanation for why the differential occurs.

Hopefully these disagreements are on the ideas rather than the individuals, because when things get personal, it gets a lot harder for people to back away from a disagreement. However, the technology world is notorious for bug fights over little things.

Which text editor do you use? (whichever one you like, so long as you can set the format to the project coding standards)

Where do you put the opening braces? (for Javascript, always use K&R style, on the same line, for everything else, whatever the project says)

If you’re fighting over something that doesn’t really matter, ask yourself why, and if you can just agree to disagree, and accept that you’re not going to convert everyone to Dvorak.

If you see others on your team fighting, look out for Logical Fallacies that can drag the argument down into personal attacks, or unproductive sniping rather than a stimulating argument on improving the code. Be prepared to step in and separate the individuals. Give them a chance to cool down and reset, or space to think, talk and reflect.

Red eyed monster

The tired, stressed team are far more likely to argue and those arguments are more likely to get personal. Don’t overwork. Find your work-life balance.

You

You are a member of the team. Exhibit the behaviour you want to see.

Categories
quickfix

Paperless and warning free

there's a dog driving that car?
Do you have a licence

there's a dog driving that car?
Do you have a licence

As a quick follow up to my post on the new process for endorsements following the demise of the paper counterpart driving licence.

First, a clarification, the change in the DVLA is for the paper counterpart to the photo id licence, not the paper licence that existed before the photo id licences. Many people will have been switched to photo id by moving house though, so it’s only the hardcore who won’t be included.

I got confirmation from the car hire firm 24 hours in advance that I needed to print out my endorsements sheet, by which point I no longer had access to a working printer, so I was glad I’d tried it beforehand. The guy at the desk noted that it was a new scheme, and also mentioned that if I hadn’t printed it out, they would need to call a DVLA verification phone number which is very busy when it’s not shut. So still a number of teething problems to sort out.

Do if you are hiring a car, get yourself over to dvla in advance (any time within 21 days) and get your endorsement sheet printed. It might just save you from long queues and grumpy car hire staff.

Categories
development programming timeout

Innovation vs Quicksand

Anyone following me on Google+, Facebook or Twitter may have seen me posting quite a lot about the many Intellectual Property cases currently strangling the mobile computing market. A lot of them involve Apple, but it’s not an attack on them. They just happen to be in the dominant mobile position now that Microsoft was in 10 years ago on the desktop, and so they’ve got the most to lose.

Last decade, the stories were of Microsoft using Windows to cripple competing office suites and promote its own, and the big move to unify the desktop, server and mobile Windows experience with XP and .net, and giving us IE6 and anti-trust cases. Now, we have Apple unifying desktop and mobile, and pushing others away with policies on in-app purchases and legal battles blocking competition in the marketplace.

I like competition. Competition makes phones faster, batteries last longer, and keeps everyone on their toes. Without it, innovation stagnates.

I am not a lawyer, so I don’t understand why a sketch that looks like a sat nav can be used by Apple to stop tablets from competitors being sold. It’s not like the Chinese rip-off that fooled even the employees at the fake Apple stores.

There is something rotten in the world of technology. It’s about patents, copyright and other protection, but whereas it works for Dyson, to protect his cyclone, whilst allowing competition from other bagless systems, the same protections are smothering the computing and smartphone market, distracting all companies into defending themselves against others, instead of differentiation through innovation. I don’t to work in an industry that’s moving through quicksand, dragging platforms, tools and devices back. We’re already held back enough trying to build for incompatible browsers without having to rewrite for new platforms just because the ui of one has protected interactions (think touch screen versions of Amazon’s pervasive One-Click patent). Higher costs for developers, higher costs and frustration for end users and the vendors fighting amongst themselves won’t benefit, ripping chunks out of each other and alienating the rest of us.

Samson needs to come and cut some crown jewels in half.

Categories
lifehacks programming

Ask me anything

Last week, inspired by a post by Ben Nunney, I set up a formspring account to accept questions and a got a good selection covering DDD Scotland, smartphones and politics, as well as some spam concerning a certain fruity tablet. Please head over to have a look at my answers and please add your own questions. I won’t promise to answer all of them, but I’ll try and answer any sensible questions. And my thanks to Ben for the idea.