#282 Chris Simon from electrical engineer to CTO coach

Resources

Highlights

Enjoyed the Podcast?

If you did, make sure to subscribe and share it with your friends!

Post a review and share it! If you enjoyed tuning in, leave us a review. You can also share this podcast with your friends and family and share lessons on software development.

Become a supporter of the show. Head over to Patreon or on Buzzsprout.

Got any questions? You can connect with me, Timothée (Tim) Bourguignon, on LinkedIn, per email, or via my homepage.

Thank you for tuning in!

Transcript

⚠ The following transcript was automatically generated.
❤ Help us out, Submit a pull-request to correct potential mistakes

Chris Simon: 0:00
I think that's probably the thing I look back on and go. What do I wish I had done earlier? And it's engaged with the community. I was so just buried in my work and like head into what we were doing. I didn't really look up and look around at the world and the fact that there's a broad community of developers and software people that are supporting each other and sharing ideas and better ways of working, and it took me a long time to connect with that and I wish I'd done it sooner because it would have been really helpful.

Tim Bourguignon:

0:27
Hello and welcome to Devilpurs Journey, the podcast bringing you the making of stories of successful software developers to help you on your upcoming journey. I'm your host, tim Boulgigno. On this episode, I receive Chris Simon. Chris is a startup CTO coach, helping startups realize their vision and new CTOs flourish in their roles. He also supports executives and boards with strategic technology advice and engineering teams with training, mentoring and consulting in architecture quality DDD that's, domain-driven design and TDD, test-driven development. He's a regular meetup and conference speaker and support teams using DDD. He recently launched Contextive and co-founded the DDD Australia Meetup. Chris, a warm welcome to Devilpurs Journey. Hi Tim, thank you so much for having me Warm warm is relative. It's your degrees in Germany. Right now You're in Portugal. It's not as warm as it should be, but a warm welcome anyway. It's still warm enough for me at the moment. It's warm enough, fantastic. But before we come to your story, I want to thank the terrific listeners who support the show. Every month you are keeping the DevJourney lights up. If you would like to join the spying crew and help me spend more time on finding phenomenal guests than editing audio tracks, please go to our website, devjourneyinfo, and click on the support me on Patreon button. Even the smallest contributions are giant steps toward a sustainable DevJourney journey. Thank you. And now back to today's guest, chris. As you know, the show exists to help the listeners understand what your story looked like and imagine how to shape their own future. So, as usual on the show, let's go back to your beginnings. Where would you place the start of your DevJourney?

Chris Simon:

2:17
This is an excellent question and it's a very long time ago. I have to get back to it and let's get there. Yeah, I think probably when I was six or seven, it was my first exposure to software development as a. I was very fortunate. My uncle was a professional software developer and he helped my family choose our first family computer, which was an Apple Fat Mac so-called Fat because it had 512 kilobytes of RAM Wow, and no hard disk. And I look back at the history of computers now and actually was quite impressive compared to you know what I'd come before. But yeah, it had a basic interpreter on it and he was very kind and I showed some interest in it and managed to pick up a book which I still have the book actually at home, you do, yeah, yeah, it's like printed with a typewriter, I think, with like a metal spiral binding, but it's full of programs and I would transcribe the code into the basic interpreter. I mean, at the time I obviously had. No, I couldn't interpret it. I was six or seven and it didn't work and my uncle would come over and say, oh yes, this is why there's a syntax error. I said what's a syntax error? So that was my first exposure to it and I really loved it. But it was probably a few years later before I found myself sort of starting to work out how to craft my own programs. But I would just, every time I could find a program I would transcribe it in. I remember there was a do you remember Mad Magazine? There was a Mad Magazine that actually came with a program listing in it on basic, with like 10, print this, 20, go to this. And it would just print out like a picture of Alfred in New and Said I remember getting that at one point I think it was in the early 90s by that point and yeah, transcribe that in. But then, probably when I was 13 or 14, I started realizing actually I can make up programs and I was fortunate. At my school there were a few other kids doing the same thing. We had a computer lab. In many ways I looked back on it. I did not realize at the time how privileged we were and how fortunate we were. I had access to this technology, had access to people to guide me and yeah, I think by 14 or 15, I was like writing games and mostly like clones of other games. So I had a clone of Tetris that I called Tetris, which you know so cringy in hindsight.

Tim Bourguignon:

4:39
No fine by me.

Chris Simon:

