Deploying new features is a nerve-racking task, but it must be done.

Here’s an issue we’ve all faced or will inevitably face in our careers. Allow me to set the scene…

You’ve finished your work on some features, fixed some bugs, etc. You’re feeling good because some features were a bit more complicated. You decide it’s high time to let your users experience these changes. You bundle up all your teams’ changes and deploy them to the production server. A couple of hours later, disaster strikes! There’s a critical bug on a feature you’ve worked on. Now, you have to revert to the old version of the application or deploy a new one, but without your changes.

As these situations can have a huge impact, reacting quickly is key. Unfortunately, developers usually learn how to handle this situation once it happens, so it only prolongs the agony.

Deploying and releasing at the same time isn’t such an uncommon practice because, at the beginning of a project, you want your users to see the changes immediately. Many projects continue using this process, but as the project grows, it makes sense to decouple the deployment of the code and the release process (activating changes to users).

Even if this hasn’t happened to you yet, we can all agree that it’s a very stressful situation, and establishing a process for handling this is something you want to do ahead of time. 

But how much ahead of time are we talking about here?

There are many ways to handle these types of outages, and it’s important to establish a rollback procedure. In addition to that, we also use something called feature toggles. It’s not something unique to us, but it’s a pretty sweet thing to have in your toolbox. For those unfamiliar with feature toggles, it’s a mechanism that allows you to turn a feature on or off for a user without needing to deploy the whole application. It’s really simple, but it’s huge!

Although it’s called a “feature toggle”, it doesn’t necessarily mean that you have to use them for features only. You can use them basically for anything. Whether it’s A/B testing, refactoring a part of the screen, or navigating a user to a different page entirely! I’m sure you can think of a couple of more examples that would be useful to you.

This also allows us to oversee which users can access a certain change. This is helpful when trying to collect feedback or just observing how users interact with something you’ve developed. Once you’ve established your feature toggle system, you don’t need to put in continuous work to keep it going. It’s also a great way to manage the lifecycle of the change by progressively rolling it out to your canary, beta, and all users! 

You gain a lot more control over who sees what, and the best part is that turning toggles on or off can be done by anyone! Someone like a product manager or customer support person could decide to turn a toggle on because it’s just something that the customer needs. After a feature has been fully developed, the toggle can be globally released to all customers, and everyone can enjoy the stable version.

The number of annoyed users will decrease, and valuable feedback on changes will increase. 

It’s also worth mentioning that you can base your whole QA process on the toggles. We can test a change by turning a toggle on, gathering feedback, and then turning the toggle off. When you have such fine-grained control, testing on production isn’t a big deal! We also use these toggles in other environments, so you can isolate a change to a specific set of users on any server.

It’s a win-win for everyone!

The main question that’s probably going around in your head is how the feature toggles affect the development of a feature.

Feature toggles do complicate things a bit when writing code, but if you spend some time on planning, it can be done elegantly in most cases. You must be careful to add every change behind the toggle so nothing leaks when the toggle isn’t turned on. Other people working on the feature must also be aware of using the toggle since it probably will span through multiple files and can sometimes be forgotten.

Sometimes, it’s not that complicated, but you gain a lot. As I’ve already mentioned, it can be used for basically anything, and complexity may increase, but it really is worth it:

The added complexity isn’t such a big drawback. You’re getting a lot more out of feature toggles, and if that means that developers have to be a bit more careful when writing and reviewing code, so be it. It’s much less stressful for a developer when they know a feature can be turned off if it’s causing problems. This doesn’t mean we approve of sloppy code, but sometimes, these things happen.

To conclude, feature toggles (once established) don’t affect the development process as much, but they offer a lot in return.

The first one does introduce technical debt, but if we create a task for deleting a toggle after it’s been globally released, we can be sure that it will be deleted as soon as possible. The person who created the toggle is responsible for deleting it, which is a great way to handle this efficiently. In any case, deleting a toggle usually takes significantly less time than developing it!

As for the other issue, there are two ways to handle this. We can do either of these two:

