Why All Companies Need a Code of Conduct, with Daniel Norman
Welcome to today’s edition of CTO Studio! Does your company have a code of conduct? Do you have a verbally understood code of conduct, or an actual written one that is in your workplace for everyone to see?
Our guest today, Daniel Norman, explains why you need the latter and why it’s so important to the health and longevity of any company, including yours. Daniel is the current CTO of gudTech whose love for technology began when he was a kid with a Commodore 64! Today he shares how he went from playing with Commodores to his CTO role today. Join us to hear his journey on our latest episode of CTO Studio.
In this episode you’ll hear:
- What is most impactful on the success of a company?
- Why did gudTech brand Retail Ops separately?
- Why does language in code of conducts matter?
- What happens in the absence of a code of conduct?
- Rust vs. Go: what are the pros and cons of each?
- And so much more!
Daniel’s first exposure to technology came early on as a kid. He quickly moved from the Commodore 64, then to the 128 and on to working in a school district servicing their computers. His undergraduate work was in technology and he interned with several engineering firms and then was employed by QualComm for several years before finally landing with gudTech.
When I asked Daniel to tell me more about the concept of codes of conduct and why they matter so much, he explained within our organizations we should be talking about them, formalizing them and making them a pillar of our business.
They are not meant as boilerplates but are meant to be celebrated as part of the daily discourse and daily water cooler conversations within our companies. Codes of conduct should be official documents that outline the values of our companies.
They can vary depending on the company but codes of conduct make it clear to everyone what are the values of the company. When these values are in bold print employees aren’t surprised by them, everyone knows these are the values you uphold as an organization. In a nutshell, whatever your values don’t just talk about them, write them.
Also be aware of the subtleties of our everyday language, like using the term “guys” to refer to an abstract group of people. If you can name the group you are speaking to and they are all men then guys is appropriate. But there are so many disparities in gender and for various other protected groups that it behooves us to be conscientious of our language and our values in our organizations.
Next we moved on to talking about Rust versus Go (two programming languages). I wanted to know if they have used Rust in their Retail Ops product. Daniel said they don’t but they do have a good amount of Go. In fact, they are moving more towards Go for application programming on the server side and using Rust for systems programming.
He explains why and how they use each. For example, Rust would be something to use to write a very high performance piece of your code like a database or a network stack.
While Go has addressed a lot of their systems programming issues, and there have been databases written in Go that work pretty well, it isn’t as good as Rust.
Go does a good job with certain types of problems as long as you are okay with the starting assumptions the language makes like you’ll have a garbage collector and green threads in everything. He recommends using it on a case by case basis, you have to decide when it’s okay and when it will be bothersome for your users.
As far as Rust, safety from data races is the #1 reason to use it. Any time you are building mission critical code there are a host of subtle errors the programmer can make and inevitably will make, unless you have a language like Rust which enforces certain invariances. Rust is very strict.
It’s so strict that Daniel says your first few weeks with Rust will involve a lot of swearing and you will hate the compiler! The compiler will be your enemy. But somewhere around week 2 or 3 something flips and you’ll learn to love the compiler because when it does finally compile it will probably be right. There’s a host of different problems your program will not have that it would most certainly have if you used another language other than Rust.
After talking a bit more about Rust and its strictness regarding the key concepts of ownership and borrowing, we also touch on the San Diego Meetup group for Papers We Love before finishing up with some of Daniel’s biggest learning lessons as a CTO.
Join us to hear the details on those topics and what Daniel is reading and listening to on today’s CTO Studio.
Please rate and review our podcast!
Share This Story, Choose Your Platform!