How to mentor

​Once you start getting experience, you’ll find other developers asking for your help. I started tutoring at university so that I could help, and reflect and improve my own knowledge. 

Mentoring isn’t about answers. It’s about learning how to find the answer. The most interesting problems we deal with are the ones that no-one knows how to do. 

When someone asks for help, help them to help themselves. You need to start asking questions to help them find their own way. 

A successful mentor makes themselves obsolete quickly, but remains available to keep asking questions. A successful mentoring process leaves the learner with autonomy and support. 

My favourite quote from my tutoring days was a pair who, after I asked them enough questions to finish the tasks, said “I like you because you make me feel smart”. 

If you’re hiring the right people, they will be smart. Make sure the mentoring and onboarding reforces that. Smart, confident people are the ones who solve problems. 

Advertisement

Is software your vocation or just a job?

When I was a tutor at university, there were three main types of students I saw in the lab: the Googlers who would search for an answer or three (in those days Experts Exchange, today Stack Overflow), mangle something together then either figure it out and simplify or give up ; the ones who cared about the craft of software development and usually just needed a nudge in the right direction with a good question or two (I remember a couple of girls telling me they liked me as a tutor because I helped them feel smart, figuring it out for themselves) ; and the ones who just wanted to do enough to get a job. 

I’ve nothing against the folks doing it just  the money, but those are the people that waterfall is for. They need structure and guidance to perform well, and that tends to happen in places where software is a component in an expensive system that has to be built by committee in a waterfall fashion. Sometimes they’ll be promoted to management and make a good job of it, sometimes they’ll be left behind by the thinkers on the team. 

The ones who think, the ones who ask questions, and who never accept “That’s the way we’ve always done things” as an answer are the ones built for modern software-as-a-solution development. The Googlers can become thinkers if they take ownership of what they wrote, or if it’s a clue for them to apply to their own code. 

If you’re not a thinker. I hope I never encounter your code outside a warning. 

The graveyard of things

End of the road

In the 1970s, UNIX was big, and so were the machines it ran on. The source code was controlled by those who sold the computers, and if you wanted to modify it so that you could fix things, or improve things, you were stuffed.

The tinkerers weren’t happy, so they created a charter, a licence to share, improve and adapt, so that you could create. Free Software was born. Free to be used, changed and distributed. It wasn’t for everyone but tinkered loved it, and it changed the world.

Fast forward to today, and one of the most famous users of open source, and part-time supporter, Google, stirs up trouble in its Nest division, when it announces not only that it will stop supporting an old device, but also that all existing ones will stop working: Nest’s Hub Shutdown Proves You’re Crazy to Buy Into the Internet of Things http://feeds.wired.com/c/35185/f/661370/s/4ebe676d/sc/15/l/0L0Swired0N0C20A160C0A40Cnests0Ehub0Eshutdown0Eproves0Eyoure0Ecrazy0Ebuy0Einternet0Ethings0C/story01.htm

The tinkerers have been duped. They don’t own the devices. They now have expensive hockey pucks.

So what could Google have done?

How about releasing the server code and allowing anyone to patch their device to talk to a local server? It might be less smart now, but it’s still smarter than a hockey puck.

Indeed, in a world where breaches are getting more common, and devices have more and more access into our lives, why isn’t local access an option? Maybe we need new standards, but most of this data has been accessible via usb for years.

This is your data and you should have the option to secure it to your network, and to keep collecting and using it no matter what changes happen to the original manufacturer.

Embrace tinkering. Reject dead man’s switches.

Project Manglement: a few leadership anti-patterns

Note: these are a selection of things I’ve seen and heard from a number of people in a number of companies, and some mistakes I’ve made. Any similarity to your situation is entirely coincidence.

(If you like this, I’d definitely recommend PeopleWare by Tom DeMarco and Tim Lister, as that’s got a lot of good stories and science about what makes for a productive team, company, and office)

Expecting things to just be done

Just because a problem was identified, doesn’t mean it will get fixed. In a team, everyone, including you, can easily claim it’s someone else’s problem, or that their other work is more important. If you want it done, assign it, and prioritise it, either yourself or as a team.

Tell, don’t ask

On the other hand, don’t fall into the micro-management tap of telling everyone what to do, thereby removing autonomy, you’ll kill creativity and motivation, and you’ll end up with an informal work-to-rule where people twiddle thumbs until you tell them what to do.

Treat estimates as promises

We call them estimates for a reason: we don’t know how long it will take. We can make a good guess on what we know, an educated punt on what we know we don’t know, and a wild gamble on what we don’t know we don’t know. If you want an accurate figure, ask us when we’re finished.

Meetings as status

Meetings aren’t for your ego, for everyone to listen to you. If the team respects you, they’ll listen anyway. If they don’t, meetings like that are likely to antagonise.