4:42
And then I thought you know, I've done a lot of basic, now I want to learn another language. So I thought I'd talk myself C with a book and got some graphic flybies and made another game in C with like a graphics library. You could load up bitmaps and all this kind of stuff and yeah, it just sort of took off from there. So by the time I got to the end of high school I knew I wanted to do something with computers and programming at university. But then I got a scholarship to do electrical engineering and I did not get a scholarship in any of the other computer programming courses I'd applied to. I still don't know why, but I decided, well, this scholarship will be really impactful, so I'll take that and I'll just choose lots of programming electives. And I was able to take a lot of software electives through that, which I really appreciate it. But I actually am quite glad that happened because I think it gave me a much better understanding of you know how software fits into a hardware landscape and like the full stack of you. Know when you move a mouse or when you write a line of code what's actually happening at the bit level in a CPU and, I think being able to appreciate that full stack has been quite helpful through my career, probably jumping ahead to explain exactly how, but I kind of appreciated it. But I certainly did focus on software electives and then I ended up choosing, like a data compression which sort of fit into electrical engineering, because it was about signal processing and electrical engineering has a lot of different subfields. In one of them is signal processing and so, yeah, data compression went into it. So I was able to write some code to explore different image compression algorithms and that was lots of fun. And, yeah, then post university work. So I don't know, that's 15 years, several five minutes, and you asked what was the start of the dev journey, but it was definitely those early formative years, copying program listings out of printed books and then trying to write clones of games that I had seen.

Tim Bourguignon:

6:33
That was definitely the start of it all and during many bells. I copied a lot of listings and made a lot of mistakes and was happy when there was a check, some at the end of the line. Sometimes, when there wasn't, I was just looking at this wall of text wondering why is it not working? I have no idea about semantics and what to really do, but there brings many bells, many bells. I don't to date you and I think you're a little bit older than me, but not so much and I think we were the last generation to really be able to do this, to go through a curriculum going all the way from electrical engineering, understanding the stack from bottom up, and really come at the end with a high level understanding of everything that was happening and expertise in high level languages to be able to program.

Chris Simon:

7:27
Yeah, I think that's probably right. I mean, when you look at the history of computers and software in general, it's always one of rising levels of abstraction and I think interestingly though, like we might say that we're the last generation to have that full stack. But already there are probably layers in the stack that we are oblivious to because they were already abstracted decades before and I think we wouldn't know how to use punch cards or like that's, or loading, like. I've got really into reading about the history of computing at one point and reading stories of people having to assemble their own machines from circuit boards that were shipped to them and then load in literally the bootloader by flicking a bunch of switches and then hitting go, like the binary thing, like, and I think you know. So it's interesting, here you say that we're the last generation, because I think that generation probably thinks that they were the last generation that's true Experienced the full stack, and here we are with our fancy floppy disks Whoa, you know.

Tim Bourguignon:

8:24
What do you mean? A floppy disk? Where are USB keys now?

Chris Simon:

8:29
So I think you know it's interesting, like every generation thinks they were the last one to have access to some hidden insight that the next generation won't have. And you know, the sort of relativity is interesting to me as well, that is true.

Tim Bourguignon:

8:42
That is true. I need to ponder that. But I still feel there's a difference to be made between the historical advancement meaning punching cards were a way to insert programs before there was another way that replaced it and the stack which is currently running on the machine beside me and which is still the same, or not still the same, which is from an electrical engineering standpoint, and how the main board is built and which components are in there and, for instance, which different kind of caches there are and memory management, etc. This is still true until it's replaced at some point. But understanding what's running beside you really from bottom up, this is something that I don't think every or the new generation is kind of overwhelmed with this.

Chris Simon:

9:34
I think so it's gotten just too big. It's forced to specialize and there are people that get into that stuff, but then they don't also get the opportunity to say, build websites or business systems. And definitely the people I know who are building websites and business systems often don't even know what a cache is until they get told oh, by the way, you're now the DevOps person so worrying about that stuff. But even then it's just in Amazon and it's a simulated cache, so who knows what's really under there? But that's probably a fair point as I look back and I don't mind being dated. So I was born in 79, I'm 44 now and I was at university from 97, and so I remember in first year university we were doing assembly level programming of like 8086 chips. But even those chips were over a decade old at that point and I'm pretty sure that the Pentium which was out at the time if we had had to learn how that Pentium chip was working in terms of pipelining and you know already at that point you had multiple cores. I think even already then it had become so complex that for us to understand the full stack we had to go a decade earlier to find the chipset easy enough for a first year university student to be able to comprehend it, and since then it's only gotten wilder and way more complex with that instance. There's actually multiple parallel chipsets and stuff too, but I honestly, even though I feel like I do understand in principle what's going on from the bit level you asked me to look at like a modern CPU diagram, I would be completely lost.

Tim Bourguignon:

11:15
You and me. Okay, so you did this electrical engineering degree, picking as many electives in software engineering as possible. Was it a fixed idea? You're going to go into software engineering afterwards. Was there some leeway in?

Chris Simon:

