Remember the high-achievers at school or university, they’d be stressing and over-studying for a test in a class that they didn’t even need! (I remember, I was one of them).
“Whatever is worth doing at all, is worth doing well.” — Philip Stanhope, 4th Earl of Chesterfield
In the workplace however, and especially in software development, this can lead to opportunity costs, over-engineering, complexity, and tech-debt!
I witnessed this first hand when a task given to a new team member (let’s call him John) to fix a Xero to Slack integration workflow. Slack notifications were sent to our customer team based on certain invoice conditions in Xero. …
“Smart Code” are the lines of code that try and save you or your users time and effort by doing more work than is expected.
As a hypothetical example, imagine an
Article class that has a method named
publish(), and it works like this: First it autocorrects any spelling mistakes, and then sets the status to
"published". This ensues writers always appear professional. Cool, right?
Not so fast. Imagine you’re the one writing an article for other developers. After hours you’re happy with it, and you click publish. Suddenly the published version shows all the camelCase variable names you wrote with spaces and in a different case. What a pain! You quickly go back to the editor, fix the errors, and hit publish again. But it autocorrects it again! …
Why isn’t it easier!?
Product Designers and Developers both share the same responsibility for creating and maintaining products. We both love to solve people’s problems, and dream of providing that perfect experience to end users. So why can working together seem so frustrating at times. And how can we fix it?
In the spirit of collaboration I teamed up with my friend Lisa Jacquiot, a talented Product Designer to co-write this article!
Assembly lines are great for making repeated processes really efficient. The problem is that when we’re developing new things, nothing is a repeated process. …
Something that is simple to grasp, and easy to use. Something you can pick up with no prior knowledge and be able to utilise to help do whatever you’re trying to get done. Surely everyone wants that! So why on earth are there so few intuitive products?
The answer I’ve come to is this:
I don’t think it’s clear how to design for intuitiveness.
How do you create intuitiveness? Do you just have to remove features? Can only simple products achieve it? Is it just all about a good onboarding? How about a clean UI? …
Organisation charts are hierarchical diagrams usually showing “upper management” at the top and then branching down to their direct reports, and so on. The CEO/boss makes all the big decisions and the control flows down. Does this sound right to you?
While this is perfectly accurate, it doesn’t promote a healthy frame of thinking for employees at any level. It promotes the idea that to grow you have to climb on top of others, rather than to support others.
This is where the upside-down organisational chart comes in. It flips the frame of reference. All employees sit above the CEO/boss! With this view it’s also possible to add customers (who sit at the very top), and products into the chart to show the full hierarchy of support. …
Clean Code is code that is easy to understand, easy to use, and easy to modify.
You know when you see clean code because it’s a pleasure to work with, it seems intuitive and straightforward, bugs are easy to spot, and it allows you to develop new features at a fast pace even in a large codebase.
So how can you achieve this holy grail?
There are many books and articles that spew out a whole number of rules to follow to achieve “clean code”. These rules include guidelines for declarative variable naming, small pure functions, DRY (don’t repeat yourself), class length, one class per file, and more. …
“I have a killer app idea that is going to take over the market. The app supports researchers with participant recruitment, which is a huge pain point. It’ll be hard, but I’ll validate it with potential customers and then I’ll build it. Lean of course - Build, measure, learn.”
That was my thought process when starting the tech startup Rulo a year ago (named Curio at the time). I thought I had the product idea that could change the world, and with sheer determination and laser focus on product development my co-founders and I could make it happen.
I could not have been more wrong. …