Meetings aren’t for you to find out progress. That’s what wall charts, release notes, and daily stand ups are for.  Don’t call another meeting just because you weren’t paying attention.

Leaky abstractions

It’s likely we’re just as frustrated as toy that the release wasn’t perfect, that those requirements are taking longer, and we know the customer is frustrated too. Telling us about it every time they contact you (or Cc’ing us in so we can see it ourselves) is rarely helpful. Developer’s egos can be fragile enough beating ourselves up about what we could do better.

Understand what we’re doing to fix it, and communicate it back, but part of your job is to filter out noise.

But when we get praise from the customer, please pass it on.

Any other anti-patterns you’ve seen?

Bootstrapping new developers

Start of a new day

When things are tough, do them often, to get more practice, as Sky Betting discuss in their recent blog post. It’s certainly something that I’ve noticed as we’ve moved to more regular releases, more regular planning and reducing feedback cycles.

One big thing I’m still learning how to do, where that doesn’t apply, is adding new developers to a team. I’ve been thinking about this after hearing The Improv Effect talk about onboarding to a company on .Net Rocks 1253 : Onboarding is Culture with Jessie Shternshus

My usual approach doesn’t apply, because good teams are stable, so onboarding is rare, which makes it harder to know how to bring new people on to the team. I always try to write a short introduction, on a wiki, to introduce the project and list the useful urls, and the getting started steps, and I ask new developers to update it with any differences they find, to keep it up to date.

Most of the team knowledge doesn’t come from there. It comes from the rest of the team. So the team needs to be built so that the onboardee collaborates with other members of the team from day one. Getting involved in code reviews, asking questions. I’m sometimes tempted to give as little information as possible to encourage asking questions, but that’s not how psychology works, and I’ve had more than a few gotcha moments where someone who’s been on the team for a while says “I didn’t know that was there” or “oh, so that’s why we do it that way”, and I have to revisit the onboarding story again, and wait for the next chance to validate it.

So, assuming your company has a good story for onboarding employees, how to you take a fresh start, or a start from another project, and build them into your team?

The tech diversity blind spot

 

Technology makes the world better. It promises to make our lives better. It will free us from work.

Except “The best minds of my generation are thinking about how to make people click ads”. And tech lives in social bubbles as well as financial ones. Apps designed for silicon Valley don’t always travel to the rest of the USA, apps for Western countries don’t always apply in the East, Facebook and Google aren’t always trusted, VR headsets that don’t work if you wear make up, facial recognition fails if you don’t have the same skin as the webcam software developer, or the photo auto-categorising application developers.

Sometimes the solution is to write technology in another bubble. Brazil, India, China, and many other places have strong home grown technology far more popular than the “global” leaders. Sometimes you expand your bubble, diversified teams, balanced teams, who are smarter than homogeneous teams anyway.

Sometimes you look outside your bubble. I get paid to write software that I will likely never use. Line of business applications, including public interfaces, for government clients. I don’t know what their business is until I ask. I don’t know how they work, or what is important to them. And sometimes I have to ask several times, and sometimes people can never understand or articulate what they do, let alone what they want, even after asking them in several ways. So what makes you uniquely qualified to understand what you do, or what problems you have, or whether those problems are universal?

If you want to know if your intuition applies to the population as a whole, make sure your stakeholders reflect that population, or accept that you are deliberately limiting your audience, because that’s what makes sense to you.

Up to speed with Git with recommended tools and books

On my current project, I introduced Git to a team used to Subversion (apart from the odd few), so I’ve had to research a few good resources for the team. I wanted to share these with you, for those of you new to Git, or wanted to get your team up to speed.

The best resource I found to start with was Version Control by Example by Eric Sink, which walks through a typical workflow in Subversion, Git and a couple of other version control systems. It’s great for picking up the basics for those coming from another version control system, or none.

I recently read Pro Git, by Scott Chacon and Ben Straub, which has given me a much better understanding of what’s going on under the hood, and has been a great resource to help me understand some of the problems the team have had with Git, and the patterns and principles required to fix them. It’s also got some great information for administering servers and repos, including setting up hooks, transport protocols, and various other details. I’m not sure I’d recommend it to a novice, but if you really want to get under the skin of the key-value datastore and directory structure underneath Git and want to know how and why it does what it does, it’s a great resource.

Pro Git recommends HTTPS as the transport layer, and that’s probably the easiest to set up for corporate networks with tough firewalls, but I have had problems with Github’s 2-factor authentication, and I tend to switch between a number of tools on the desktop, primarily SourceTree and Visual Studio 2013’s Git Flow Extension by Jakob Ehn for the Git Flow process, TortoiseGit for the merge UI, and the command line for everything else, which means the credential cache is often out of date, whereas SSH keys are much easier to keep in sync via Pageant, as installed by Tortoise. If you want to set up SSH keys yourself in Windows, one of my colleagues wrote this post.

