profile

Hi, Iā€™m a creator

šŸ„§ Pie Mail - fix your organisational bugs, get organisational hugs šŸ„§

Published over 2 years agoĀ ā€¢Ā 4 min read

ā€‹

Hey y'all! Time for a piping hot fresh slice of pie-mail!

I've just ticked over three months at my job. I'm finding getting the balance of being both a manager and an individual contributor really hard. In any given week, I feel like I do one or the other well - but never both.

From what I've read, this is a pretty normal way to feel - but - that doesn't make it any easier!

It's nice to take a 'mental break' and put this newsletter together. Here are some interesting things from the last couple of weeks!

Enjoy!


šŸŽ“ This week I learned... šŸŽ“

...about Organisational bugs!

I think this will be the third newsletter in a row that I've shared content from Maaike Brinkhof, I guess I'm a fan. She recently published this really frank blog post - it's about some of the frustrations she has with being a tester in an environment optimised for developers.

It's really interesting, but the thing that stuck out to me is the concept of 'organisational bugs'.

For some time I've been trying to nail down some of the things that separate a junior or intermediate tester from someone senior, and I think that organisational bugs is one of those things.

What I mean is - at some point in my career, I found myself moving away from finding problems in the product, and moving towards finding problems in the 'way we do things'.

ā€‹

ā€‹

I had a little think about some of the 'organisational bugs' that I've come across recently:

Regularly SSHing into Production to fix a problem

This one is a clear sign to me that there's something wrong. We should never have to log directly in to production to fix something. It's bad because it introduces a lot of unnecessary risk. It also is a waste of engineering time, if it's something that happens frequently.

If the problem is caused by a bug in the product, the bug needs to be fixed. But, as an organisation, we should prioritise putting tooling in place that means we don't need to log on to production machines to make fixes.

Not knowing when changes are going in to Production

Have you ever had this? Where you get the 'surprise' that something is in production. Maybe it hasn't been tested yet, or you didn't even know it existed?

This, to me, is a sign that the release process is broken. The risk here, is that you've ended up with untested code in production. It's completely unknown whether it works or not.

As an organisation, visibility is really important. When code is merged, deployed or released, it should be really obvious what has happened. This can be controlled through automation and notifications, and keeping deltas small so changes don't get lost in the noise.

One person being the source of knowledge for everything

This is the situation where, every time there's a problem or a question, it's that one person that you have to turn to again, and again. This is a risk because it means knowledge is not being shared. If that one person leaves, they take a lot of knowledge with them.

It's also a terrible use of that one persons time!

As an organisation, the fix for this is to write stuff down. As much as possible, people should be able to self source the knowledge they're looking for.

ā€‹

Upon reflection, I'm not sure if my interpretation of 'organisational bugs' is what Maaike meant in her original article, but, it's been a really useful reflection exercise for me!


āœØ Some interesting links āœØ

Things I believe about software by Paul Swail:

I'm not sure how I came across this post from Paul Swail, but I've had the tab open for a long time. There's some really good points in here, although I'm not sure I agree with all of them (like the unit tests one). But, definitely worth reading anyway.

ā€‹

How to make code reviews stress free:

I really like FirstAML, and the way they operate. This is a cool post from a while back, on how they 'size' their feedback in code reviews. I'd like to try it.

ā€‹

Tea Time with Testers:

There's a new issue of Tea Time with Testers magazine! I have barely broken through the first couple of pages, but I'm confident there'll be some good content - there usually is!

ā€‹

Print Style Sheets:

ā€‹This post from Manuel Matuzovic about print style sheets is interesting and informative in it's own right. But it's also reminded me that, well, sometimes people print things from their browser - and it seldom, if ever, gets tested.

ā€‹


šŸ§© Puzzle time šŸ§©

Here is some HTML source code. It's one section of a bigger HTML page, and it represents a couple of dialog boxes.

ā€‹

ā€‹

In this particular product, this is how dialog boxes work:

When one of the dialog boxes appears, the 'display: none' is removed from the opening div tag, so the box is visible.
When it is closed, the 'display: none' style is added back, so it is hidden again.

With me so far? Great!

So, I was writing some Cypress tests for this page. My tests are to check that the dialogs open, and the buttons work. But one of the tests failed, with this error message:

"cy.click() can only be called on a single element."

Can you see what might be wrong? How might you go about fixing it?

Bonus points if you find the bug that exists in one of these dialog boxes too!


šŸŽŖ Events coming up šŸŽŖ

Events for those of you in New Zealand:

Lightning talks at Digital Design meetup (Auckland, August 2):

Come and hear Evandah from Rocos and Diana Xavier from Vend at the Digital Design meetup. I had the pleasure of meeting Diana at Product Talks a few weeks back and really like what she has to say - so - get along there!

ā€‹

Events for anyone anywhere!

The future of testing on mobile (August 10)

Another Applitools future of testing event, this time targeted to AU & NZ timezones. Sam Connelly, one of my favourites, is speaking, so should be worth checking out!

Collaborating on Code UnConference (August 12)

CodeLingo are hosting a Virtual 'Unconference' all around the subject of collaboration.

Places are really limited on this one, and it sounds pretty interesting. It looks to be lined up for both US and NZ timezones, so if it sounds like your sort of thing, check it out!


šŸ‘‹ Thanks for reading! šŸ‘‹

Can you believe we're well over half way through 2021 already! Time flies!

Take care out there every one, especially those of you reading from some of the really COVID affected areas at the moment. Get those vaccines, follow the guidelines, and hopefully we'll be out of this mess soon.

Reach out to me any time on LinkedIn or Twitter.

Cheers,

James a.k.a. JPie šŸ„§

ā€‹https://jpie.nzā€‹

Hi, Iā€™m a creator

Read more from Hi, Iā€™m a creator

Hi all! It's flooding and cyclones here in NZ, especially those in Auckland. I hope this email finds you safe - if you're being affected by bad weather, please stay inside until this all blows over! šŸ¤ COLAB Before we get too deep into it, I'd like to give a small shout out to COLAB. I had the chance to take part in COLABs Equitable Product cohort last year. It's eight weeks of conversation and learning with like talented peers; covering subjects like data ethics, accessibility, inclusion and...

about 1 year agoĀ ā€¢Ā 4 min read

Well hello there! Happy new year everybody. I hope you all had a good break, and are well rested heading in to the new year. I've had a good long time off, getting some rest after a busy 2022. I've found myself really eager to get back to work though, I'm looking forward to what 2023 will bring - I hope you are too! šŸ™‹ā™€ļø The value of dedicated testers In my last email, I wrote about the importance of engineers testing their work (and not just leaving it for testers). But this leaves an...

about 1 year agoĀ ā€¢Ā 4 min read

Welp, the end of the year is upon us! It's been a long and busy one. It's definitely been fun, but I'm ready for a break! I've had some interesting conversations over the last couple of weeks about quality, and the lines of responsibility - so - that's the subject of today's email. Enjoy, and see you in the new year! šŸ’» Programmers and Engineers My first job was in a busy office. Our office constantly seemed to have a dirty kitchen - a pretty common office problem. Instead of rinsing their...

over 1 year agoĀ ā€¢Ā 3 min read
Share this post