Ben Barden

Products - Projects - Process

by

Tech in plain English

When I was young, I wanted to be a teacher.

I’ve often found it difficult to learn new things. There’s always that hump you need to get past: when you go from reading and digesting, to starting to understand the core principles behind whatever it is you’re learning, and becoming more fluent. It could be a musical instrument, a foreign language, or a new thing in tech. I often struggle with getting past the hump.

The reason I wanted to be a teacher was to help other people to learn. Perhaps there were other people like me who found it hard to learn. Perhaps I could give other people guidance in where to start, and give clear explanations to help them learn.

In a tech role, I can still channel teaching (or training) in a number of ways, particularly through tech support. Doing tech support is an excellent way to connect with people outside your immediate team, help solve problems for those people, and learn a bit yourself. If the same issues are raised repeatedly, writing a guide could help. If the same names are coming up again and again, perhaps those people would benefit from some one-on-one help, or a repeatable training course.

A big part of this is communicating in plain English. If you’re using jargon right out of the gate, whether it’s in a Slack post, a written tutorial, or a group training session, there’s a risk you’ll lose a few people along the way. Different methods of communication warrant different approaches. I often write with myself in mind: not as a person who works in tech, but as that person who finds it difficult to learn new things.

If you’ve ever felt learning new things is daunting, well, you’re not alone. Not knowing where to start can make learning seem like a mountain to climb. My advice is to take it one step at a time. As they say – Rome wasn’t built in a day. Meanwhile, if there’s anything you’re confused about in tech, add a reply – perhaps it would make a good future post.

by

Clear cookies, cache, and reboot: not a swiss army knife for any support issue

Years ago, a lot of day to day business and personal matters had to be done in person or over the phone. We didn’t have smartphones with dozens (or hundreds) of apps. We didn’t have online ordering for pretty much any store you can think of.

Technology is in a great place. However, it means that many companies are now tech companies in some capacity – whether they realise it or not. As soon as you give people a way to self-serve – to login, to place orders, to change their details, or do a lot of things without needing to rely on back-office staff to do it for them – you’re providing a service.

Software is a great way to automate manual processes – but it doesn’t remove the need for people. If customers can place orders online, you’re going to need people to fulfil those orders. Not to mention the ongoing need for software development, and a bunch of other things.

When you’re in the business of providing software that people use, you’re going to need to support it. And this is where I’ve seen a lot of companies fall short.

The common line is to ask you to hard refresh the page, clear your cookies, clear your cache, restart your browser, and restart your computer.

In some cases, these can help – but not all.

One major downside of using this guidance first is that if it does solve the issue, you could be masking a solvable problem.

It’s worth taking a moment to understand what each of these actions does – and how to make sure you’re doing it properly.

Hard refresh

One of the common uses of a hard refresh is when releasing a new version of certain files (particularly JS / CSS files). A website might look odd following changes to these files – until you do a hard refresh (or clear the cache).

This is a bit of a cop-out, but also doesn’t scale well if you’re making lots of changes that affect lots of users. You shouldn’t have to ask users to do a hard refresh every time these files change. Putting a query string on the end, or changing the filename, will force new files to download across all browsers. Example:

<script src="assets.js"></script>

Any changes to this file will require a hard refresh to pick up. But you can do this:

<script src="assets.js?v=20210511"></script>

You could populate the bit after the ?v= with a timestamp generated by your build and deployment process.

Setting cache headers to expire will not immediately force the file to re-download, as the browser cache may ignore these headers for longer than you specify. It’s also hard to get this right across every file you’ve changed when you could just pop in a new query string.

I’ve been using the query string approach for years and it’s the only method I’ve found that works consistently.

Clearing your cache

I’m not going to lie, this has saved me a number of times. Today I was doing quite a bit of admin, and the site I was using was running more and more slowly. Clearing the cache fixed it.

What this does is remove temporary files stored on your computer that can make repeat visits to a website a bit quicker – so the browser doesn’t have to keep downloading the same files every time you visit the site – or on every page load.

Over time, the cache will fill up, and it’s worth clearing it now and again. In Chrome, the clear cache option looks like this:

Look for the part that says “Frees up 1.1GB” – that’s quite large. Even half that would be big.

Make sure you look at the “Time range” option, as by default that will only clear the cache for the last hour. If you set it to “All time”, it will clear everything. If the cache is your issue but you’re only clearing the cache for the last hour, it won’t do much.

Clearing your cookies

Cookies are small files that contain things like settings for certain sites. If when logging in, you’ve ever ticked “Remember me”, or “This is a private computer” (or a shared computer), chances are the site will remember that setting via a cookie.

So, if you clear your cookies, expect to be logged out of everything – and you may need to re-apply some settings for certain sites.

If you’re worried about not being able to login again, you should probably look at password managers. 1password and LastPass are both good. There are others too.

Clearing your cookies can be good to do now and again, but it can be quite annoying to clear cookies regularly. Instead, if you’re running into issues, it’s worth trying Incognito Mode in Chrome. This is like having a fresh browser without actually needing to clear anything. It’s a faster way to troubleshoot issues with a site you’re using, or perhaps with a site you’re working on as a developer or tester.

