Today we live in a time where building and delivering high quality software, fast and frequent is a necessity. Having assembled teams who have done this relatively well and having worked with teams who have not managed to do this so well, I have come to appreciate certain qualities of teams that I thought I should pen down. So here we go.
They self-organise
The team can plan and get something meaningful done without needing a manager to guide them or define things for them. They understand the big picture and collaborate within the team to figure out the what and the…
TL;DR they don’t.
It’s been quite a while since I adopted RxJS and fell in love with the idea of Reactive Programming. It takes time and quite a bit of practice to really get to know reactive programming and learn to appreciate it. When you start playing with RxJS one of the first things you would notice is the similarities of an Observable to a Promise. The next thing you would do is google “promise vs observable” and the internet will explain to you what the differences are quite well.
I’m baffled by the number of people I come across…
When you travel out of your resident country there are things that you miss quite often. One of those things that most people end up missing is the caller-id when you receive calls from your resident country. This happens mostly because people tend to save phone numbers without the country code for local numbers. This bites you back big-time when you are traveling. I recently moved to Singapore from Sri Lanka and it has been a blast, except when I get calls or WhatsApp messages.
So I wanted to convert all my Sri Lankan contact numbers that did not have…
Picking the right software architecture/design is just like picking the right tool for a job. You use the wrong tool and then everything may seem a little bit more difficult or little bit more messier. When it comes to software architecture/design though, there is no such thing as the “correct” tool for the job. Most solutions would work and the difference would be relative. It really boils down to how optimal a solution is, for the problem(s) at hand.
When we started rebuilding Creately from scratch, we revised a lot of our design and architectural decisions. One of them was…
RxJS is something I have come to appreciate quite a bit in the recent past, in it’s ability to manage asynchronous operations. It really is a shift in the programing paradigm of how you look at asynchronous code. If it is adopted consistently well across your app, you can see a significant improvement in how you manage asynchronous code. In this post I want to talk about a particular principle of Observables. This post wouldn’t make a lot of sense if you have not had exposure to RxJS.
Unsubscribing or Cancelling.
One of the key features of Observables is its ability to cancel…
In the second part of this series I talked about how we actually deliver our products every single day - the process and the tooling. In this final post I want to discuss why some of these practices are important to achieving the level of efficiency you need to deliver quality product, fast.
When we start a new project, there are a bunch of things that we setup to ensure the smoothest and fastest operation of that project and the best quality outcome of that project. …
Anyone who is an experienced application developer understands that if your application is not the typical todo app, you have at least a few states that are application wide (they conceptually exist regardless of how they are implemented/handled). There are lots of powerful ways to maintain states well (like routes, singletons, storage and so on). But it all boils down to how you define them and use them.
Why disaster?
Centralized states can be a disaster for the very reason why global variables can be the same. When there is a central/global state, it can affect different parts of the application and…
In the first part of this series I spoke about what this whole thing means for us. In summary the three key focuses are: World-class product quality, fast delivery of smaller things and automating everything. In this post I will be going through how it is done.
How we work is what enables us deliver product everyday.
Environment
Each of our projects are on their own git repo. Each project is bootstrapped with package management, linting, code styling, unit test coverage reporting and a full-on build process. Every repo has
- a dev branch which aligns with staging environment.
- a master branch…
F**k that.
I fully appreciate the notion of not taking failure as a negative emotion and I have practiced that many a times. Failure happens and there is so much that you learn from it and almost every failure is a gain, not a loss. So telling yourself “it’s ok to fail” when you fail, is one thing.
What bothers me is whenever I see a Startup or even any sort of initiative that is driven with the safety net of “it’s ok to fail”. This I feel sets you in the wrong direction all-together. If you are being scientific…
In today’s age and time, if your product team is focusing on anything other than building great product experiences, your competitors won’t have much trouble gobbling down your slice of the market. There are many things that can eat up the time of your product team. One of them is delivery.
Continuous Delivery is no magic. You will find many ways to learn and make CD work for you. I’m not gonna talk about that. This series is going to talk about how we adopted a scalable way of working for Delivering Product Daily.
Delivering product fast is no brainer…
Hiraash Thawfeek
Coder, Creator of things, Entrepreneur