It’s not an ideal situation, but it can happen. The solution mostly depends on the state of the features, so it’s impossible to determine the best way without knowing all the facts. Either way, both solutions can simplify things for development.

For us, implementing feature toggles was a no-brainer. Considering all of the benefits like the control, progressive rollouts, and others, it seriously outweighs the downsides it introduces. Even the downsides can be managed to an extent.

It’s important that everyone in the company understands the whole process and embraces why we’re doing it in such a way. It’s an essential part of a company like ours since every department is involved in the release process of product updates. Once people are aware of this, building an admin system to control this is up to you and your company’s needs. 

Here’s an example of our own. We call it the “Backoffice”:

As a developer, I’m grateful we can release features quickly and stress-free, knowing we have some wiggle room.

As for you, I hope I’ve shown you why it’s a good idea to think about something like this if you don’t use a similar mechanism. If you need a bit more convincing, you can read more about it in an article by Martin Fowler! Even if you’re not in a position to make your feature toggle system, there are a lot of external tools and libraries that might help you implement the same!

I’m always pushing myself to look at the big picture of a project I’ve been working on.

You can easily get tunnel vision when working on a larger project, so it’s imperative that you constantly remind yourself to put everything in perspective.

This most commonly refers to a project’s business logic or domain, but an equally important aspect revolves around the technical implementation of a project. This can easily be overlooked so I’ll try to explain why you should think about it a bit more.

Any time I start working on an unknown project, I always get the feeling that there’s too much bloat. I’m eager to do things my way. Sometimes my way really is better. Most of the time it’s the constrictions of the project that caused something simple to become complicated. This isn’t related only to code, but to third-party library dependencies, the architecture of a project, and so much more.

The worst thing you can hear in this particular scenario is “That’s how we’ve always done it” or “Here be dragons, so just leave it”.

Alright, maybe it’s not the worst thing, but it certainly doesn’t get your hopes up.

This might mean that you’re just stuck adding to a legacy that will just become more and more complex to get a hold of. Now, add a team of people doing the same and you’ll see how quickly the situation can get out of control.

Luckily, this is not the case at Productive. I’m so glad to have finally found people with a similar mindset and a similar drive to improve what needs improvement. The whole idea is that each team member can and should contribute in any way they can. And there are plenty of options when it comes to contributing: 

I’m sure you can think of some more examples as well. Some are easier, some are more complex, but all of them are important. As I’ve said, this shouldn’t be something you do entirely on your own. You’re required to talk to your team and come up with the best possible way to improve an existing issue. It might not be the very best solution right off the bat, but it’s a step in the right direction. After you get the ball rolling, other people might be motivated to have a crack at something!

The idea that you have to be very experienced to do these kinds of things sometimes held me back from doing as much as I could have. I always thought that someone could do this better than me, someone with more experience or knowledge. That might be true, but if you have an idea and the time, it could be a great opportunity to learn and become better. Even if you’re new to the company, you’re most probably the best person to update the onboarding documentation because you can easily find out which step wasn’t clear enough! 

Add these points in with having all team members involved, as well as good communication, and you’ve got yourself a pretty sweet deal! The functionalities and the bug fixes will still be pumped out, but the overall developer experience and codebase quality will surely go up instead of down. This can also help people get a grip on a complex issue that might otherwise be left untouched.

Even though our experience has definitely been positive, not everything was perfect from the start. Some initiatives didn’t pick up as much as we expected, even though their general idea was important.

After we talked to our team members, we realized that the scope of certain initiatives was too broad. The general idea was good, but people didn’t know where and how to start.

To alleviate this, we split the problematic initiatives and narrowed them down as much as we could. That’s why it’s very important to talk to your teammates and get actual feedback, especially if you notice something unusual.

If you’re stuck on thinking what could be improved in your project, here are some of our initiatives that we came up with:

I’m convinced that things would go a lot slower if we stuck to doing improvements on the fly and without responsible people. Therefore, I’m really glad this took off because it’s really inspiring to see people make an effort in domains that are not as focused as they should be.