Restarting your browser

Chrome can be a bit of a resource hog, and sometimes restarting it is necessary. But if you aren’t also clearing cookies and cache, and you’re reopening your windows when you restart, you might find it doesn’t help that much.

It’s worth looking in Chrome’s task manager to see if any tabs are more resource-heavy than others. If so, close the ones you’re not using.

I’d also recommend having as much RAM as you can. I recently switched from a MacBook Air with 8GB RAM to a MacBook Pro with 16GB RAM, and I’m using a similar number of tabs (usually around 30 at a time). It’s not just the RAM that’s different between the two Macs – but the difference is like night and day. Large Google Sheets can be particularly heavy-going, and my MacBook Air was borderline unusable with a much smaller number of tabs open.

In short, restarting the browser might not make a lot of difference – though it is necessary if you have a browser update to install.

Restarting your computer

These days, restarting your computer should be a rare thing. Outside of operating system updates and certain software updates, a full restart can be pretty pointless when most of what you do is in a browser. If you must, restart your browser first.

What to do instead

Instead of suggesting a hard refresh, clearing cookies and cache, restarting the browser or restarting the computer, another way would be to do the following.

  • Find out which browser, browser version, and operating system the person is using. Look out for any particularly old setups, such as old versions of Windows, old browsers, or old phones and tablets. Aside from it being harder to support these older versions, using unsupported software or devices is a security risk to the user.
  • Find out, step by step, what the person is doing and what happens as a result. This will help you identify if things are working as expected – and also gives you the opportunity to try for yourself.
  • Ask if any error messages come up.
  • Ask for screenshots.

Listen to the feedback – and pass it on to someone who can review it, and either deal with it or help to give an appropriate response.

As a software company, tech support is part of customer support. By taking the time to deal with any feedback, you can identify any issues that could be fixed – or any improvements that may be needed. Great software means happier customers, and fewer people needing to call to report issues – so a win-win for everyone.

by

How many projects should a team work on at a time?

I recently posted on LinkedIn, asking for suggestions for post ideas. This one comes from James Nowell:

I would love to know what your thoughts are around the maximum number of projects a team should be working on at any point in time. The ideal number is one for pure focus time however I don’t see that as realistic in an agile, fast changing world. What do you think is optimal?

In my view, it’s not so much about a specific number, but about how your pipeline of work is managed. However, I’ll come back to numbers a bit later on.

Your first goal should be to make sure there’s a logical and consistent entry point to the team – a manager or a triager – so that new work requests are given some kind of assessment. Teams can work on many things at once – but as time is precious and you probably have a backlog you’ll never reach the end of, it’s essential to prioritise.

Without checks on new work coming into the team, a team can quickly become overwhelmed. It’s easy to say “yes” to every request. It’s easy to get distracted by the latest shiny thing – whether it’s a cool technical tool, or simply a bloody good idea from one of your stakeholders. But if you try to accommodate every request, or you keep getting distracted by new things, the output of the team will grind to a halt.

The “entry point” person – let’s call them the triager – is essentially a first line of defence, to protect the team from interruptions – as it will take longer to complete a task if you keep context-switching than if you do the task from start to finish.

The triager can also be the face of the team and give requestors a consistent message about what work can be taken on. It’s fine to say no to things. It’s also fine to say yes, but not until projects A, B and C are done. And it’s important to watch out for the type of work that should jump the queue – where there’s a big benefit to the business, where there’s some kind of legal deadline you need to meet, or where there’s a project you can work on to unblock some other work.

It’s also really vital for the triager to have a good relationship with the team, which means not accepting every request and telling the team they just need to do it. The triager should either know enough about the work the team is doing, or be able to learn about it, so that they are doing more than passing information back and forth. Being able to answer questions about whether something is practical can be useful too. But it’s not essential for all teams. The triager role works best if they can collaborate with the team to find out how they can be helpful and useful, and not simply add an extra layer of bureaucracy to the process.

OK, so that’s quite a bit about prioritising. The next thing to look at is how to organise the work you do want to do, and spread it around the team. The target number of “how many projects should we work on” has a cop-out answer here – “it depends” – but it really does. For each project, or block of related tasks, you should consider the following:

  1. Is it important for everyone to understand the work that’s being done? For projects that will deliver something that becomes central to a lot of your future work, you may want to get everyone working on the project – or at least set some time aside to talk through what’s happening, whether that’s before/during/after the work is done.
  2. How many people have the expertise to do the work? If one person is an expert, you’re definitely going to need them involved. It could be worthwhile to share their knowledge around. But if you have, say, 6 people in the team and only 1 has the knowledge to do most of the work on a project, it might be better to get 1 or 2 other people to learn alongside the expert, and have the other 3 people working on other things in parallel. They can always pick up the skills later.
  3. Is there enough work to share across the whole team? If you have a big team and not a lot of distinct work on a single project, you might not want to have the whole team working on one thing. However, you could pair people up, especially if points 1 or 2 apply.
  4. Is it possible, or practical, to do the work in parallel? You might not want to put 5 people on separate tasks if they need to be done in sequence.