For the members of the team less comfortable with curly braces, I’ve pointed them towards GitHub Desktop for the easiest way to stay in sync.

What are your favourite Git tools and reading?

DRM and plastic knifes

I tried to do something I wasn't allowed to do but they refused to tell me what I'm not allowed to do.

I thought Digital Rights Management was dying when iTunes no longer required it. I was wrong. It’s sneaking into HTML, it’s in coffee machines, it’s being discussed for JPEG, it’s led to the introduction of boot lockers to prevent users from modifying the operating system on their machine.

So what? Surely copyright holders have the right to protect their content, no matter that the entire music industry could be bought out with Google or Apple’s spare change. Surely they need the money to support the poor struggling up and coming artists, who they can’t afford to pay from streaming revenues. Surely we should just let Hollywood have their way?

And anyway, doesn’t restricting operating systems and the software we can install protect us from the bad guys? Apple will keep us safe in their protected iOS and App Store, right?

When you restrict tools via drm, only the professionals can use the full tools, but where do the next professionals come from? We’re suffering from a shortage of people who want to learn to develop software, and we’re putting extra barriers in place, so that we need specialist devices for teaching development in the form of the Raspberry Pi and others, because the main machines we use are locked down and restricted.

Knives are dangerous and they can kill, so Scotland has restrictions on their sale and carrying them, but we still teach children to cook, sharp knives and tools for sharpening them are still widely available, and you don’t need to be a licenced chef to use a real knife.

If we can trust society enough that we don’t need plastic knives outside preschool, fast food vendors and cheap airlines, why can’t we trust them with access to a fully functional computer?

Bad change : the hokey cokey requirements

It goes on and on and on

When I said I don’t trust change, there were a number of situations I was specifically thinking about, changes that actively cost time and money and decrease business value. One example of this is what I call the hokey cokey requirements.

You can identify these where the business value of the requirement is unclear. Where the product owner is making decisions on behalf of a user without verifying them, or not considering the impact on other requirements, for example, how changing a date for one screen will cause a dashboard somewhere else to report additional failures.

If you’re lucky, you’ll identify the requirement before you start implementation, but more likely, it’ll be in until you release to test or even live, and you’ll immediately get a change request to take it out again.

If you’re really unlucky, you’ll then end up in a tug of war between 2 teams.

How can you identify them in advance?

For some systems, you’ll have a well defined dependency graph between requirements, or at least enough prep time to generate the dependencies from the code prior to accepting the requirement.

For others, you’ll need a big user group to cover the edge cases, and accept that big user groups are not a comfortable fit for agile development.

How do you deal with them when you find them?

Make sure the right users are involved, at design and test. And make sure there’s no hierarchy to invoke. What works best for the CEO might break the workflow for the administration team. On the projects I tend to work on, keeping the administration teams happy are the key to a successful delivery and simpler support.

Sometimes the smallest possible change is best. Don’t build the full solution, build just enough for all sets of users to see the implications.

Make sure you understand the impact, so you can explain it clearly.

But most of all, if you see it happening, try and build a ripcord into the code to pull it out again, like a feature toggle, because despite best efforts, you may still hear “I know that’s what I signed off, but I didn’t expect it to do that!”

How have you dealt with hokey cokey requirements?

Engineers, ethics and scapegoats

Uncle Bob talked about the VW software engineers on his Clean Coder Blog. Go and read it.

There’s two important issues here. One is that the official line is that the engineers acted alone and no-one else knew what they were doing, in any QA, in any road testing, in any future tweak over the many years these cars were for sale. Although I note there’s no suggestion it was an accident, or an oversight, as in other European engineering failures.

So, if we accept this was a deliberate action, and that the engineers were aware of the consequences, at least in terms of the NOx and CO2 outputs in US and EU tests respectively, and this wasn’t a misconfiguration or falsely triggered test mode, then the engineers have some professional ethical questions to answer. I don’t know the full story about the process that led to this software being developed, signed off, and released, but it’s a good time to consider what our ethics should mean.

I hope you would all enforce ethics in your code, and would challenge any questionable decision from within or outwith the team. This is our first duty as professional developers, to ensure the integrity of what we produce, to ensure it meets all legal and appropriate quality standards, and does not mislead.

Unfortunately, it can be easier said than done. Standing up once and saying, this is wrong, can be scary, even when you have documents and a team backing you up, but when time pressure or financial threats hang over a decision, it’s far easier for that fear to turn into inaction or compliance with a bad decision.

So, before you get into that position, review your code of ethics, from your company, and from your professional body (in my case, the BCS Code of Conduct). If your company doesn’t have one, make one. Defer to a professional body if that’s easier, but make sure everyone knows it, and knows that the company will support them if they refuse to do something because it breaches the code.

It’s much harder to be a scapegoat when no code was breached. Take pride in your profession.