11:32
there I knew I wanted to write software. I did not at that time understand how the industry of software worked and so, like I sort of had this notion that, oh, you just get a job and you write programs, how great will that be. And again, my uncle, who I do a lot too, I think he had his own business which was a software business, and he gave me a holiday job coming in and writing some code for him, and so I got to see a little bit about how it worked, and that was my first exposure to understanding how important it was to write code that could be understood by other people, because previously all the code had been written for myself. And I think back to all my variables like A, b, x, z, whatever. You don't know, terribly don't, but you know the code worked and it was just for me and I didn't mind. But then I started writing this code for this company. It was just a little application on the side to help them with their licensing or something, and I remember it was just a summer holiday job, and so after the break, a couple of months later, we would exchange your emails and say how's it going? And they said, oh, we're not even really sure how your code works, because you've spelt the word license three different ways in the code base. I guess I was never claimed to be good at spelling and they're like, but we can't work in it, it turns out. Well, I managed to introduce these spelling errors in places where it just kind of didn't matter, because there were different class names or method names or whatever, and they were just getting really confused by that and I remember thinking, oh, I thought I did a really good job, but turns out maybe I actually hadn't. And I realized, like you know, it's just as important that the code works that it is that other people can understand it. And that was like just, I guess, the very first inkling of this idea that I had. Well, no, it wasn't an original idea. Obviously this is, you know, with hindsight I look back on and say, well, this has actually been the whole history of our field. It's like this is the central, most important idea that we've the field has been grappling with. But you know, I think when you first get into it, it's all about making it work. And then you realize, well, there's a limit to what I can do on my own. Now I have to work with other people and then, all of a sudden, the code has to serve multiple purposes, it has to work and it has to be understandable, and I just I'll never forget that, because that was like that first moment again. Oh, hang on, this is a thing I should start to pay attention to. It took a long time for me to really understand what that means and I think I'm still learning about it, to be honest, still thinking about different ways in which this phenomenon manifests. But yeah, that was definitely an interesting moment.

Tim Bourguignon:

14:03
So you mean the JavaScript minimized version that we read on the web is not a version that people wrote. There are some A and B and C variables in there and could well have been a teenager sitting there. Interesting. You said it wasn't the software industry that you pictured when before starting this internship. Was it just the working with People piece, or did you have some other preconceptions?

Chris Simon:

14:31
Yeah, yeah, definitely. I think now the working with People piece was something I didn't expect but was still. I really appreciated that. I liked that aspect of it. The part that I didn't expect from that my early days was that every program I had written up to that point was something that I wanted to write. And then you get a job and you have to suddenly write what other people want you to write and you have to write things for other people that are serving you know their purposes, and you don't have, I guess, the freedom and the kind of you know just kind of, hey, I wonder what this would do. I wonder what it would be like if I tried this and you just get to you know this freeform exploration, when you're just writing code for yourself, and then you have a job and it's like, oh, here's a ticket, here's a ticket with an acceptance criteria, make and pass and it's like, well, that's a different experience. But I think that was definitely again, I think, those two kind of facets of it. There's the interaction with your other, your colleagues and fellow developers, and then there's interaction with the people that you're writing the programs for. You know those two facets of it have become, I think, defining themes of my career, and where I've really ended up spending so much time thinking deeply about how they both work. And it's why I love demand-driven design, because I think it's the thing that helps you engage with the people that you're writing the code for, and I love test-driven development because I think it's the thing that helps you engage with your other colleagues, and that's, I think, why those two things have become foundational practices for me, because of these two relationships that are essential to being a software developer in a group, in an organization. But, that said, I still do, sometimes really mischievous, writing code for myself, which is why I now have an open source project which I'm literally the only person working on and I get to just make a decision to do it straight away, and it's great, although, really interestingly, last week I had my first contributor, community contribution to this project, which is actually really thrilling, and so, as much as I've been enjoying the freedom to just code without having to persuade people or communicate with them or convince them, it's actually really nice to have someone saying, hey, I wouldn't mind if I did this, can I help? So it's all good really.

Tim Bourguignon:

16:37
I haven't said what contextive does, but hearing news talk about spelling mistakes in your variables. Now I have an idea.

Chris Simon:

