Hi, I’m @elliot 👋. I’m a Front End Developer on the Opslock Engineering team. I joined the team just about a year ago now, and I want to reflect on what it is like to work here. I interviewed each of the Opslock Engineering team members (there are nine of us) and asked six questions in an attempt to collect some words and ways to think about what being an engineer here is about. Each of these six questions is a heading in the post below. Under each heading is a selection of a few of the most interesting responses from the engineers. With that being said, I’ve tried to fairly represent the perspectives of all the engineers.
Why am I writing this? I asked for some time to write this blog post by pitching it as a form of viral marketing that “will promote a positive view of Opslock’s technology to our existing and potential customers”, and “will be a resource for attracting new engineers”. Really though, it’s just an excuse to spend work hours talking, journaling and contemplating my own career… Facetiousness aside, the team was supportive and encouraging during my writing of this post. If you are interested in working at Canadian startup, I have certainly tried to make this post useful to you.
Alright, let’s get to the questions.
SHAWN
“So I think in general, you know, we’ve just had the mantra of ‘nothing on the front end is set in stone’ and […], you know, we encourage people to try new experiments. And then, I think that the whole team is pretty good about if they see someone doing something that is just a better way to do it; that knowledge spreads very quickly through the team and it just becomes the default way to do it. And then eventually we have to go back and do it for the old code, but that’s the downside of doing it this way. But I think it really allows us to sort of slowly find a workflow that works for us.”
BEN
“So far. I’ve touched a little bit of everything, so less specialized, but I worked with Memento and Notify.”
“Notify is our notification sending microservice and the purpose of it is to allow users to receive notifications whether they’re on premises, on an industrial work site and/or whether they’re working from the headquarters of a company somewhere in a major city.”
“So that was really the biggest challenge: being able to send notifications as […] someone goes in and out of a wireless internet connection while going across the ocean.”
JOHNNIE
“Replicate? Okay. So yeah, replicate is an in-house replication system that copies data from multiple databases in a master-master fashion, or we call it active-active.”
“We kind of know what kind of rules we want for when writes and reads occur between one site to another. And it’s one of those cases where the solution out of the box doesn’t provide all the customization you would like. And also if we want to do maintenance on a piece of work like this, we want to be able to understand what’s really happening under the hood. So for us it made more sense to write one in house and add the features we need as we need them.”
“And also we wanted to be able to have the ability to control how much data goes over the wire and how big is the deliverable, because we’re pushing these changes to on-prem devices, IOT devices.”
BJORN
“And the [Opslock] design system? I’ll say it would be like any other design system, the building blocks for whatever you see on the screen. And it helps developers to build things quickly and it kind of makes things more rigid and robust.”
AIDAN
“Well, the fact that we work in a startup also [means] that our responsibilities are a little more cross spread, like cross-pollination [of our] tasks.”
“So I guess the most interesting fact is that our responsibilities are not stuck in stone. And, and if something really interests you kind of can go forward with it and go explore it a little.”
BEN
“We have a strong bias towards building our own tech in Go instead of just including a bunch of technologies from all over the place. And we always try to find Go technologies first before including other programming languages into our stack. So instead of just adding some big Java-something that runs in the background, we try and find a Go alternative or we write a Go alternative. And that keeps things really light and slim, but it also gives us hands-on engineering experience, building simpler versions of those really complicated Java things. So we get to learn a lot of different stuff.”
JOHNNIE
“I think the most interesting part of the job is designing the backend solutions to our problems, just because when we’re often thinking about solutions, we’re thinking about how they are solved twofold. One is online and one is on-prem.”
“That’s kind of interesting to solve rather than working on a cloud-based product only. It’s kind of straightforward when you have access to using whatever SAAS tools you want. But when you do backend solutions that require on-prem, you have to think about if you can’t use a SAAS tool, most cases. It adds: ‘Okay, we have to build some.’”
MARC
“I would say, having to deal with on-prem devices that sync with the cloud, that allows customers to use the service even when their work-site is offline [and disconnected from the internet], as long as the app has a working local network. It’s the most interesting part because it’s the most difficult part [and] is the part that makes Opslock differentiate itself from other companies that might offer a similar product.”
“It’s a bit mathematical in a way too.”
BJORN
“Because it’s the first time we [are] working [with Svelte] on an enterprise level and we are solving problems that not many company has solved before with a new framework. I’m pretty happy that we are discovering ways for it. We are paving the path forward for this new kind of framework we’re using.”
LUCAS
“In general, I find the grooming process for new features is the most interesting part. It lets me imagine a blueprint for how to implement a feature. And then, when I implemented and finally got everything into one piece and I chain everything together. I feel it’s the most interesting part.”
MICAH
“I love technology, but ultimately I view it as a tool to complete another goal. So it’s understanding how people will interact with something, it’s understanding how people could interact with something, how it could be broken, how they could expect something to behave and then finding thoughtful ways to implement it for future developers or myself.”
BEN
“I’m just doing a lot of reading and building microservices. I guess most of my day is just building and testing stuff, but I don’t really know how else to answer that.”
JOHNNIE
“My day-to-day work, for me normally, begins with after I warm my brain up: going over some PRs and things like that, then I’m prepping to see what my team is working on. Cause I’m a technical lead for a squad. So understanding where my team members are at and understanding what can I do to help them, and what can I do to help facilitate them help them help each other? Because at the end of the day, I don’t see myself as like the boss or the leader, but I see myself as the facilitator to just kind of help get things done. I want to just make sure they have what they need.”
“I think we’re all leaders here at the end of the day. We all have very strong thoughts and I like to have everyone really have ownership in what they’re doing. I think the goal is just making sure that there’s always alignment and having someone take control of that alignment, but everyone provides good thoughts on the engineering team. I like to be the facilitator to let those thoughts come to fruition.”
MARC
“Fortunately, my day-to-day work does not involve too many meetings. I’d say maybe 20% meeting, 40-50% actual work, which is pretty good compared to past experience. Another fraction about helping others that might have technical issues with the product. And I also take the time to research and think about the future and what we could do best in the future.“
SHAWN
“When we got our first customer [customer name removed]; Johnnie, Joe and I flew out to Newfoundland and set up the onsite server on their boat and they showed us around the boat and stuff. And this was a more modern boat, but they were still doing most stuff with pens and paper.”
“They had binders they showed us: ‘yeah, here’s where we fill out the thing and we just check it off.’ and it’s this big bookcase of binders. And you know, it’s impossible, if you need to search for one work permit that happened three months ago. Good luck finding it, right?”
AIDAN
“So there’s not lots of places where we can say that we’re actually […] trying to make the workplace a more secure place, like where we can actually have an impact on security [safety] and maybe even lives.”
JOHNNIE
“I think my take is simply we’re building tools to make risky jobs easier to do or safer to do.”
“There’s a lot of friction going on with those industries and we’re trying to solve that friction.”
MARC
“My interpretation of the mission is that there’s a lot of friction right now in the industry when it comes to health and safety, a lot of forms and checkboxes to tick and things like that. When it comes to security, it’s ironic because too much security actually can decrease security.”
“You don’t increase security by adding more stuff to do. You make it super easy. You use computers instead of [paper] forms, but you don’t, you don’t fit-in forms on your computers. It’s a bit better, but that’s not what you do. You want to automate. You don’t want to have anything to do, and [automation should] do the health and safety analysis for you. So, yeah, removing friction.”
MICAH
“So coming from a background of mechanical engineering, I worked with industrial companies and I saw how they maintain their documentation and how they tracked work, let’s say, or how they try to ensure safety or how they even track systems. I worked with subsea departments, so looking at installed hydraulic equipment and seeing how that is monitored and tracked. And then I’ve worked with work departments where they’re talking about budgeting people’s hours for work. And one thing that really kind-of astonished me at the time as an undergraduate student and these co-op terms was how behind they were technologically at the time… And how Excel makes the world go round!
And like someone in an office can run Excel and that’s fine, but nobody who is in a trades position or who in an implementation position is going to pull up Excel and log it? It doesn’t make sense! It’s so much friction. And it’s so non-intuitive, it’s a great tool, but the reason why people make paper documents, which tell you where to sign and what you’re signing, is because it makes so much more sense than giving a trades worker a pen and paper and say: ‘why do you think this is safe at this given moment?’ Right? So the thing that I love about our mission is it lets people focus in real-time on what they are doing as far as dangerous work is concerned, as far as trying to talk about dangerous work.
And it guides them along that path to be more effective communicators and more effective maintainers of the integrity of the safety around the work they’re doing. And then to implement it, right? Because the more we lower the friction for the paperwork that they have to do to ensure compliance, the better that they can focus on actually being safe Because we’re telling them exactly what they need to do. So, I just, I really like it because I know the friction exists and the reason why we do it is because the work is inherently dangerous. So it’s kind of fulfilling to be like ‘we get to take it off your plate,’ you know?“
BEN
“I learned a lot about how to keep architecture simple and how to not overcomplicate things.
Johnnie and Marc are both very good at the ‘don’t prematurely optimize’ mentality. And that’s something that I’ve had trouble with in the past.”
JOHNNIE
“You start to understand when you solve problems, you’re normally solving now for what doesn’t work rather than what does work; because there’s always multiple ways to solve the problem, but oftentimes we’re always like ‘what’s the first thing that works?’ But I think what I’ve been learning is [that] you want to remove ambiguity all the time. So you want to remove things that don’t work and then leave yourself with a set of options.“
LUCAS
“I think the most important thing is there are many ways to solve a problem, and I learned how to find a solution, the best solution, for this issue. And just thinking in the long term, I think that’s the key.”
MARC
“I’ve had the chance at Opslock, when building the backend, to actually be part of the discussion about the design, the architecture, and how to tackle problems.”
“I have learned a lot about how to tackle the problem and what matters and what does not matter. Cause there’s plenty of stuff to fix all the time. I don’t run out of stuff to do, but you have to be able to know what needs your attention right now and what can wait. And it feels weird sometimes to say here’s a bug, but I won’t fix it. Even though I notice it, even though I know I have a good idea on how to fix it, I just won’t fix it now.”
“So yeah, I learned to prioritize and also at Opslock, I’ve been allowed to fail. Like there are things that I’ve implemented and it turned out to be very bad, and I just propose another solution for my mistakes. I said, well, we should do it this way instead. And I was allowed to redo it. It was not like: ‘no, you had the chance and we’ll ask someone else’ or ‘we’ll just keep that crappy solution because it kind of works. It’s fine.’ If I know how to make something better, I’m allowed to do it. So that helps the learning experience.“
MICAH
“For me as a developer, I learned a lot of new technologies because we’re very quick to, kind of, use new shiny things, which is a fun part of being a startup. If you want to implement a technology, you can fight to do it… If you think it’s going to give business value.”
“I think being your own advocate too, is another thing that you have to be in a smaller team. Maybe in a larger team, you can kind of hide in the background a little bit more.”
“This team loves to share excitement, and I think that’s a lot of fun. If you make a strong case for something then people will be like: ‘yes, we do need that. Let’s get it moving!’ Whereas in larger teams, I can imagine there’s just more, a little more bureaucracy to making those changes.”
AIDAN
“So we’re slowly building the CI that we want. Bryan listens a lot to his engineers. Not that he’s like… sometimes he has his ideals and he may be stubborn sometimes. But I mean, if you have good arguments, he will listen to you. Like, He didn’t know nothing about Scaffold, about Memento and all that, but Marc-François presented those and said: ‘look, it could be useful’ and he said: ‘okay, I don’t know what it is, but it seems good. Let’s go ahead.` So slowly, our CI is getting better and better.”
BEN
“Everyone is tech savvy. They are completely comfortable with just instantly hopping in on video calls or, or screen sharing, or using a Visual Studio live sharing. I think that’s the biggest… There’s the least amount of friction collaborating with people at this company that I’ve ever experienced so far.”
MARC
“I might be biased because, as someone who’s part of making the developer experience, I’m building the tools.”
“My favorite part is that if you have a brand new computer and you’ve just got access to the GithHub repo to get the code, and you have Docker installed, it’s one line, pretty much one line, and you’ve got your backend running and you can open the app. You can add users, add companies, do tasks. Like the friction is pretty low. I know it’s not perfect, but it was worse in the past. And it just, it keeps getting better.”
BJORN
“I feel glad that we have these, kind of, building blocks [from the Design System,] to speed up development. And yeah, sometimes I’m looking at files just full of Design System components and nothing else. It’s really cool to see.”
“Another thing is we have very extensive tests. I mean, for CI. So every time we do some changes currently we have a big list of CI checks that we do. And the good thing is we always have them green these days and it’s really assuring as a developer that we’re not missing.“
MICAH
“I think that the design system was a really smart move from the get-go. Just because previously we had used libraries, and there’s a lot of great libraries out there. It’s not to say that ours is the best. […] it just lets us have a level of control and customizability around the application that might be hard otherwise… and it ensures consistency.”
LUCAS
“Yeah, many things! I really like [that] we are building a fantastic CI on every repository, and it’s cool DX. And then secondly, I really like the group discussion[s we have] to solve the problem, and anyone can propose a solution and then we figure out our best fit.”
“Also I really liked the hackathon. And we can, besides the customer request[s], we also have the chance to propose our own requirement, which we think of, if we think there’s a chance we can help the customer in another way.”
SHAWN
“I mean, besides, you know, working in an early stage startup and working on a good team, what I would say is… The mission of Opslock is more compelling than a lot of engineering jobs out there. You know, there’s so many tech companies where you’re like just creating AB tests for some ad or: ‘which user interface is going to get more clicks than this one.’ It just feels so soul-crushing to me. I was nearly hired at a company like that, and I’m so glad I ended up here instead, because at least I feel like, oh, it’s very clear. There’s a very clear goal here.”
“I just feel like, look, whatever industry it is, people are losing hands and stuff, doing this, right? And hey, if we have software that, you know, reduces the number of hands lost per year, that seems like a positive outcome.”
“You can feel proud and excited about that without any sort of moral qualms within yourself. And I think there’s a lot of technology companies, not all of them, but there is a good amount where I would feel somewhat morally conflicted about the success of my own company.”
AIDAN
“When I get a little stressed and all that, and I’m like, oh, I just think of the team. And I like the colleagues I have.”
MARC
“There’s no unnecessary pressure put on me. If I have good ideas, they will be listened to. The tech is also cool to play with, I think, if you like Go. I guess on the front end, I suppose so too, I don’t do front end that much, but Svelte seems pretty cool. There’s also a good culture… The tech culture is there. People are interested and passionate about the tools they use and the programming language, without being too much… What’s the word? Well, without being fan-boys in a way“
“We like cool tech, but we like cool tech that gets things done.”
BJORN
“I would say that if you’re working from anywhere else, not in Canada, then take a shot. The team has been really, really helpful in making you part of the team and making you feel included. Anyone, new hires, feel free, not just in Canada, if you’re anywhere else, it’s a good opportunity.”
ME to LUCAS
“Other engineers call you the machine. Why is that?”
LUCAS's response
“I don’t understand when Joe called me that the first time, when I was in Opslock in my first year. I did some research actually. It’s like… just doing something like a robot and it’s never stop[ing] or some explanation like this. I find that it’s a positive compliment, so I accept it [laughs].”
“So I think for any potential hires, I think I can say that we grow very fast, we are still young and we have a lot of things to learn. So we welcome everyone that wants to learn new things and wants to grow together.
MICAH
“What’s exciting about working on a product like this is it’s not inherently super esoteric. It is in some ways, when you talk about predictive mitigation for instance, that could be seen as a little bit out there. But I think we’re making something for everyday people to use who have important roles in society. So I think that’s neat and fulfilling.”
That concludes the responses from the team! Interviewing my co-workers was a fun, collaborative, and insightful way to reflect on my first year here at Opslock. I’m happy to be able to share that insight with you in this post. Thank you for reading. Thanks also to the engineers and to Melanie, Opslock's designer, for making the line-art illustration for the header image of this post! If you are interested in joining the team, please visit Opslock's careers page here.
