The Tools I Use: Ufuk Kayserilioglu, Senior Developer
Why can’t people choose the tools they use to do their jobs? It’s a question we ask a lot at Myplanet.
Because for us, the strange paradox of a world full of choice that is largely restricted from people during their working lives seems, if not completely backwards, at least quite annoying.
Most people arrive at work and whatever tools — systems, programs, or software — are deemed to be the right ones by their employer, are the ones they must use.
And even though we know these tools have (hopefully) been chosen carefully to accomplish the tasks at hand and that they might even be the best available tool to do the task, we also know that doesn’t mean they’re the best they can be. Nor does it mean the hundreds, thousands, or potentially millions of employees using it find it an easy, enjoyable, or satisfying experience.
Which is why that choice paradox bugs our brains so much — why restrict people’s choices? And if you must use something, shouldn’t it at least be as pleasant as possible to use?
These bugaboos of ours are part of why we started our Tools I Use series a few months ago. We figured if we’re going to improve people’s workplace experiences, the first place we should look for what inspires and excites people about their work tools was right in our own offices. So we’ve been asking Myplaneteers to share their favourite tools for getting their jobs done as part of that.
In this edition, we’re taking a look at what one of our Senior Developers, Ufuk Kayserilioglu, uses. As a member of our Meetings & Collaboration team, Ufuk has been working for the past two years on RelayRobin, a VCaaS product we developed that simplifies and improves the videoconferencing experience for enterprise users.
Hearing about his favourite tools is of particular interest to us because not only is he a talented and dedicated developer, he’s also an incredibly effective collaborator — in spite of being stationed thousands of miles away where he works from his home in Europe.
With a sharp mind for development and a keen sensitivity to the challenges of communicating and working with colleagues over great distances, we were keen to hear about Ufuk’s preferred tools.
So, without further adieu, here are Ufuk’s top 5 tools for getting his job done.
Tool #1: Sublime Text
Tool number 1 would be my editor, Sublime Text.
As a developer, most of my time is spent editing code or producing new code (hopefully!), but generally speaking, some sort of text editing. I like Sublime Text because it is relatively lightweight and it’s extensible enough with a wide enough range of choices of plug-ins and extensions to cater to all my needs (so far).
Some people have greater expectations of their text editors, where they expect it to do almost everything for them, so they use them like an IDE (integrated development environment). I don’t have that expectation, so I just use it as a plain text editor with some macros that I’ve defined to make the text editing easier, but not necessarily to build my project or to run it or to run my tests or anything.
Tool #2: iTerm2
…I heavily use the command line. I primarily work on a Mac, but I haven’t used the built in terminal tool too much. Instead, I started using a tool called iTerm2*, which is a replacement terminal.
I use iTerm2 because it supports advanced things like resuming sessions, or giving me transparency, or docking the screen to the top of a window and opening it with a key command or something — basically, it has more features that I’d use. I use split windows, for example, to do two things at the same time, like run tests on one and run the web server on the other and see the output from both.
I usually switch between the editor and the command line and then, if I’m working on mobile to the respective emulator, or to the browser if I’m working on a web project.
*iTerm was an open source project which, I believe, was forked to create iTerm2. iTerm2 is now in version 3. So it’s all very confusing, but it’s a great tool!
Tool #3: Google Chrome
So those two are my main tools. But of course, since I’m mostly working in a web environment, my next tool would be the web browser. And my web browser of choice is Chrome.
I use Chrome for the sole reason that the developer tools in Chrome are amazingly good.
I can inspect the state of my web project as it’s loaded in the browser, easily do style changes, and then preview them in-browser without having to reload the page.
I usually do style changes in the browser and then when it’s in a form that I’m happy with, I just copy-paste from there, put it back into the code, and then do a full reload. It makes the process much simpler.
And there are even more advanced features that I haven’t used much, but I know they’re there and I know that if I need them or if the project needs them, that I can always use them.
And it’s all integrated into the browser. It’s all just a click away, so that’s why Chrome is my — and I think most of my colleagues — choice of browser, as the primary browser.
That being said, it’s important that there is some diversity.
At the end of the day, Chrome is only one browser and there are other browsers out there with differing quirks and differing rendering mechanisms, so the code that I write and that I preview in Chrome doesn’t necessarily mean it’s going to look the same in other browsers.
As an example, a cross-platform website (which is the case for the product I’ve been working on) needs to actually be tested on other browsers. There needs to be someone (or some people) that do those tests, so having some familiarity with all browsers is still important.
Tool #4: Slack
The first three are all things I use when I’m developing on my own. But as a remote worker, apart from occasionally videoconferencing or flying in to Toronto to see people face-to-face, what’s actually very beneficial is to have an asynchronous text option. And for me, the best tool for that is Slack.
Let’s say I want to ask someone something, but I know there’s no urgency to the answer. Or I want to have a loose conversation and I don’t want to interrupt by calling the other person, because they could be working on something and don’t need the distraction. Slack answers those needs for me. It’s been a great tool for communication on our team, and especially for me personally.
It reduces email — which is, most of the time, really hard to follow and pollutes your inbox — and it also prevents me from being interrupted or interrupting people. It’s a nice medium for communicating via text (and emojis and pictures and whatever else), but in an asynchronous fashion, which I really like.
Tool #5: ScreenHero
Sometimes, however, I actually do need to talk to other people and see the same screen and be able to actually, maybe, control the same screen.
In instances like pair programming, or helping out a colleague with a particular problem, or someone seeing something that I can’t reproduce — if I can see it and try to troubleshoot it or work on it with them on their machine, that’s ideal.
For those scenarios, Screenhero is an invaluable tool. Screenhero is like screen sharing, but it’s even more than screen sharing. Up to 10 people can actually collaborate on a single screen.
One of the participants shares their screen. Every other person is connected to the same screen, but they each get a different mouse cursor so they can all actually interact with that single screen, independent of one another. And you can change screens.
Sometimes we’ll be working on my colleague’s screen, who is in Toronto, and I’m remotely looking at what he’s doing and, if necessary, interacting with it and typing. Then we’ll switch to my screen because I’ve done some work on a different part of the code, and then my colleague in Toronto is using my screen and looking at and interacting with my code.
It’s also a great tool for helping colleagues when they’re stuck or getting an error when they run a command and have no idea why it’s happening. It’s nice to be able to just jump into their screen and type a few commands to see what’s happening and test a few different things and then say “Ah! Yes, I know why this is happening” and then I can fix it for them or show them how to fix it really easily.
The last thing I really like about Screenhero is that when you’re sharing the screen, it also open an audio communication between participants, so you can talk. It’s the next best thing to actually being in front of the same computer, talking to each other and troubleshooting or working on the same thing. It might even be better — you each have your own respective keyboard and mouse and access to the work being done.
Slack actually bought Screenhero a while back and they are slowly rolling the functionality into their platform. So eventually, it will be an all-in-one collaboration tool that supports audio, video, screen sharing (like Screenhero does it) and text, which I’m looking forward to. It’s already a great tool and it makes the remote presence thing very easy.
On Selecting Tools
I’m not sure I have any particular set of rules when I’m evaluating which tools to use, but…
- It shouldn’t make me wait. It should be fast. If I’m launching an app and waiting for it to launch, then that’s a drag and it impacts whether I really want or need that tool.
- Similar to tip 1, depending on the value that it gives, I think it’s important to weigh the benefits against the annoyances, and whichever weighs more heavily, I lean to that side.
- I like using things that give me more freedom and more choice. I choose Chrome, for example, because it’s a more flexible platform, is easier to develop for, more extensible and has more options for how I want to use it.
- Familiarity and comfort is important to me. Being really accustomed to the tools makes a big difference in the end. I don’t use an external keyboard and mouse with my laptop for that reason and it’s something I mentally consider when I’m thinking through new tools.
We’re given a lot of room to choose our own tools at Myplanet, which is really worthwhile for me as a developer, especially.
If anything, we don’t care what tools people use, as long as the output has a common style and has the common conventions that we want to use on the team. Because everybody’s choices are different, everybody has different familiarity with different tools and we actually want people to use the tool that they’re fastest with or they feel the most comfortable with.
The goal is always to produce a consistently great product. We’re less concerned about how we produced it and more concerned with what is being produced. So when you’re picking a new tool, your top concern should be about the effect it has on what you produce.