16:46
Yeah, this has been a career in the making. I might just briefly explain it, if you want to connect to the story. So, yeah, through we're sort of jumping ahead decades here, but I think through my career I learned about the field of domain driven design and really fell in love with it. There's actually my first conference talk was called learning to love domain driven design a tale of two products. It's like comparison of my first startup, which did not use it, and my second, which did. But on the second one, where we did use it, I really loved the concept of the ubiquitous language, this idea that we should try and intentionally craft a terminology like a language, not just a terminology, but a way of speaking about the domain that resonates with our stakeholders and which we can learn to understand and which are embedding that in our code base. And, yeah, so I came up with this idea of contextive, which is a suite of tools, starting out with IDE extensions, that allows you to put like terminology definitions in your repository and it will surface those definitions in your code, like when you're hovering over the domain term. And because it's tied to the domain terminology and not the code base, you get the same definitions whether you're in TypeScript, javascript, java or C sharp anywhere, like if you're in the domain of e-commerce and you have the term order. Anywhere that you use the word order, you're gonna get that definition. But it's also context of where, because if in one of the things to make a design Was really innovative with was and you know it's probably central insight in in bringing this idea to us is some you know that no one System can be consistent across the whole system in terms of the mental models that you have, and so it breaks the system down into what they call bounded contacts and you say, in the context of Placing an order, this is what an order looks like. It looks like a list of items in their prices. But in the context of shipping order, this is what it looks like. It looks like the size of the package and the weight of the package and the destination. And so context is context where, in that if you're in the part of the code base dealing with Purchasing, it'll give you one definition. If you're from the part of the code base dealing with shipping, you know the definition and you're absolutely right, like Even though it was probably only working on these startups and learning about the manager of a design that inspired it. If I think right back to that original experience of the feedback that you know why do you misspelled the word license three times. That was probably the genesis of the journey that let me to think.

Tim Bourguignon:

19:07
Not sure what ever happened in this case, but you mentioned a couple startups. How do you, how do maybe, maybe start from from your first experiences? How did you enter the industry? Make the actual right now, and we'll get to start up later.

Chris Simon:

19:27
Okay, well, it was a very high. I spent a few years in industry, so we can get to start quickly, but I am so, yeah, having done electrical engineering degree and part of the scholarship that it and part of the reason I took the scholarship even though it wasn't in the fields of the degree that I thought I was gonna, you know, pursue was the opportunity to do industry placements, and so while I was at university, I had the chance to do A 10 week placement and then to six month placements at in in businesses, and one of them was a company that does industrial control systems, and they ended up being bought by Siemens.

Tim Bourguignon:

20:03
Sure, you've heard of Siemens being massive national company, I think 50,000 employees in the town I live in.

Chris Simon:

20:13
Something like that. So this is this tiny little Australian company of 200 300 people was bought by another German company called management and then Siemens bought the industrial logistics system from management management. So I may be an offer I had done six months work with them. While I was there I got to do a lot of Control systems program they call PLC's, which is that we could spend another hour just talking about PLC's because they call programmable logic controllers and this fascinating Intersection between hardware and software in that the industrial control systems, they want the flexibility of software but they want the reliability of hardware. And so this is this completely unique programming language called logic, which actually looks like a circuit. So you're like constructing a circuit in software. And the reason I call it logic is you got literally the positive power rail on one side and the negative power rail on the other side and across it you have all the Bullying conditions. But it's got more and more complex over time and now you can put like complex function blocks in there and you can create modules, become kind of a modular architecture approach. But it's running on these PLC's is programmable logic controllers that have not changed in decades, because when you invest in a warehouse and a conveyor belt system. You put a lot of money inside, you want to last a few years and it's quite interesting seeing you have these programmable logic controllers which have part of the reason they value as well as the real time control. So they're sending like real time signals to turn on conveyor belts or pop things up, to push boxes or parcels or or even like airports use these sorts of systems as well and you know so they need like really fine, like millisecond response for actuating the motors and things. And then often what happens is they've got Another layer of software running above. It could like a warehouse management system or location control system, which is typically written using traditional software and running on a PC. And it's fascinating how you know you go into these warehouses and these things are running on Windows 98 and because they can't migrate them and they're struggling to support them and maintain them, but the program logic control is just still tracking, just still, yeah, still there popping up boxes and turning on and off motors and doing what it's supposed to do. So yeah, it's kind of interesting seeing that that side of things. So I got into this field and because of my background software, they asked me to start working on Like a developer tool, something that would help make them more efficient in creating their the PLC code. So you know the guy was working for real genius, to be honest. He sort of come up with this idea of how to introduce modularity into before these things even supported modularity, but he needed some tooling around. It helps stitch the modules together, so it's effectively like a compiler and a linker, for you can drag modules on and connect them up and say this module represents this stretch of conveyor belt, this module represents the downstream stretch, and you can connect them up and Back and forth with this kind of relationship, ones upstream, ones downstream and he's like a sort of or divert, what they call it. Yes, I worked on this system for them and it was, I think, quite helpful, but you could tell it was like the first big program I've ever written, like it was. The performance was terrible and it started getting people would like Load a library into. It would take like five minutes to load the library and I had yeah, so it was. That was kind of my first experience of. I was really proud of it and I started getting this feedback like it's helpful, but Was it so slow? Interesting, anyway, that that kind of Ran its course, I guess. I mean, I used the software for quite a while until the underlying systems changed. But while I was there they gave me the opportunity to go and work in America for a couple years to a kind of project, and I had a great time there and a lot more about systems and systems engineering, systems thinking, and then eventually came back to Australia for personal reasons. But when I got back to Australia I kind of realized that this whole big corporate life wasn't really Sipping me like. I was kind of I missed the days of just being able to you know just what I wanted to do and to do it and you know it's been a lot of time in meetings and become like a systems engineer, which kind of meant you don't actually do any engineering, you just like and what is your design in the system? The system had been designed, it was just negotiate with vendors and technical project management, really, and In a very highly waterfall environment. So there's no scope for change in. Any change was a disaster and I just I just wasn't loving it. So A friend of mine from university he had ended up working at the same place and we were going out for lunch every day and he was really keen to sort of launch a startup and I had always thought, you know, be fun to get involved in a startup. But, to be honest, he was kind of Providing the main drive for it. To the point where one day he still remember this phone conversation because I was at the supermarket after work, I'm picking up some groceries, and I got this call from me said I've done it, I quit and go and start the startup. And I'm like, well, I can't really afford to do that right now. It's like, don't worry about it, I'm gonna. I'm gonna go and work out a few things and I'll let you know when we've got an idea and then you can decide if you want to join us, and so a few months later you said yeah, we've we've got what we're gonna do. what do you think and those few months have been enough for me to realize now I need to get out of this environment. It's not right for me. So luckily they I guess they sort of appreciated what I was doing. After let me take like a leave of absence without pay, sort of you know they said I'll just go, you know what's the word, sort of such this itch. And then when you realize that it's there's no future and it come back to us and that start up is where I worked for the next 18 years.

