You know the saying, “by developers, for developers”? Well, at Rookout, we take that quite literally. Developers are the heart and soul of Rookout. As developers ourselves, especially as ones who have had our heads stuck in code for many years, we look to make fellow developers’ lives easier.
There are countless tools that are available to developers. Whether they enable easier workflows, improve quality, aid in collaboration, and so on and so forth - the sky's the limit. With all these options, how do you choose what’s best? Devs are notorious for their personal preferences when it comes to working on their code, and choosing their tools is no different. Like proud parents, they want what is best for their software. Going about choosing these tools is no easy feat, so we thought we could make it just a smidge easier for you in your search.
The Rookout team is dedicated and driven by hard-earned experience. That’s why they’re sharing their experience with you. Here are just a few of the tools that these awesome devs believe empower them most in their work. So sit down, grab your cup of coffee - or beer, it’s happy hour somewhere!- and read what tools might help you to optimize your dev workflow.
Let’s begin with one of our Backend devs, Zeev Manilovich. When pressed to share one tool that he loves above all else, he chose IntelliJ IDEA.
“IntelliJ IDEA is my go-to tool for everything development related. It has all the needed information and tools to do my job. The plugin system makes it an all-in-one development tool, essentially allowing you to develop an application end-to-end without leaving it.
Some of its best features are an IDE with all the needed language linters, various version control clients, a database client for all popular databases, code compare and merge tools, fetching documentation, integration with dependency management, and much more. For me, there is no way that I could have done my work without it. Simply put, all the alternatives just aren’t as good and I’m not even anywhere near thinking of replacing it.”
“In my role as DevOps, the tools that empower me the most are the ones that save me time. So, I usually look at what my workload consists of for the day. At Rookout we are subscribed to and use more than 20 different SaaS tools, which all have their use. However, personally, if I don’t use something every day, then I wouldn’t rank it high on my list of helpful tools.
Managing a Kubernetes cluster is not an easy task, and even when using a managed service such as GKE, I still find myself buried in my terminal under kubectl commands switching namespaces and clusters to find out where a deployment went wrong. I then found out about K9S - a nifty open-source CUI (CLI User Interface). It could make everything easier, ranging from auto-refresh to color coding, showing more detailed information about pods, parsing base64 config and secrets at the press of a button, and of course providing a way to manage environments such as cluster contexts and namespaces.
I have been using this tool for the past year or so. When some of my colleagues at Rookout saw it on my screen, they were surprised they weren’t already using it. I of course pointed them to the github repository and gave them a quick tour of the tool. I think the most annoying part about using it is that I want to contribute and give back to this awesome tool and team that made my life easier, but they are already so on top of things that I can’t send a pull request fast enough with a feature that I’m missing because it’s already been done!”
“One of the best things about modern Web Development is the concept of Styled Components. As Newman from Seinfeld once said - "Love is a spice with many tastes" - and so is CSS. This language that makes web pages and cross-platform apps pretty to the eye is often regarded as not-so-pretty itself and as unintuitive for a number of reasons. One of those reasons is the need to always think about specificity.
In CSS, specificity is taken very seriously. If you have a CSS selector that points to a specific element in a very detailed manner - it would take precedence over other less 'detailed' selectors pointing to the same element, and this is often the reason why people use the infamous !important declaration - which is something none of us should ever have to use - when needing to override that selector.
Styled Components and @emotion/styled (Emotion's take on Styled Components) save us from all this trouble. They let us focus on the styling rather than on class names or specificity (since those two are being handled by the library, respectively), which ultimately makes life for Front End Developers much easier.
This, of course, doesn't mean you shouldn't know your CSS. It's an integral part of each and every Frontend Developer's toolbox. But if your plan is moving forward fast in this age of Modern Web, where every component is encapsulated to be an entity of its own, then the 'styled' philosophy is something you should probably keep in mind.
And as a way of showing we walk the walk and aren’t just talking the talk - we are in Emotion's examples in the wild.”
“When thinking of a tool or service that empowers me as an R&D manager, I think of how those tools must be something that gives great value to both my team and me. One of the main problems that Rookout’s product solves is debugging and solving bugs. Yet, before you can fix and solve the bugs, you must first find the bugs and understand the state of quality your product is in. At Rookout, we use Bugsnag and Sentry. Their value is amazing and empowers our team of developers. It does this by allowing them to hunt the bugs and gives them a headstart on fixing them.
As a manager, I know that my devs have the right tool to help them find bugs, while also giving me a high level understanding of the quality my team delivers. I don't often dig into the details of every bug, but when I do I am able to get a wide insight on my system’s status. I can look at the amount of bugs for each application and service we have, see the amount of new bugs that surface when we deploy a new version and then identify overall trends. I am able to easily decide whether I want my team to put more or less effort into bug smashing and can then raise a flag to our sales engineers and support engineers when things heat up.
If you don’t have any error reporting framework, go ahead and integrate one. Whether it be Bugsnag, Sentry (which has excellent integration with Rookout) or any other service - you won’t understand how you managed to get by without it.”
As CTO of Rookout, Jira is my favorite tool. Why, you ask, out of all of the tools in the universe, did I choose this specific one?
Well, for starters, as the CTO, Jira gives me the management capabilities that I need. I know, I know, most devs everywhere are less than fond of Jira. But let’s be honest! They (especially our dev team) end up liking the end result. The impact that an empowered and well managed product team has on their workflows is incomparable. While they may dislike the software, they do like that their tasks are clear and unconfused. It lets them know exactly what they are working on and why.
Jira allows us to break down the roadmap we have in place into byte-sized pieces of work that can be executed on a day-to-day basis. It also enables our product and engineering leadership to stay on top of things, knowing where they should focus their time and energy to make sure things are progressing smoothly.
As the saying goes, “if the shoe fits…”, but really, it’s if the tool fits. In our experience as software developers, no tool does it all, no matter how hard their marketing might want you to believe. That doesn’t mean, though, that you should give up all hope.
Rookout, for instance, as a data extraction and pipelining platform, will empower you to find the information you need and deliver it anywhere. This lets you understand and advance your software, saving you hours of work and reducing the time you waste logging and debugging. But hey, the possibilities are infinite! Whether you choose to adopt Rookout or one of the above tools (or even better, why not adopt a few?), just remember that it’s about what’s best for you and your code! We’re looking forward to hearing which worked for you ;)