Once everyone started recognizing the benefits of an initiative, all sorts of ideas started coming out. It’s amazing how you get used to something so quickly, but a little push sets off a chain reaction that has you questioning why you didn’t think of something earlier.

I hope this helps you out and encourages you to try out something similar for yourselves!

Writing documentation is important but tedious. We’re all probably aware that we have to write documentation for the products we develop. I don’t know how you feel about it, but when I do it, it hurts my brain.

It’s not even that difficult (most of the time), but the whole process around it is what makes it so dull. Personally, I enjoy writing, but even I have to force myself to write a couple of sentences about what I’ve done. But you gotta do it, baby.

I’ll be explaining the techniques we incorporated in our workflow to improve the whole documentation situation. If you’re struggling with this, I’m sure you’ll be able to take away some ideas from this post.

I won’t spend too much time explaining why documentation is important and who benefits from it because I’m sure you already know that. I’ll mention some problems that I’ve run into when dealing with documentation.

When I first started working at Productive, there was already a fair share of documentation. A lot of things were documented, from setting up your workstation to details about using a specific component. I was excited about being brought up to speed with everything, but I started running into cases and features that were either not detailed enough or not documented at all. Even though I was optimistic at first, this didn’t really surprise me since it’s a huge codebase with a lot in it. This just meant that I’d have to ping other colleagues and figure some stuff out on my own.

Fast forward a couple of months, it was my time to write documentation. Up until this point, I was very excited about documenting everything I’ve done. But when it was time to write something, I had this nagging feeling in my head. I knew that it had to be done, but now I had to think about how and why something was done in a particular way, how detailed the explanations should be, where to actually write the documentation, and a whole lot more. It’s even worse when it’s a system that you don’t completely understand and you start asking yourself if you’re the best choice for writing this piece of documentation.

So many problems—and I haven’t even started writing any documentation yet.

Now, this sounds a bit more dramatic, but all of these thoughts passed through my mind at some point. We quickly brainstormed a couple of ideas to tackle the problems mentioned above. If we had some sort of a process and a frictionless way of writing documentation, everyone would have a lot more brain power to actually write documentation as opposed to worrying about issues related to writing documentation.

Here are the things we agreed upon:

Now, let me take you through each.

This is something I had to get used to, as you can probably tell from my experience when I just joined Productive. It doesn’t mean that you should only document new features you’ve worked on, but even the old ones that you might not completely understand. You can always request a review from someone who has more experience to double check what you wrote. Even if it isn’t entirely correct, it’ll probably be much easier for the other person to advise what to focus on as opposed to a blank slate. An important thing to mention is that we also encourage asking more experienced colleagues to write a part of the documentation if it’s something complex or too difficult to piece together.

This ties in nicely with my previous point. Since documentation is something you iterate over constantly, it’s okay to just write some information down without paying too much attention to grammar, structure and completeness. It’s important to create a process that is as frictionless as possible in order to increase the engagement of everyone in the team. You can always improve the wording a bit later and other people can give feedback really quickly, even if they don’t fully understand the feature you’re working on.

Besides documenting new features and maintaining old ones, make sure that incomplete documentation gets the love it deserves. More often than not we run into something that exists in the documentation, but our specific case isn’t covered. This could also mean we’re approaching an issue in the wrong way, but still, we have to take initiative and document it. Chances are that someone else will have the same issue and if you take time to document it, they will have to spend significantly less time handling the issue.

Documenting something this way could be considered a “bottom-up” approach. Instead of documenting the whole process/feature, you just write down the specific case. Doing it this way could be a little bit “easier” because you don’t have to know every little detail about the whole feature. Just remember, whether it’s an onboarding topic or something highly technical, it should be a candidate for documentation to avoid confusion!

This one is, subjectively, the hardest. The whole process is simple: just like with continuous integration and continuous deployment, we have to maintain our documentation at all times. If a process/feature is worthy of documentation, a good time to write something about it is just after the process/feature is stable. A better time to write something about it would be even before you start coding, if that’s possible for the feature you’re writing about. Writing down everything while the information is still fresh will help you flesh out the whole story, not just parts of it. If you’re writing about it a couple of weeks later, you’re bound to forget some of the nuances that bugged you during development. Doing it later on could possibly be the beginning of incomplete documentation, so it makes sense to nip it in the bud.