Tim Bourguignon:

26:01
so Wow 18 years yeah, that was a big age.

Chris Simon:

26:09
Yeah, yeah.

Tim Bourguignon:

26:12
When did the German company realize that you're not coming back?

Chris Simon:

26:18
Well, I think I did go back and do a little bit of contracting work for them because you know we're in a startup, we took us a while to get revenue and you know. So I did a little bit of part-time work for them just to keep the lights on. But they kind of knew when I said, look, I'll come back on a contract, but not permanently. I think they knew that the writing was on the wall. But you know they were happy for me that it was starting to work out.

Tim Bourguignon:

26:37
So it was good. So what did you do in the startup?

Chris Simon:

26:42
Yeah, so we. So the idea actually inspired by us going out to lunch and chatting about startups was to build a service that would allow employees to order their lunches so they could be delivered. And it was kind of motivated by so my friend's brother he worked in finance and he was aware of in Australia there was a particular piece of tax legislation that meant that if an employer provided food to their staff on site, then so there's a thing, the stroke of fringe benefits tax, which is that if a company gives you anything that's not money, you have to pay tax on it. To try and avoid companies saying, hey, let's cut your taxable salary and we'll just give you a car, and then you don't have to. You could buy a car and not pay tax on it. So they said, oh okay, well, we're going to, we're going to tax that stuff, we're going to call it a fringe benefit. So it's a fringe benefit of your job, you're going to get taxed on it. So it's no escaping the tax, man, like you have to pay tax. But there were these exemptions and cars, interesting enough, was one where they did have an exemption if you leased it as a whole thing and food food provided at the workplace, consumed on site at the workplace, was considered an exemption because it was obviously a necessity for people to be able to eat. And so there was this idea that, like we could build a system and integrate with the HR and payroll systems and integrate with local cafes and restaurants, and then they would deliver the food and we would integrate the HR to deduct it off their pre-tax salary. And the company would like this because it's like a benefit to their staff. They can offer them, like a, you know, effectively cheaper meals because they're not paying tax on the cost of their food, and the caterers like it because they get more customers and staff like it because they get access to hopefully healthy food. We have to queue up. This was in 2005. So this was like a decade before menu log or Uber Eats or anything. But we built a system and it was working really well. We managed to sign up a couple of really big companies in Australia as a user and then, of course, just as we were about to go live with like our next big one, the government changed the tax legislation and removed the benefit, and so we were kind of obviously a bit blindsided by this. We were still really small. I think we had about eight to 10 staff by then. We certainly didn't have anyone working as a government lobbyist. We didn't know what was happening. But fortunately we were able to pivot because, like about a few months before that, one of our customers had said really like using your site, they'd be great if I could order my children's food the same way. And we said, okay, let's explore that. And we had actually just launched into a school to do the same sort of service at schools and so when the tax laws changed, we just focused on the school's business, because you know that obviously didn't have the tax benefit. It was just about convenience. And this one is interesting because I think I kind of have to explain that it's a bit of a tradition in Australia about the way children in school get their food. Obviously a lot of parents would send in lunch with their kids, but if the food is provided at school, we never really had any of this kind of cafeteria style like you see on TV in America, people queuing up with a tray and they get slopped onto their plate. That never really took off in Australia, but they had what they would call a canteen or a tuck shop, which is where you would write on a. Parents would write on a paper bag what they wanted the child to eat. They would put some cash in the bag. The child would take the paper bag into school, put it in a plastic tray, the tuck shop or the canteen would pull out all the bags, work out what they had to make, make all of the food exactly to order, put it back in the paper bags, take the cash out, put the change in and then put it back in the plastic tubs, which would be sent back out to the classrooms. I have no idea how this started, to be honest, but this idea actually really well suited to becoming an online digital service and so we're able to take credit card payments from the parents. The schools could save a lot of time and energy working out what they had to make in the morning, because they'd spend an hour just tallying up the bags and then we would just print out a stream of labels that they could stick on bags, and they used to find they would not get paid enough because parents were going off last year's menu and the price had gone up, but they didn't know and they couldn't leave the kid go hungry. So you know they weren't always making money and a lot of these things. They weren't really commercial things. A lot of them were run by parent volunteers. They just, like parents, would say, oh yeah, we want to make sure kids have healthy food at school, so we'll, you know, someone would organize it and then parents would volunteer a day a week or a couple of days a term to go in and help make this food. So basically, we digitized this whole sort of Australian institution, which was fun, but not really globally. It wasn't right for global expansion, because I don't think there's any other country in the world that provides food to children in the same way. But in building this we were able to then become like, I guess, transactions, like a payments platform for the school and we started selling school uniforms and tickets to school fairs and events and things and just became like the place where you would buy stuff that was happening at school. And, yeah, it went really well. Like I think that latest count I can't remember there's close to 2000 Australian schools using it and millions of parents and kids have come through it. We've now got people that have had access to our service, their entire school in career and even people that have worked for us now, who had access to our service when they were at school. So it's been around for, yeah, it was there for a long time and it's still going really well. And, yeah, I'm still loosely involved with that business, so keep an eye on it. But yeah, it's a whole new team and they're on their own modernization journey trying to improve the rubbish code I wrote 18 years ago.

