Many times during the past year I have found myself wishing I’ve had a whiteboard. Some things are so hard to explain without drawing and on a remote call, you don’t have many options. I even stopped doing workshops for a long time unless we could meet in the office.
I have always felt that that having a whiteboard speeds up communication a lot. You can draw, point, move post-its on it. It’s one reason I like to work with a colocated team and it is something remote working has taken away.
This is why I’m happy to share that…
Of course, it would be ideal if we can prototype and test but if we are to make the deadline we need to start development now. Maybe next time.
I’ve heard this many times. Confession, I have even been in the position of saying it. But lately, I have been feeling that we don’t have time not to do usability testing.
In this post, I hope to show how it can save more time than it takes. That even 30 minutes can be enough to get started.
Usability or user testing may sound complicated. Like something reserved for big companies…
Even if you are not using Firebase, bear with me.
This is still applicable for any microservices or when using NoSQL or other types of de-normalized data.
Before we get into it, let me explain what I mean with some of those terms:
We should never work on assumptions but we definitely should work with assumptions.
A PO I once worked with used to threaten to slap us if we ever used the words “I assume”. We did a lot anyway and thankfully we never got slapped 😂
His point was that we should never, ever, work on assumptions because it means we will likely get something wrong and do rework.
This might create a fear of assumptions though, which is lethal because really, any fast work we do, is done by heuristics. Previous experience and generalisations that help us make quick decisions…
Our app teams at Styler does an excellent job of avoiding bugs but also fixing them quickly when they pop up. The first step in this lies in finding out when they happen.
Working on server-side it’s so easy to collect, monitor and report on logs. They generally come from the same place. Be it a log file or stderr stream, we can easily read it alert on errors. Many server software even comes with built-in tools for sending emails on crashes if not even more sophisticated.
On client-side, however, apps will crash, hang or simply go blank without us…
When it comes to evaluation season, no one loves it. It can be hard to see the reason why we need them, even as a manager. Maybe it’s for legal reasons or to record performance issues. Probably it is trying to set fair salaries.
You probably agree that the performance review, quarterly, annually or otherwise, isn’t the thing you love best about your job. After all, I think the only time a performance review feels worthwhile is when you get or get to give a good raise or praise.
In our day-to-day work, we usually do all kinds of reviews…
Reporting bugs isn’t the most fun job I have as I try to help my team manage our project but, it’s needed.
Having worked a lot with testers in my previous jobs I’ve often found a lack of understanding in what can really help developers narrow down and fix a bug and as I was thinking of sharing this with my team today, I figured I’d just write it up instead.
The format I use is:
But together with this format, what I’ve found invaluable is the use of pictures and…
This weekend I spent fourteen hours building an app. I even got it released to the App Store. Proudly, I handed over the phone to my partner saying:
Look what I made! Will this help you study Swedish?
The response was a brutal:
It’s cute but.. no
This reminded me once more that:
Failing fast is a household phrase these days but I wonder how often we apply it. Even with my fourteen-hour project I couldn’t help but feel a sting of failure as my output was shot down.
But it is true, failing fast is good, and I got really good feedback out of it.
Read the full story at my official blog, greycastle.se