Having outdated documentation is worse than having no documentation. This will just raise questions when something doesn’t behave as it says in the documentation. If you find yourself in a similar situation, make sure you delete it so it doesn’t confuse more people.

As mentioned, another approach we’ve considered is writing documentation before you start coding. This is something we’ve found helpful, gathering your thoughts around a feature makes developing it easier. This is also a great way to include non-technical people in the process and iron out some discrepancies even before a line of code has been written.

Having documentation is really important for everyone, no matter the seniority level or the amount of time you’ve been working on a project. Having said that, it’s not easy to encourage yourself or others to just write documentation.

You can make this a lot easier by reducing the amount of friction when writing documentation. Start by defining a time and place for writing documentation and involving your whole team. 

While you’re researching tools that could be helpful, don’t forget to check out Productive and our Docs! It could be helpful to add the extra step in your workflow, like including it in the estimates and requiring changes in the documentation when submitting a pull request. You can treat this just as you would treat writing tests since they complement each other. This will, most certainly, increase the time required to finish a task, but it’s just as important as the other parts of a feature.

This should make a good foundation for everyone to contribute and iterate over each other’s work. Hopefully, these small steps snowball into a more manageable project and make everyone’s life easier.

Let me start off with a little exercise. Just sit back, close your eyes and let me know if this sounds familiar. Well, maybe you shouldn’t close your eyes.

Anyway, you’ve been working on a project for some time now. Some bugs are reported to you now and then, but you feel something’s off. 

You suddenly remember that it would be a good idea to set up some kind of an error tracking system. There are a few choices, like Sentry, Bugsnag, Rollbar and some more. After choosing wisely, you install everything necessary and, lo and behold, some errors are starting to show up! 

And now comes the critical part. You promise yourself that you’ll check the error reports periodically and fix them as they come in. If that sounds familiar, chances are that these error reports aren’t getting fixed as diligently as you’d expect.

What I just described is the current situation at Productive. Bugs are getting fixed, but the ones that don’t “stand out” are kind of getting overlooked. Another issue is that the error reports are in Bugsnag, so they’re not in your face when you start working on your tasks for the day. As a consequence, our product managers aren’t always aware of the error reports so they can’t plan accordingly.

As part of our team’s internal initiative, for some time now, we’ve been aware that it just isn’t enough to set up an error tracking system. A process around it must exist. Just like with tasks, someone has to be responsible, the level of priority must be evaluated, and the error reports must be considered part of the workload. And now, with more people in our team, we can finally make things right.

In this post, I’ll show you an overview of all the things we’re trying to improve to really get a grip on bugs and errors. 

Since we’re currently working on this whole process, some things might change or some new points might get added, but the general idea will still stand.

First of all, I’ll let you in on a small glimpse into the current state of our Bugsnag:

I’m sure this might come as a surprise to some of you, but when you have a lot of users doing all sorts of things in your app, things are bound to go wrong. 

Even though this will be improved, as it is—this still gives a lot of information on how to organize a seemingly unrelated bunch of errors.

I’ve briefly mentioned which issues bothered us the most. There were a couple of issues on top of that, which we found out about after running a quick poll between our team members:

Now would be a good point to mention that these issues built up over time. Depending on the size of your project/team, the architecture or workflow, some issues might be more important than others. The key here is to find out what is really slowing down your team, but feel free to use this list as an inspiration.

After we’ve identified and written down the actual issues, the team collaboration kicked in and we got a lot of ideas on how to improve our situation.

The first step was to create a plan of attack. Taking all the issues into consideration, we came up with a list of potential solutions that might help us out. Since this was some sort of a brainstorming session, everyone was encouraged to leave their opinions and suggestions. 

Doing it this way, we were sure that we covered all the pain points that bothered the very people that were working on the bug reports.

