What is Dev Like at a Canadian Startup? šŸ¤”

Elliot - Jan 3 '22 - - Dev Community

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.


How would you explain something youā€™ve worked on to someone outside of Opslock?

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.ā€

An illustration of a boat communicating with a building in a 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.ā€

What is the most interesting part of your job?

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.ā€

An illustration with ON and OFF connected to 0 and 1 and a Svelte logo

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.ā€

What is your day-to-day work like?

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.ā€œ

Whatā€™s your take on the mission of Opslock?

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.ā€

"If it's not simple, it's not safe"

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?ā€œ

What have you learned while working at Opslock?

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.ā€

Whatā€™s your favourite part of Developer Experience (DX) at Opslock?

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.ā€

"New tech", "Good CI", "design system", "colab & lead"

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.ā€

Anything else youā€™d like to say?

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.

. . . . . . . . .
Terabox Video Player