Tim Bourguignon:

32:17
Is there still some line of code that you wrote back in the code?

Chris Simon:

32:21
Yeah, yeah, there's quite a lot. What technology did you pick? Back then we went with NET, so it'sNET 1.1. And yeah, it's really back in the day. We probably like it was 1.1 as it was being released. It was the. I think we might even even the first prototype might have been 1.0. So, yeah, aspnet, classic web forms, asmx web services, classic WinForms, application for running in the canteen, for printing labels and things, so really old school. But you know, we got it going, it worked and it scaled eventually. We could spend a long time talking about the scaling journey. That was because, you know, I had no idea what I was doing. Like, you know, I knew how to write code and I'd written a couple of systems and stuff, so I was building this thing. I didn't know anything about user experience. So, you know, luckily we were able to engage some advisors to help with that and graphic design and stuff. But it was really the scaling issue was the biggest challenge for us because once it got popular, I think our first version was running on like a what we used to call a shared hosting environment. So you would, you know, sign up and you would get a database and you could upload your DLLs and then we'd just run in an environment, no visibility of how much CPU or RAM was there, or even if our restarting processes or whatever. So you know, sort of learn about that over time and eventually got big enough that we need more reliability. So we got like a, a virtual machine which you know even in 2007 or 2008,. You still had to put in an order form, like a fax and order form, to get virtual machine provisioned. And it took four weeks to get the virtual machine provisioned and then I got a login and could remotely connect to this thing. And then the other next couple of years we just get added, adding virtual machines. We changed providers a few times and then Amazon appeared and I was like, oh, we need that, because the thing about this business was all the parents were putting their orders in at seven or 30 in the morning, so it was like huge scale up in the morning and then nothing the rest of the day. And so we were by think, by the time we got to Amazon we had like eight really large, for the time, virtual machines which was costing us a bomb, and it was like they're not being utilized 90, 95% of the time. So it was like a poster child for AWS scaling groups, and so, as soon as Amazon arrived in Australia, we jumped straight into it and I ended up actually speaking at Amazon summit in Sydney in 2014,. I think about our migration journey and because it was just like you know, you look at the graph and it's like every in the morning it just spikes up massively and it's flat the rest of the day. And then we had this other interesting trend which was like Monday, tuesday, wednesday, thursday, thursday, wednesday we're at the same Thursday was a bit high and then Friday was double the rest of the week. So we just assumed it was because the parents had run out of food they hadn't, you know, like at home, because you didn't have to use this service every day. Some people use it once a year, some people use it once a week, some people use it every day and yeah, so we had this sort of all these hypotheses around why Friday is so big. But it's kind of like this. The other one was the through the week, if you will behave, you'll get a treat. On Friday, you get a lunch order treat. We just saw these like parenting styles playing out in our data, but yeah, so that was kind of the. That was that journey. And yet scaling was a really interesting part of it and, like, I think, connecting the dots with what you were talking about earlier about owning the full stack, that was, I think, a really formative period for me, because not only did you have to learn all about hosting and infrastructure and then cloud, when it came along, I think it was probably six years before we hired another developer, so it was only you for me and my friends and my friend had done electric engineering as well and he took on the CEO role and was mostly focused on business development and sales, but he did spend some of his time in the code. He actually wrote some of the software that actually ran out in the canteens for printing the labels and stuff, but I sort of primarily owned the back end and the website and everything and the scalability of it. But yeah, it was. It was, I think, 2011 before we hired our first person, and that was like a graduate straight out of the uni because it was all we would have thought. So, yeah, it was really interesting. But then you know, by that time the business has started to take off and, you know, over the next couple of years, we're able to grow the team, and that was that was a whole another sort of series of lessons to learn about how to manage people, how to help them understand the code I had written, help them be effective and productive in it. And you know, I think thematically this connects back to everything we're talking about. Like you write code for other people to understand, you write code to connect with your stakeholders, and so the stakeholder part was really easy for me because I was a co founder. I was out there doing sales, I was like doing cold calls, I was doing customer support, so I always felt really connected to our customers. But it took me a lot more, I think, to learn about how to write code, how does the architect systems, how to run a team so that the team can work effectively together, and honestly, I didn't get it right the first time.