There’s plenty to bear in mind with this.

So, what’s the maximum number of projects you can – or should – work on at a time?

In theory, the maximum number of tasks you can work on at a time is equal to the number of people in the team. But if each task is for a totally different project, that’s not really teamwork – you’ve just got a group of people each with their own tasks.

It can be really valuable for a team to “swarm” around a common goal, rather than having each person working on something totally different. It aids collaboration between team members. And I’d argue it’s better to have one thing “done” than 5 things in progress. You can read more about this in my post: Getting things done.

In 2021, I’m trying to write more regularly on my blog – hopefully one post per week. See my progress so far here: Weekly blogging in 2021

by

Practical tips for organising your backlog, from my home improvement project

For the last two weeks, I’ve had a bit of a break from blogging while moving into my new home. This week, I’d like to write about taking a backlog of work or ideas and getting them organised and ordered.

However, instead of talking about software projects, I’m going to use my recent move as the example. Since moving in, there’s lots of things I want to with the place — so it makes sense to organise these into some kind of order.

What you need:

  • Post-it notes, Sharpie pens, Whiteboard, whiteboard markers
  • Or, a suitable digital alternative

Step 1: Get the ideas written down

First, we write down everything we want to do.

Grab a stack of post-it notes and a Sharpie (per person) and start writing things down. Stick to one idea per post-it note. Keep the text brief.

You can use online tools to achieve a similar effect — particularly while we are working from home, but also if anyone in your group is working remotely.

With several people involved, you may want to timebox the task to 5–10 minutes, or you’ll have more ideas than you can realistically handle.

Step 2: Review and rank the ideas

First, read all of the items and see if they make sense. Are any of them too broad or too big?

For instance, “electrical work” would be too broad of an idea for the things I’d like to do in my flat. Instead, I can break this down into a few specific things — replace fuse box, add new plug sockets, replace socket covers, replace light fittings, and so on. Or, these could be broken down further — replace light fitting in lounge, replace pull cord in bathroom, replace light switch cover in lounge, and so on.

Look out for any duplicates and stack those together. Then, you can rank the ideas.

There are a few ways to do this. Giving each person 3–6 votes and taking the items with the most votes is fine if you don’t have dependencies, or if there’s not already a natural order — i.e. things that you want to do above anything else — or things you have to do.

You can use “MoSCoW” — i.e. Must have, Should have, Could have, Won’t have — to rank which tasks by order of importance.

Or you could do what I did and simply use High, Medium, or Low.

Step 3: Order the ideas

If you have a lot of ideas, you might not get to all of them yet. Start with the ideas with the most votes, or those that are the highest ranked.

Some things can be done in parallel, while others might have to be done before others — or you might want to push a few important things to the top. In a new home, safety is very important, but then so is heating, which might include replacing the windows, or getting new radiators. An electrician could do lots of small things in one day, but it’s probably better to focus on addressing any potential hazards before making the light switch covers look nicer.

The ranking of ideas will help, but the highest priority ideas might not be the ones you can do first. Replacing the windows in my flat is something I’d like to do right now, but there’s a lead time of a few months. The job is all booked in — but I can do other things in the meantime.

To actually write up the order, I titled up 3 columns on a whiteboard:

  • To do
  • Next up
  • In progress

For each task I’d like to do next, I’ve put them in the “Next up” column, in the order I’d like to do them. As a task gets underway, I move it to the “In progress” column. Other ideas I’d like to do soon, but which aren’t top priority, go into “To do” for the time being.

I’ve decided not to have a “Done” column — instead, when I task is done, I add it to a Google doc that lists out everything I’ve completed so far. And I’ll take the post-it note off the board at this point, freeing up space for other tasks.

You might find you have more tasks than you can fit on the board — and that’s fine — you can set them to one side for now. I’d recommend writing these up somewhere, either keeping them in the backlog of your issue tracker, or keeping a short list documented in Google Docs or Sheets.

Step 4: Keeping the board up to date

In a previous post, I explained that the Agile board should reflect reality. It’s all very well to get things in a nice order, but you need to keep the board up to date, too.

That means:

  • moving things to In progress when work starts;
  • moving things to Next up when space frees up;
  • changing the order of tasks as required;
  • adding more things to the To do column as space frees up.

While you can (and probably will!) do this in digital tools, there is a lot to be said in having a physical board. Moving a post-it between columns can feel good — seriously, try it! — I’d say it feels better than moving things around in something like Asana or Jira.

Having limited space is similar to a WIP limit, but it’s much harder to circumvent when you physically don’t have any more room for post-it notes. I guess you could get a bigger whiteboard — or a second one. I will admit to having just bought my second, although they will be used for different things.

This isn’t a particularly new or groundbreaking process, but keeping my home improvement ideas organised in this way has helped me to feel more on top of them, and to see progress being made. It’s very rewarding, and I’d recommend trying something like this for any project you do — tech or otherwise.

In 2021, I’m trying to write more regularly on my blog – hopefully one post per week. See my progress so far here: Weekly blogging in 2021