Having worked in diverse companies as a software leader, Royi Freifeld has a diverse background in backend development, security, software architecture, and dev team management.In this talk, he shares his insight into what keeps developers happy.
Perfect. So, welcome everyone. My name is Amal Massoudi and I am your moderator for today. Welcome Royi, and a warm welcome to everyone who is watching us from home remotely. So, if you have any questions during the talk, please feel free to use swap card to chat there or if you are in the room, I will bring you the microphone at the end of the session so you can ask all of your questions.
So, without further ado, the stage is yours, Royi. Enjoy.
Thank you very much. So, hello everyone. My name is Royi and I’m very excited to be here and to be talking about what developers want and how to be a more joyful developer. Let me just share my screen for a minute and we can start. Okay.
Cool. So, my name is Royi. I’m a team lead and an architect at Frontegg. I’m a retired officer from the OFEK software unit in the Israeli Air Force, where I served in many different tech roles for many years. I’ve been playing the keyboard ever since I was six years old, and at some point I even wanted to program a synthesizer, but that never happened.
I love snowboarding. I’ve been postponing my vacation, unfortunately, for almost two years due to recent COVID events. And, I’m a dog person, but I’m owned by two cats named Sushi and Soya. What I’m going to talk about. So, ever since I started coding, I learned what makes me productive, and I wanted to learn what makes me a more productive and a more happy developer.
But every now and then I find myself frustrated and angry because things are not going as smooth or as easy as I would like to have hoped. A developer can find himself fighting with the programming language and the frameworks and dependencies and a lot of other things like the architecture and the build tools and that’s just the techie part of things.
You can have an argue with your boss, maybe or just want some help from someone on GitHub, but hoping that someone will approve your PR at some point if you just opened a bug fix. So, in the next 40 minutes or so, I would like to share my thoughts on how to be a more joyful programmer, how to find interest in code, and how to be more productive.
Some of the things I’ll show you seems like a bit common or a common solution, but we tend to overlook the small things, we tend to overlook the successes that we create along the way. I’m going to show you how to learn from each step and how to give myself credit when I do good things for the company, the code, or myself.
Obviously, this is going to be a highly opinionated session, so just bear with me. And, I’m not going to trash talk any language, but TypeScript is our main language for now, so just bear with me. So as I said, I’d like to explain what my view on developer’s misery journey is. As I said, there are four main pillars for developer’s misery.
The first one is the infrastructure and the tools. That can be your day-to-day things that you use, can be the programming language, it can be the build tools that you use. These tools are things that stops you from moving forward or moving fast. The SDKs and the API are the second pillar. These are the third-party libraries that makes your day a little less happy.
Even though it seems like a good API at first, sometimes along the way, things are not really as it seems. The third part is the community. The people behind the GitHub comments they can be really nice at some points, and in some cases not so much. And, the last thing is the work culture or the work environment, and that’s basically everything else.
But, you know, you can argue with your boss and you can have not-so-nice colleagues. As I mentioned, I would like to share my thoughts from a real-world story using these pillars. And, don’t worry, no Java developer was harmed during that session.
Now, this is me, I’m an engineer. I’m usually healthy and not angry and quite focused. And, someone at the company decided that we’re going to use TypeScript as a main language and I need to create a new service.
This is where my journey of four misery pillars starts. The first one is the infrastructure and tools, and this one I call being frustrated. So many of you know how to start a new JavaScript or TypeScript project. You can start from scratch by just doing npm init, and then you only have one file named package.json and then you need another file to configure TypeScript.
And, you only got these two files, which I don’t know how to start with them. How do I continue from this point? At this point I’m frustrated enough, but oh well, let’s just try to carry on. The next part is finding the right microservice framework. From previous working experience, obviously, I need to find some sort of a framework that will handle HTP request or send some messages to a queue.
In TypeScript or JavaScript we have Express or Fastify or Happy or many other things and I need to choose one that looks very promising and I found one. And, while my procrastination kicks in, I just decide to open some issue on GitHub because I just wanted to ask some sort of question and obviously GitHub is not a good place to ask questions, but don’t worry, they have a question type issue so I digress a little bit, but let’s continue the journey and we’ll get back to that issue later on.
The next thing is probably going to be something like integrating with the database. When it comes to integrating with the database we have several tools or ORM that we can use. In TypeScript, we have Sequelize or TypeORM and each of them has, like, some sort of disadvantage or advantage in some parts.
So, Sequelize is the more stable one while TypeORM is in zero point something at the moment. And, Sequelize has the better documentation while TypeORM has somewhat lacking documentation. But TypeORM is a little bit easier to use with TypeScript, and it has some sort of integration with Mongo, but I’m not sure yet it’s going to provide any advantage along the way.
What do I do about migrations? Will I use the Sequelize or TypeORM migration or maybe something else like Flyway or Liquibase, or I just found… By the way, I found a new cool framework called SchemaHero that might interest me along the way, but I’m not sure yet, should I use Active Record or maybe Data Mappers?
Which is the better one to use, the repositories or entity manager? Should I even use the Query Builder and let’s not forget many, many more configuration files that I need to understand and add at some point in the future? But obviously, these are many considerations that can lead to a never-ending quest for the right or the best framework there is.
So one last part about that thing is using the right dependency tool. So, obviously, there aren’t many decisions that we can make when we use TypeScript or Java or any other language. There are a limited number of build tools that we can use. But after using many tools and language, the decision can make a really bad impact on our developer journey.
One way we can have dependency held with Java, or we can have dependency held in NPM, or maybe we lack a standard way on how to build or how to write scripts ourself. For example, in NPM, there is no way to just build the stuff, we need to write some sort of script in order to do that.
In my opinion, this is the one thing that can kill my time and waste my time for no good reason at all. So what works for me in that case? As a startup, we need to deal with these issues on a day-to-day basis. We’ve grown really, really fast and along the way, we needed to develop new microservice every month or so.
So, we’re now at a point where we have, like, 20 microservices, and each one of them looks slightly different than the other. So, obviously this is not a maintainable or a healthy situation to be in. Sometimes the developer can be a little bit frustrated or confused, and I have some sort of solution that makes me a little bit happy, a little bit less nervous than what I should be.
So, the first thing is just to accept the situation, I’m going to give myself to some JavaScript God and understand that there’s nothing I can do about it. This is actually, for me, the hardest thing that I can do. The second thing is I’m trying to find how not to waste my time.
And, what works for me in this case is to standardize everything. I can standardize the language, I can standardize the REST endpoints, I can standardize the queue messages that I sent, I can standardize everything. And, I’m taking some sort of API-first approach.
I think about what the experience of the client should be and then start implementing. I’m using some tools like OpenAPI, or gRPC, or Protobufs, or Avro to spend more time on domain flows and not on DTOs. I can even try to take the extra level up to generate the entire code or crowd messages or message handling in Kafka queues or in whatever it is.
So what we did, at some point, we created some sort of standard to eliminate any repetitive boilerplate. And, again, we created just one standard. After we created that standard, we created the template, single template, not many templates, just the single one and many libraries.
Why we did that? Because templates tend to be a little bit messy at some point. Templates tend to be a little bit messy, and once I generate the first one, it becomes really hard to use that template over and over again. You can’t really do anything once it’s generated the first time. So, we can use some sort of scaffolding or templating tool like Maven Archetype, or Cookiecutter, or NX, or Yum and we try to do it wisely.
Since templates are getting a little bit messy, we extracted these many libs as possible to enforce architecture and serve as building blocks for that architecture. Obviously, we’re going to incorporate also linkers, and folder structures, and naming conventions, and everything all along the way also Dockerfiles and Helm Charts and everything DevOps related.
This is what we did. As you can see here, we have the Frontegg backend template with the NestJS packages and other packages that are not NestJS related. And, as I mentioned, only one template and many, many libraries that we use.
The other thing that we do, I build tools that support my work. I invest in these tools. I’m making them feature complete with comprehensive CLI and…as if it will be released to one of our clients. Here, you can see a project I created to support my day-to-day job, which takes Protobufs and sends them to…bundles them up and zips them together and creates actually messages, instrument everything, and sends them as Go Modules to a repository, to an online repository.
And, as you can see, it’s a very comprehensive and very feature complete with many flags that we can use to support the work that we do. The other thing I did is making testing a little bit easier.
This is another tool I created to mock AWS APIs, for example, S3 or SQS and now we can test our environment locally on our machine. We don’t need to go to AWS anymore.
And, obviously I’m a Java developer living in a JavaScript or TypeScript company. So, please use Java and Maven as much as you can. So, what to do first? So, as I mentioned, I created some sort of standard, some sort of written standards that will try to keep some sort of consistent feel to our APIs.
I’m saying try to keep a consistent feel because obviously actually doing the API consistence in a startup company, it’s not the easiest thing to do. We need to move fast and as we go, we tend to break that feel. I created a simple guideline as to how an endpoint should look like.
And, obviously, again, let’s be reasonable here, it’s okay to break it along the way. The other thing to do is use Avro, or OpenAPI, or Protobufs, obviously gRPC, and Thrift, and everything else to try at some point, I still didn’t do it, but try at some point to generate the entire code, generate from the controller level all along the messages that we send in Kafka.
This way, we spend more time on the main flows and not on DTOs. What have I accomplished? While I did all these things, I managed to accomplish many things, and I need to give myself credit for that.
So, the first thing is focus. In the long run, I’m going to be more focused. I’m working effectively and not implementing things over and over again across multiple services. I increased my productivity by remembering not to repeat myself, obviously and as of this point, I will not spend time on boring parts of the code. Instead, I spend more time to implement critical sections and critical business processes.
I deliver code more often, and over time, I’ll have some sort of set of prepared solution that I can use, for example, that code generation tool and that AWS mocking library. Another thing that I need to remember is by being my own client and thinking what my colleagues need, I can be more responsible over things that I write.
I actually care about the things that I do. And, obviously that’s awesome, and we need to celebrate that achievement. Pillar number two, integrating with other tools. So, this part is why I dislike or why I don’t like third-party integration. Obviously, at some point I went back home after creating all these tools, and I’m ready for another great day at the office, and I got a new task to integrate with some product named, Awesome Product.
Now, if you’ve never heard about Awesome Product, they are a big company. They have quite a reputation, and it feels like integrating with them is going to be easy and fairly fast. And, I did some check and luckily they have an SDK that I can use. And, just to be on the safe side, I also checked the API and the documentation, and it’s practically a masterpiece.
The API and documentation is really easy to read, really easy to understand, and it maps completely the domain. So, obviously I start coding and everything works out great. I even managed to get a POC ready really, really quickly and see that actually that Awesome Product is well suited to our needs.
And, at that point, all I need to do is somehow make it part of my code, you know, standards and everything. After a few hours of coding, I see something that just drives me a little bit crazy, and it’s that thing. What do I do with this thing, what is metadata any? Is it a string, is it comma-separated or is it an object?
Why there’s no documentation in the code? Obviously, I’m going back to Awesome Product documentation and I’m looking at the documentation to understand what I need to do and obviously I found out it’s a shallow object and I write some code and see that it’s working and everything is okay.
And I’m continuing my day and as I continue coding, at some point I find another one of the… I’m starting to get some sort of weird issues, some weird errors that I don’t know where they come from. I started to debug the API and the SDK and this is an example of one of the errors that I got. Now what should I do with that error?
What do I do with it now? So again, I’m going back to the documentation and I’m trying to figure out what happened and the problem is that there is some problem with the SDK, but obviously it seems like I’m exaggerating a little bit.
But I’m going to show an actual code I wrote to handle similar problems with non-type errors. I actually had to look at the stack and just match strings and see if it starts with that weird string. That’s an actual code I took from one of our services. I had to remove obviously the rest of the string because of course there are many, many string that look like that and at some point it started to look like a if/else statement.
And, even now when I’m looking at that code, this is how I feel and I need some sort of coffee break when I read that code. And, I can tell you about the code review later on, but it was quite harsh and even the reviewer said I don’t know what’s going on.
Why did you do that? So I went back to my desk and I opened an issue to GitHub to Awesome Product GitHub page and ask them to add some sort of types or generics or some better error handling. So what works for me in that problem? Obviously my goal is to create a clear understanding of what is expected of the programmer to do.
I want the programmer to read the SDK and just know what he needs to do, not just me, but my colleagues and everyone else using that code. So, I contain the problem and encapsulate it into a single place. Obviously it sounds like the reasonable thing to do.
I contained it in some module and put it somewhere safe so no one will ever touch it and I create a folder with the domain level errors, and I wrap the untyped fields or function with my own type variables and arguments. And, obviously I can always add it to some sort of the libraries packages we talked about and I can even take it a bit further and open source it, or even consider writing some sort of blog post about it.
But that’s optional. So, what was the first thing that I do? Obviously I turned strict language feature on, and I’m trying to use some sort of linter at that time. But at least I’m making sure that my code is clear as possible, and I am making sure that everything is typed.
I know that some people will just tell me that types just stops us from moving fast, but eventually, even if a code doesn’t have types, I still need to pass some sort of parameter to that function no matter what it is. I create some sort of type safe SDK for that API and I remember that since I didn’t like that happening to me, I want my clients not to have the same experience.
So, I create a type safe SDK for my API and I add functions that will expect some sort of the exact types that we need. What have I accomplished? Again, I’m looking at what have I accomplished doing that. So, I made my system more stable.
I increased the stability and reduced failures over time. I eliminated errors for other developers and that way, the system will be more robust along the way. Obviously, I learned a bunch of new things, how to make an awesome product, how to use that awesome product, and how to make my code a little bit more stable.
I’m faster at decision-making. I learned how to use Awesome Product, but I learned also if I use similar products, I know what to look the next time. And, by learning how not to write APIs and SDK, I learn how to be a better programmer because as of this point, I’m a better developer and I’m better service providers because I think about my clients.
And, that’s awesome. That’s just awesome. I am making my company better, I’m making myself better by just looking at that part, by doing that part. The third part is the community. So, again, I’m going back home and a new exciting day arrives, and I look at my inbox and I see that I got new responses for the issues that I opened.
And, I’m thinking to myself, awesome, I could finally catch a break, or someone finally helped me, and maybe just, maybe I can fix that nasty code that I wrote. And, this is an actual GitHub issue that I opened that has still yet to be answered. As you can see, it was opened a year or so ago and I guess that’s not the case.
No one is going to help me in that case, and that’s really frustrating to just get the plus one that another one wants that issue to be handled. Another thing is that someone just sends me to a Discord channel or a Slack channel just to be ignored over there.
And, obviously that’s not always the case. That’s not always how it looks. And, this is an issue that I opened for Eclipse MicroProfile OpenAPI. And, there’s another one that I opened for JWT authentication. And, both of these issue were accepted to the spec, which is great. And, at that point, I really want to give a big shout out to the guys in MicroProfile and Quarkus for being awesome.
They’re just super responsive and every time I needed their help, they helped in a minute and helped me debug my code. So, really, thank you guys. So, what works for me in that case? I take the time to read the code. I’m considering the third party, the community, I’m considering some sort of code review. I’m learning new things by learning how people write code.
For the first issue, I learned how to use CoffeeScript in that part. I find my way around the problem obviously, and I’m sending some sort of comment back in the GitHub page and probably making the community a little bit better by making it better myself. If possible, I open a pull request, obviously.
And, from that time, from time to time, I’m going to check back with the GitHub page, with the GitHub issue and see if it was fixed. And, also it makes me, at least what I’m doing is just going back to the library and see if something has changed over time and maybe there are many more contribution that made the library a little bit better.
What we do at Frontegg is actually we encourage customers to be part of the community. What you can see here is one of our customers that actually opened a Terraform provider for Frontegg, which configures everything, and it worked really great for him.
The other thing is the rise of dev success. We have great DevSuccess here and it helps us so much by being super responsive and engaging in our community at Frontegg. Again, let’s see what we have accomplished by making the community a little bit better. I obviously learned by reading code.
For example, I learned C programming by doing an assignment with a friend with amazing skills. So, if I take that experience and learn from other people’s code, I can actually be a better developer myself.
I’m helping others to solve issues I have faced, and that way I’m making the community a little bit better. And, eventually the community is making me a better engineer by making me do all these things even though they didn’t help me at that time. And, again, super, super great success.
A great achievement that we need to celebrate that. Let’s go back to the pillar number four, the work culture. I want us to rewind a little bit and think about all the things that could have gone wrong if we had bad culture.
So, the bad culture could be no motivation for employees to grow, can be no explicit expectation or requirements for developers, frequent context switching, the lack of transparency, no appreciation for work/life balance, there’s no feedback loop, no team mentality, hostile work environment, we don’t learn from failures or even it’s a bad thing to fail.
These are just part of the things that can make a bad working environment. At that time, I’m thinking to myself, can I do something about it? How do I reduce the mental load by thinking all the time about these things? What works for me is to first of all, just take a minute to myself and state my goals.
By stating my goals of what I want to achieve, it makes it easy to be focused, it makes it easy to know what I need to do next, how I need to act, do I need to talk with my boss, do I need to fix the issue, do I need to, I don’t know, set an example and do some sort of talk to my colleagues.
And, also I set an example to what culture I wish I had. I set an example by being more open, I set an example by taking the extra step and creating tools, I’m setting an example to be a more friendly coworker obviously. And, I take responsibility all the time.
If I can make some sort of difference, I will do it. I’m trying to be open. It’s always easy to complain, it’s always easy to blame others. If I wish other people to be open with me, if I wish people to share their thoughts with me, I need to be open first and always, always, always assume best interest. My coworkers are not here to make my life harder.
Everyone wants to get their work done, and we are all on the same boat. So what have I accomplished during that time? I keep the negativity in check and stay focused. I remain focused on what needs to be done next.
I remain focused if the issue is really just in my head or I can do something about it. And, I’m creating some sort of chance for cooperation. I’m saying chance of cooperation because we open the way. I allow my colleagues by doing these things, I allow my colleagues to cooperate with me, I allow my colleagues to be more open with me, but they don’t have to do that.
So, it’s just a chance of cooperation. But the chance is better than no cooperation at all. By being open and setting an example, I create a chance for cooperation with my colleagues, which is a great success. With better friendship and better cooperation, there is better work culture. So, I’m reaching the end of my talk and I have some final thoughts about it, how to be a more joyful programmer.
So, first of all, remember my successes. I grow as an engineer with every piece of code that I write, I grow as an engineer with every talk, with every feedback, good or bad that I get. I take pride in my code, even if it has bugs or reviews. I grow as an engineer with every pull request I open to open source. There’s always time to learn and improve.
It’s either be code reviews or third-party code that I read, or articles that I read, or new technologies. I always plan on how to make my job easier by creating tools, I plan how to make my job easier by making things a little bit more smooth. Remember that I’m part of a team.
I teach and help other developers, my colleagues, and it’s part of my job. A team makes the product better, a better culture, a better product. And, always be open and state your goals. Thank you very much.
Thank you Royi, very much for this very, very interesting presentation of yours. So, now it’s time for the Q&A. Does anyone have any question regarding the presentation? Not really as I can see in the audience right now, I think no one has a question, but let me check the chat really quickly.
Okay. So, in the chat, we also do not have any questions. We do have one question.
Hi, thank you for your presentation first of all. I have one question. Of course, you have been talking about the happiness of developers mostly in the community sense, in the sense that you try to make yourself happier by having a better collaboration inside the company and everything…whenever you are facing problems with customers instead.
So, whenever you have problems that you cannot solve internally, it’s just a problem that really, I don’t know, you have a bad communication or you have any kind of problem which is not directly dependent on you and that’s not so much you can do about it, how can you cope with that?
So that’s a great question. Thank you very much. So, what I’m thinking about when there’s an issue like that is that if I don’t have anything that I can do about it, why is it bothering me, why do I need to think about it?
Obviously, if one of our customer has some sort of issue, we need to solve that. It doesn’t matter if he yells at me or he doesn’t agree with what I do or the prioritization, but it is what it is, eventually, that’s what we do at the moment. Obviously, there are many things that you can do by escalate the problem to your boss and your manager.
It’s not a matter of power but if I have nothing that I can do, why do I need to care about it, why does it bother me at all, why does it bother me at that moment?
Did I answer your question?
Sort of actually, yeah. It may happen that it’s still a problem that affects you and it can be frustrating so, I don’t know, you have just a slow communication, so you have a lot of inefficiency or, I don’t know, you are requesting an access and they take one month before they give you access to some server, I don’t know, whatever problem it may happen.
And, really you get this frustration like, “This is a real problem, but there’s nothing I can do about it.”
If there’s nothing I can do about it, I don’t need to be so upset about it. I mean, if there’s nothing I can do, let’s just do things that I have some sort of not power, I forgot the word. But if I have some sort of effect, I can do something else, I will just do that other thing.
I mean, if it’s not your responsibility, you can’t do anything else. So, just do whatever you can. I mean if someone needs to give you access to some server and you can’t, I mean that’s not your problem. You can always talk to your boss and escalate the problem in that case.
But let’s just look on what I do now, let’s look at what are my successes at the moment. I did a lot of things, I created code, I read code, I learned new things, but at the moment, I don’t have access to that server and there’s nothing I can do about it.
Thank you very much Royi. So, are there any more questions? Okay. So, I guess the audience here understood everything that you had to say today and on the chat I do not see any more questions, which means this is it.
The Complete Guide to SaaS Multi-Tenant Architecture
