Reducing waste by timeboxing

Sometimes we have a task to do, but distractions get in the way. We know we can’t multitask, and we want to be available, especially if you are in a leadership role.

But sometimes you just need to get something done.

Don’t be afraid to block out 30 minutes or half a day to focus. Put it in your calendar so everyone can see, and go somewhere private where you won’t get interrupted unless it’s an emergency. Work outside the office if you have to.

And limit your time. If you know you only have an hour (or 2 pomodoros) to finish something, you will be focused on it for that time. But pomodoros are good to remind you to take a break, re-energise and get back in the flow (but not Flowstate – I like the idea of an app that keeps you focused Mission Impossible style, but a lot of the writing I do needs a lot of thinking too).

Be clear about what you’re doing so that your team feels they have the space to do it when they need to.

Advertisement

Naming things is hard – Microsoft’s Core problem

There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.

• https://twitter.com/secretGeek/status/7269997868

Microsoft are changing the name of the next iteration of .Net – what was .Net 5.0 is now .Net Core 1.0, and like Rick Strahl, I like the idea, but I’m not find of the timing. Although, as it’s pre-release, anyone writing production code on it was playing with fire anyway. I’m not a big fan of the naming scheme though.

The timing issue is an easy one to solve. I’ve had projects running under placeholder codewords for months whilst the business agreed a proper name. Microsoft has been doing this for years. No-one expected to see Windows Chicago, Windows Threshold or SQL Server Denali. No-one would have expected to ship .Net Sapphire (hey, they’ve admitted that were going after the Ruby developers 😉 ) Everyone knew they were codewords, to be replaced pre-release once marketing figured out what year it was being released – or the regression testers discovered how much old code thought 9 < 7.

The problem I have with it is that ASP.Net Core sounds like part of the family that includes ASP.Net MVC, ASP.Net SignalR or ASP.Net AJAX, whereas it actually replaces the ASP.Net part with its own .Net Core stack. I can’t at the moment think of a better way to name the ASP.Net Core though, without losing the ASP.Net brand.

The naming works when you compare .Net Framework to .Net Core, and to me it’s as natural as when Netscape open sourced Navigator to give us Firefox (once they managed to choose a unique name). It was from some of the same team, and it did the same job, but the new one was leaner, faster and more focused.

Naming things is hard, but starting a new roadmap and resetting expectations is definitely the right thing to do. .Net and the ASP.Net frameworks have needed a decent overhaul for a while to fix the untestable, interdependent ball of mud that the .Net framework install had become. I like the new Core world, with NuGet and Gulp and Grunt, and Github at the heart of development. This is not a Microsoft I thought I’d see when I was at the ScotAlt.Net meetings all those years ago.

Alt.Net is dead. Long live .Net Core.

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.

The zeroeth rule of network security: don’t trust your users

I realise, when I talked about the three rules of network security, and the fourth about encryption, I forgot the most important part of security practice: people.

We know people are a weak point. Watch “Mr. Robot”, watch “The Real Hustle” or “Catch Me If You Can”, or read this to understand that “It only takes one thing to get someone to reveal their password: asking”

So we try and enforce stronger passwords and hope users have a decent password manager, or at least a hidden physical copy, and don’t reuse passwords.

We try to add 2 factor authentication so there’s less chance of anything happening if one is lost, and hope we’re safe from phishing attacks.

We try to train users.

But security is an inconvenience. It hammers usability, because we want it to be unusable for the bad guys. (and it’s not just software, go to the right Scottish islands and you’ll find unlocked cars and unlocked houses).

If you’re a bank, you optimise for failure. Cancel the old card and send out a new one. Block the online account until you get something in the post. Log every change for users to review. Rollback transactions, when fraud has been proven. But even after optimisation, failure is expensive. It’s not an option generally open to the rest of us.

Agile : The importance of heartbeat

Scrum is built on the weekly/bi-weekly cycle. It provides a structure, a routine. It minimises surprises. You know that the planning session is on a Friday, for the work that starts on Monday, so you can get things on order on Wednesday.

It lets you see what’s coming.

It’s not about process, it’s about expectation. The more you can plan, the less you have to think about. You know when it’s coming and you can line things up in advance.

Have a heartbeat. Know what happens on a Monday, even if you don’t know yet what you’ll achieve.

Becoming a technical lead

A new year has arrived, and maybe now you think it’s time to take on a new challenge. You want to become a technical lead, or maybe you can see that your project needs one and no-one else wants it. You’re apprehensive, and unsure you’re ready. It’s OK. Everyone is an imposter.

Set yourself some stretch goals, something that seems just out of your reach. Throwing yourself in at the deep end is good practice, because you might ask your team to do it too, so you’ll be able to use your experience to help. You’d be wise to have a mentor at this point, to make sure you’re not being too ambitious, because you do want some early successes to give you the confidence you’re going to need later on.

I’ll assume you have the technical knowledge, so think about the things that set you apart, now you’re a leader. You have to guide the team to the goal, and make sure there’s a common purpose, and a team culture to follow. That’s all down to you. You have to know your team, and their strengths. You need a strategy to deal with disagreements. Read Peopleware: Productive Projects and Teams and understand that people are not interchangeable components, despite what your high-level plans might fool you into thinking. You are an individual now, your team are individuals too.

Ask questions of your peers and the community to understand what technical leadership means to them.

Learn from those who’ve done it before, and have offered up their wisdom. One of my colleagues is writing about his learning path as he goes, and there’s a lot of great information about keeping the bigger picture fresh, and understanding your team : Mike Childs – blog posts on leadership. But don’t forget to look after yourself too, as Patrick Kua explains : 5 Tips for Being an Effective Tech Lead | ThoughtWorks

Good luck on your new challenge, wherever you are.