Tim Bourguignon:

37:21
It was challenging, yeah, and is this what sparked the? The job that you're doing right now as a CCO coach, helping people?

Chris Simon:

37:30
Yeah, definitely, definitely. Because because that I mean, we sort of got to, I guess, the midpoint of that era, about 2015,. We had an opportunity to launch another product and it came off the back of the success of the first one. Some of our partners in banking had seen what we were doing. They said, oh there's this space that you might want to get into it. It's different but similar in that it's a transaction platform in a contained environment. For insurance and particularly in Australia, there was big changes around the way they were funding people with a disability to receive that services and supports that they needed. And people were sort of saying to us oh, it looks like the payments and ordering and transaction management in this space is going to need some support. So we launched a startup to work on that and this is a very different experience because I had the experience of the first one. This new one was pretty well funded. We were able to sort of recruit a team from the start, and so I paid a lot more attention from the beginning to making sure the code was like make sure the design and the code and everything was fit for purpose for a team to work on. We were straight into the cloud, because we already had that and then it became more of a challenge of scaling up then to like multiple teams and dealing with government agencies and compliance regimes and being a proper CTO, I suppose. So, yeah, I guess that is the journey both the first phase but also the second phase has really made me think I want to be the support that I would have really values through that journey and while it was a, I think someone a unique journey, because these days a lot of startups they just start, either they go straight out and get venture capital funding or something, so they hire a team straight away, or if they're bootstrapped and they've just got one person working there, they're kind of like I wasn't there, bit isolated. I think that's probably the thing I look back on and go. What do I wish I had done earlier? It's engage with the community. I was so just buried in my work and like head into what we were doing. I didn't really look up and look around at the world and the fact that there's a broad community of developers and software people that are supporting each other and sharing ideas and better ways of working, and it took me a long time to connect with that and I wish I'd done it sooner, because it would have been really helpful.

Tim Bourguignon:

39:39
I mean, do that? I discovered the community is pretty late as well. Five years in after my first job. It would have been so helpful at the beginning really to get this, this. How do you call that being being? I have a word in German when you're exposed, when you're exposed to a lot of things that you don't expect and I don't know you don't know that yet and you don't know that you're going to need that, but you get an early exposure to stuff and then it starts making its way into your mind and that's what the community is. The first thing I realized why I needed community was that, and then the connections and really having people around, like-minded people or sometimes different-minded people, to just put it what you say. It would have been good earlier.

Chris Simon:

40:38
Yeah 100%.

Tim Bourguignon:

40:42
I would like to come back to one thing. That that's the piece where I usually ask for advice. And I want to come back to one thing the moment when you decided you said you're your friend. Back then, say, hey, I quit my job, I know I'm going at it, it's, it's good, and it said well, it took a couple months for you to figure out okay, I need to move on in my life. How did you discovered, how did you realize this was the time you need to make it, even if a big jump in your life? What was the thinking?

Chris Simon:

41:13
process there. Yeah, it's a tough one to answer, partly because it's a long time ago. Look, I mean, I think I sort of I'm going to answer this question actually with relation to two points in my career, because one was that decision to join the startup and then the other was another really tough decision, which was the decision to leave the startup. Because, you know, I've been there for such a long time and I was like an institution and I felt really connected to it. But I realized I needed to do something more. And I think, actually, as I reflect on it, the journey I went through in the decision making was kind of similar in both cases. And you know, and in both cases it was hard for me to recognize, like, what I needed as opposed to what the business needed from me. I sort of always felt this strong saying I need to be loyal or I need to. You know other people need me. You know there's always this sense of like I have to do what other people need from me and it's been really hard in my life to sort of prioritize, actually, you know, what's important for me or what I need. And in both cases I think we're times where I sort of realized, or let myself realize. Actually this is something I really want to do, this is, you know, something that's going to be important for me and I'm allowed to do it. So yeah, it was. It was interesting. I think in the first one it was more obvious because I was so unhappy in that environment, like I loved the people, the people were great, I love my colleagues, but it was the work was not rewarding. There was too longer gap for me between idea and outcome, and then there was so little autonomy, so little sort of self direction, that I just felt really stifled. And so the startup obviously was completely the opposite. There's always too much autonomy like complete lack of direction and guidance. But the second decision was a bit different, because I love the environment, I love people as well. I had a lot of autonomy and freedom, but what I was missing was that connection with community that we were just talking about, and I had started to become connected a little bit. I did some talks and some meetups and got to know a few people in the industry, but I realized that I'd only seen the one company you know for most of my career and I wanted to see how other companies were working, how they were doing, how they were tackling the problems we were tackling, and I thought I don't really want to just go and get a job Like I've been working for I wasn't really working for myself, I think, even though I was a co-founder. Eventually we got investors and once you have investors, even when you're a co-founder, you don't work for yourself, you work for your investors. This is the reality of it and you know so. I worked for my co-founders they worked for me, I suppose, but we worked for each other, but we worked for the investors. You didn't really feel like you were on your own for a long time and I didn't want to go just and just get a job at that time. I think now, actually having done this consulting work for a couple of years, I kind of find myself pondering you know, maybe, maybe I should do that, like maybe that would be an interesting. It's like I haven't done a pie in a ton of people I don't think I've actually had an interview in almost my since that first job I took because straight out of university I went into an interview to get that job. They already knew me because I'd done the placement through the scholarship and then we just launched the startup. So I suppose you could say getting to know my friend and his brother was kind of a quasi interview, and now that I'm a consultant, I suppose every time I'm selling my services is kind of an interview. But it doesn't feel like that. You know, when you go through the interview process for a job like that's not Anyway. So I'm getting a bit distracted. But what I was thinking about is like so I took that company from you know, the very early days as a CTO through to you know 100 to I think it was like 120 and 30 people at the point I was leaving and I realized, like I've never gone past, that there's a lot of problems and challenges facing businesses that are much bigger than that. And you know, I think I can have a glimpse or a sense of what it would have been like to scale beyond that point and a lot of things that I learned through that journey I think are still relevant. I've never actually taken a business through that. I think it'll be an interesting challenge to rejoin a company that's already at that point and take them on the next phase of growth. So it's something I can see myself doing in a couple of years. But right now I'm enjoying too much, you know just engaging with lots of different clients, coaching people, doing open source work, speaking in conferences. It's just too much fun. So it'll be a while before I do that.

Tim Bourguignon:

45:18
Then surf that wave as long as you can until you feel that you need to do something else.

Chris Simon:

45:24
And exactly.

Tim Bourguignon:

45:26
Chris, fantastic. Thank you so much for sharing your story with us. My pleasure. Thanks for having me. Where could people find you online and start a discussion with you or continue this discussion with you?

Chris Simon:

45:36
Yeah, so my website is chrisseimanau and I'm actually in the process of revamping that, so hopefully soon it'll look a lot nicer. It's got links to all the socials and things I'm on mastodon and LinkedIn. I still have a Twitter presence but I'm gradually winding that down and yeah, so that's places I'm. I do try and get over to Europe once or twice a year to speak at conferences and connect with the community over here. I'm really connecting strongly with the demand driven design community here through things like D2E Europe and Kandinsky, and I'm actually over here in Portugal at the moment speaking at NDC. I think by the time this goes live I'll be back in Australia. So yeah, if you're in Europe, check me out on the socials, and I think I'll be back in Europe next May May 24, to try and speak at a few conferences. So yeah, hopefully we can connect in person then, otherwise online you have heard that, chris, thank you so much Thank you.

Tim Bourguignon:

46:32
And this has been another episode of their post journey. I will see each other next week. Bye, bye. Thanks a lot for tuning in. I hope you have enjoyed this week's episode. If you like the show, please share, rate and review. It helps more listeners discover those stories. You can find the links to all the platforms the show appears on on our website devjourneyinfo. Subscribe. Talk to you soon.