• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Ben Barden

Product management and process tips

  • Ben Barden
  • Home
  • Music
  • Blog highlights
  • About
You are here: Home / Archives for Tech

Tech

5th August 2021 by Ben Barden

Thoughts on tech support

In tech, providing some kind of support is essential. However, I’ve found that a lot of people don’t want to do it.

Maybe I’m weird – but I quite like tech support.

Support is a great way to learn, and can be quite varied and interesting. Sometimes it’s given to new or junior team members – but I’d argue it’s important for everyone to do it now and again. Tech rarely stands still, both within a business and in the wider industry. Support gives you a snapshot of the types of things that people are dealing with day to day.

I find support to be quite social. I get to interact with far more people when doing support than if I’m buried in a project. Don’t get me wrong, I like the projects too – but I like having the opportunity to do a bit of support too.

We use Slack for our support, and I’d say it helps with keeping things friendly. Thinking about it, almost every company I contact for support does it all via email. Credit to the fine folks at Kolide for opening up a shared Slack channel with us and giving us a great way to communicate with them, so we can reach them on Slack and not worry about email.

I also find it immensely satisfying and rewarding to be able to answer questions and solve issues for people. The “big ticket” items such as rolling out Okta are huge, but sorting out smaller things is also important.

One downside is if you’re trying to focus on something and you keep getting interrupted with support requests. Teams can solve this though. I’m in a team of four and we each do one week of support every 4 weeks. It works well and keeps things fair.

Sometimes the same things come up repeatedly, and you find yourself answering the same things over and over. This is a good opportunity to write a few guides. It’s much easier to share a link than keep writing the same answer. And when the same things keep coming up, this can help you identify issues with tooling, or process improvements you could make.

I think there’s a lot of good reasons to do support now and again.

Filed Under: Tech

30th June 2021 by Ben Barden

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.

Tech support and training go hand in hand

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.

Plain English

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 the saying goes – Rome wasn’t built in a day.

Filed Under: Tech

3rd June 2019 by Ben Barden

The future of iTunes

Update, 4th June 2019: The BBC have confirmed this news. Notable:

iTunes will remain unchanged on Windows platforms, and downloads will still be available in a sidebar on the Apple Music app for Macs.

My original post follows.

Last week I read a few articles about the alleged closure of iTunes, with the suggestion that Apple will announce separate apps for music, TV and podcasts.

These articles talk about the introduction of Apple Music likely sounding the death knell of iTunes, citing how iTunes originally gave listeners a legal way to listen to music way back in 2001 – replacing earlier alternatives such as Napster.

Spotify is the obvious successor, offering a catalogue of music for a monthly fee.

But if iTunes is retired, what’s the best way to play music you bought in the past and don’t want to lose access to if you stop the neverending monthly fees? How about music that isn’t on streaming services at all?

I’m sure I’m in the minority here. Who cares, right? Spotify is easy to use (I do use it regularly) and it works well across all of your devices. I’m even more on board with Spotify than I used to be, having ditched Apple’s iOS ecosystem and plumped for the Samsung S8. Transferring MP3s to an Android device from Mac OS is pretty janky.

Still, I have thousands of MP3s that I bought individually from dance music sites such as Juno Download, just so I could make my own compilations. Some of the tracks are on Spotify, but a good 50% of them aren’t.

When I sold almost my entire CD collection due to most of it being on Spotify, I kept a bunch of dance collections – both mixed and unmixed – as they weren’t available to stream. Dance compilations do seem to be the running theme here.

I guess I shouldn’t complain too much, though. Currently, almost all the music I want to listen to is on Spotify. That’s not the case when you look at the minefield of TV series and movies. The current crop of Netflix, Amazon, Google Play and iTunes (or not) doesn’t cover everything. How many monthly fees does it take to build a collection of the shows and movies you love? Furthermore, how much of that content will be there in 12 months time?

With a successor to iTunes potentially coming soon (and it’s probably overdue), it makes me wonder if Apple will try to compete with Spotify head-on, and aim to grab some artist or album exclusives – similar to how some content is only on Netflix or Amazon. I’m not sure what’s worse: the near-monopoly of Spotify, or the fragmentation of content across different streaming services. Still, choice is good.

It remains to be seen whether playing offline files such as MP3s will continue to work in an iTunes successor.

Filed Under: Music, Tech Tagged With: iTunes, spotify, streaming

14th May 2018 by Ben Barden

Use Makefiles to quickly run common commands

A tip I picked up from work is the use of a Makefile to set up short aliases for commands you run often, but that are a pain to type, or you can’t remember. I find this particularly useful as I code fairly intermittently these days, so it’s easy to forget the exact syntax of certain commands.

A good example is how to run unit tests. This varies from project to project, but is something you’ll probably want to do fairly often.

To start, create a blank file called “Makefile” and put it at the root of your project. Then insert the following code:

[code]
SHELL:=/bin/bash

unit-test:
[TAB]./vendor/bin/phpunit
[/code]

Change /bin/bash to the location of Bash, and modify the ./vendor/bin/phpunit line to do whatever you’d normally type in to run your unit tests.

You’ll need to replace [TAB] with a Tab character. Spaces won’t work. Make is strict in this regard.

Save and exit the file. Now open a Terminal, go to the root of your project, and type:

$ make unit-test

All being well, this will run your unit tests.

In the Makefile, “unit-test:” indicates the label you’ll need to run after “make” to run the command. You can add multiple lines and multiple labels – for instance:

[code]
echo-ab:
[TAB]echo ‘A’
[TAB]echo ‘B’

echo-cd:
[TAB]echo ‘C’
[TAB]echo ‘D’
[/code]

If you have lots of commands, this method can get a bit messy. It’s handy for small projects where you only have a few things to include but can’t always remember them.

Filed Under: Tech Tagged With: make, makefile, unit testing, unit tests

  • Go to page 1
  • Go to page 2
  • Go to page 3
  • Interim pages omitted …
  • Go to page 6
  • Go to Next Page »

Primary Sidebar

Substack

My Substack blog

Recent Posts

  • My Substack blog and newsletter
  • Review of 2022
  • How to practise good etiquette in team updates
  • How improving the Okta SMS flow would reduce support requests
  • Flexible working in 2021

Archives

Categories

Handcrafted with on the Genesis Framework