Needless to say, you can’t do all of these things at once. Some priorities came up during the brainstorming session and here’s what we came up with:

I agree, it’s a big list. There’s a lot to do, but it’s not necessary to finish them all before we can reap the rewards. The most obvious thing was to upload the source maps since it’s not that difficult to do, but will tremendously help out when resolving bugs.

Some of the points are a bit touch-and-go. We’ll set something up, but some parts might change after we get a feel of how everything fits together. This includes the thresholds, automating the deleting process, and a couple of other points. 

It’s important to consider the amount of noise one sees when dealing with bugs. We want to minimize the amount of bugs actual humans need to deal with—mostly because we don’t want to get overwhelmed with the sheer number of bugs. Naturally, you have to be careful not to strip out significant and relevant bugs!

During our brainstorming session, we thought about our goals for the initiative. We came up with this…

For this to work properly, there are two things that need to be done:

After these are defined, every member of the frontend team should be aware of these processes and do their part to keep the number of bugs at a minimum.

This isn’t some super complex idea, nor is it as profound as I would like it to be. It summarizes the whole initiative in a couple of sentences, but is often overlooked when trying to get on top of this issue.

Doing it this way really does require additional work and will probably drive you out of your mind sometimes, but the payoff is huge! Think about the happier users, how your product will be more robust, and the amount of things you might learn that you weren’t aware of before. And can you really say that you’re tracking errors if you’re not resolving them in due time?

In a product of this size, you’re not going to cover every case that might happen with tests and your coding. This might sound a little demoralizing, but it shouldn’t be, it’s a normal thing! There are a lot of things that can go wrong in building an application, so in order to cover your bases even more, error tracking is a step in the right direction.

If you’re really interested in a particular subject we discussed here briefly, we’ll be posting more deep-dives related to specific implementations of the mentioned solutions, so stay tuned for that!

A couple of months ago, there was a huge shift in my work-life. Or so I thought.

Instead of working in Vue or React, I had to learn Ember for my new frontend position at Productive. I was sure I would have needed quite some time to get used to it. Up until a few months back, I didn’t know what was going on in the Ember ecosystem. Although this didn’t scare me, I felt like it would be a hefty challenge because I wasn’t sure what I was getting myself into.

Turns out, it’s really not that different from the frameworks I already know. All of the usual things you’d expect are there. Things like store management, component slots, dependency injection and much more. And they were a bit easier to use since it all came out of the box! 

You don’t have to spend a lot of time deciding between libraries, patterns or technologies because a number of them are already there when you just install Ember. It does have some nuances, pitfalls and you still have to choose between some libraries (UI libraries, I’m looking at you), but I haven’t worked with a framework where you didn’t have to worry about anything. After I took all this in, the hefty challenge didn’t seem so bad anymore. Now, this was just a matter of getting used to the framework.

As I’ve started to learn about Ember on a deeper level, a lot of the concepts were familiar to me. Some were described exactly as you’d expected them, some were named differently and some used a different terminology.

But since Ember has such a long history (for a Javascript framework, at least), there are some terms I wasn’t aware of. That’s why I started to write down anything that I wanted to learn more about. This included libraries, phrases, patterns and technologies. I was sure this would help me in the long run, so I’m sharing it with anyone who’s just starting out with Ember.

This is especially helpful if the codebase you’re working on has a couple of years under its belt. It pays off knowing how and why things were done so you don’t accidentally break a functionality when refactoring.

I’ve talked long enough, so here’s the list!

Learn more about it:

Learn more about it:

Learn more about it:

Learn more about it:

Learn more about it:

Learn more about it:

Learn more about it:

Learn more about it:

Learn more about it:

Learn more about it:

Learn more about it:

Learn more about it:

Learn more about it:

Learn more about it:

Learn more about it:

Learn more about it:

Learn more about it:

I’m sure some things might be missing, but this is what was the most puzzling to me. Hopefully, you’ll find some use of all these terms!

Also, I feel like it would be kind of rude not to mention the resources I used while learning Ember: (yay, more lists)!