#75 David Hirschfeld had a long, eventful career (sofar)
Transcript
⚠ The following transcript was automatically generated.
❤ Help us out, Submit
a pull-request to correct potential mistakes
Tim Bourguignon 0:00
How is it to sell your company after so long?
David Hirschfeld 0:02
It was awesome for three months.
Because unfortunately, I made a critical mistake.
Tim Bourguignon 0:17
Hello and welcome to developer's journey. The podcast shining a light on developers lives from all over the world. My name is Tim Bourguignon, and today I received David Hirschfeld, David software career spans over 30 years, from business development and technology consulting, to creating his own companies, which are v S. S, and more recently techies Inc. softgrid. Design and development firm, I'm sure we're going to talk about tickets at some point. David is also the CTO and managing board member of NZ, originally a techies customer, and I would pretty much like I would like to know how that came to be. But first and foremost, David, welcome, Steph Curry.
David Hirschfeld 1:00
Thanks for that great introduction, Tim.
Tim Bourguignon 1:03
So let's let's go back to the beginning First, if I counted right, you were in the it already in the ACS or the end of the 80s. You weren't telling us how that works to start your career at that point in time?
David Hirschfeld 1:16
Oh, sure. Well, and I kind of went at it in a very indirect way, because I studied physics at UCLA as my major, but then instead of going into sciences, when I was out of college, I ended up going into sales and it sales to start with. And, and I and I found it very frustrating. Now, that was a whole different world back then. This was all made for IBM mainframe software related sales, since when Oracle got it at the very beginning of Oracle, db two as a data, IBM database was the big 800 pound gorilla on the block. And what I found very frustrating was to do it sales, you always had to have a sales engineer available to come in and, and do the technical presentations and had to schedule those ahead of time. And I wanted to build consensus, and be able to, you know, just show people what I'm talking about and talk about it technically. So I started going to all of the education classes for the systems engineers and learning the development stack. Back then it was COBOL and JCL. And very cryptic in compared to today's world. And then I saw that I could talk intelligently with potential customers so that I was on more of a similar level, because I don't like being on that sales level. I like being on the consultant level, somebody that they feel they can confide in and talk to with their issues. And then I can help them try to figure out the best way to address them. As a result of that, I ended up going to work for Texas Instruments and had the same issue. So I went to the and back then at Texas Instruments, they had a product called IETF. And it was an enterprise development platform, very big, very expensive. And it used models, data models, process models, you so you build everything in this modeling environment, and then it would generate the code. And so I went to school to learn to take centum at school to learn how to develop on that platform, and ended up building all my own prototypes. And these were four really big systems like welfare state welfare systems and things like that. And then I when I left ti, I ended up becoming a consultant and doing contract development using AI F for and that's actually how I got my start in development was for developing was basically self taught. Wow, that's a really through
Tim Bourguignon 4:02
the backdoor isn't
David Hirschfeld 4:02
very backdoor. Yeah, very. But I had a strong inclination toward science and technology. And I loved the way it felt to assemble things using code and using models. And so I learned and the cool thing about learning the way I did was I learned the methodology and philosophy first of how you how you create a data model. It's what third normal form is and why it matters. How and when you denormalize a database, how to build a process model and process flows, understanding the whole workflow piece and how software controls that workflow and state state engines and so I learned it from the real conceptual perspective first instead of from the real low level technology perspective of understanding how coating land budgets are built that all came later instead of first. So it's kind of a backwards education, I think. But it's served me incredibly well.
Tim Bourguignon 5:09
Was it something you wanted to do learn this on the on the theory and on the modeling side, etc, before going to the application side? Or did you just happen to be the way you you you stumbled upon.
David Hirschfeld 5:24
So when it started out with computer associates when I was selling IBM mainframe software, and I needed to understand some technical level of the coding environment, and the way jobs are, you know, JCL job control language and how jobs are submitted and controlled and how the transaction processors worked. And, but, but you needed to understand at a high enough level, because you have, when you're talking with somebody about a product that you want to sell them, you need to be able to talk about it from a standpoint of needs and benefits before you get in, because until you've set shown them that there's something here that can help make their job better. You know, if it'll run faster, it'll be less work, it's less risk, whatever the thing is, that meant that it matters to them until you get that point, they're not interested in the technology itself. So you have to start at the high level, and understand how to present that to a client. And then then when I went to Texas Instruments, that because all the development was done with models, instead of with code, you had to learn all this, it was all driven from this higher level philosophy. I learned coding later, I learned how to how to write C and then for dotnet, and JavaScript, and I learned all that after that later. I mean, I learned a little bit of it during that time. But I really developed strengths in those areas after I understood the conceptual things. And where where really helped me I think, was that I, I was a lazy perfectionist when I was actually writing code. And what I mean by that is, anytime I saw something that was potentially repetitive or going to be difficult to maintain, I always looked for a more abstracted way of constructing the system. From a object oriented class component. perspective, micro service perspective, I always gravitated towards the higher level more more deliverable independent component type of development with the idea that I want to be able to reuse things, I want to write a lot less code, I want the code to be easy to test and maintain and extend. And when I found it difficult to do that, I would always step back and look at it from a higher level because I was kind of trained to do that from the very beginning. I'd also would always look at systems from the data model perspective, before I end the workflow perspective before I ever started building anything. Because it would save me a lot of headaches downstream. After I built something where it, I built myself, I developed myself into a corner, because I hadn't thought broad enough and high level enough in the beginning to make sure that I was approaching it properly. With and I've seen it and I've taken over because I a software development firm. Now I've taken over many projects that I call recovery projects, where somebody started out building something without really understanding what the long term goals and objectives were. And so now they've got a mess. And it's slow to enhance and it's fragile, and we got to go back and refactor the thing to make it much more scalable, maintainable extensible.
Tim Bourguignon 9:07
We'll we'll have to come back to a few of your questions. I want to keep keeping this this flow going right now. How do you deal with with newcomers now industry which are now way, way more practical, I would say on the drier side of things, really trying to get something out the door very fast and not necessarily thinking in terms of systems. How do you deal with with this newcomer energy with with this background of yours,
David Hirschfeld 9:37
newcomers that get my attention are newcomers who are curious and are aren't looking for just a comfortable, stable daily development but are people who are exploring and learning and pushing the envelope in terms of of what's possible technically. And that that's what drives them and feeds them. So I bought hiring practice, and I don't directly hire, I haven't for a while. But it's a hard this is a difficult practice to, to infuse into my team. But once they get it, they live by it, they love it. And that is don't hire somebody unless they're smarter than I am. So when I'm interviewing somebody, or when my team is interviewing somebody, if that person doesn't come across as smarter than them, at least in the, in the thing that they're trying to hire them for. If they're, let's say, let's say it's a QA position, for example,
then that person
is really not even necessarily extremely skilled, but really smart and creative about how they think about QA. Where it's clear that they're expressing a high IQ, in terms of how they approach QA and how they can extend QA beyond what we currently do the same thing with a developer or with an architect, you know, I want these people to all be smarter than me, because they're smarter than I am, then my job is, as a company owner is to get the impediments out of their way, my job isn't to drive them, then my job is to keep up with them. So that's an and that's a not a lot of companies run like that. But I find, then everything we do, is as good or better than I might expect it to be. If we if I, if the people that are working for me or with me, are adding more value than I could add by myself in the specialty or the area that they're wanting to do. So the so somebody starting out today, the most important thing I could say is learn everything and and read everything going on and all the new trends and play with them on the site and try them and experiment to see some of the benefits you get without don't necessarily try to drive all the new things into your company, because some of them may not be proven and create risks that are that are not yet
Tim Bourguignon 12:35
easy to understand. But it but be hungry for them and understand them. Because then you start to see new way new patterns, in the old patterns, new ways of approaching existing problems that you don't see if you just keep doing it the same way forever. I like the the sentence you say though, seeing new patterns in the old patterns. I found I've attended a talk recently called wisdom of the insurance from from a German speaker here. And he took many papers from the from the 60s in the 70s. So the white papers from Dijkstra and CO and started swapping out words and swapping the word. I don't know what it was module or component with a word service or micro service. And showing us that the paper is still hold was just a different granularity and then what they had before. But it's exactly the same, the same concept right now that we have with micro services or whichever level of tinius we reach now. And that I find that really, really interesting to see that we are not inventing anything new. It's the same recipes again, right?
David Hirschfeld 13:44
Yeah, it just packaged differently. Right,
Tim Bourguignon 13:46
exactly, exactly. I would like to to go back to one when you started learning or getting into this, this, it as a creation system in order to better understand what what your customers were living through in order to sell it. But when did you flip the coin and start developing for the sake of developing and not not selling anymore?
David Hirschfeld 14:11
Well, at Texas Instruments, I started to actually build prototypes using their tool. And then when I left ti and I started doing contract development for Intel, Motorola, Arizona public service, Allied signal, you know, all large companies, because only large companies were the target of this develop model based development platform. And I am because I was skilled in it. And I also was skilled in the beta version of it, which nobody else in Arizona was at the time. So I was a hot commodity in that area. That's what got me into actually building systems. And then from there, a friend of mine from Texas Instruments and I decided we wanted to start a software company. We This was in the early 90s, we built an application for vending operators using Visual Basic back then. And it started out as Visual Basic and expanded to see in c++ and other other things. And it was SQL Server based it was client server. And tier kind of client server architecture. This was really early in when windows three Oh, just came out. And three one was just about to come out. And so we built an application for vending operators, route drivers inventory management, and put it on the market, it was the first Windows based application for that, for that industry. And that happened because a brother in LA went into the vending industry. And so I thought, you know, this is a an area where we could create software, kind of like our first software company, it could be something small just to put something out there to say that we've done it, then ended up growing into a, a company that we sold to a publicly traded company in Canada, nine years later, it was a we ended up with 800 customers in 22 countries that we had, we'd go to these big trade shows, and these are huge trade shows when you're in that industry, because you have Coke and Pepsi and Hershey's, and all the big prop and chip manufacturers and candy manufacturers. So you can imagine, right? These are big glitzy trade shows. And accidentally, despite everything we tried to do otherwise, it grew into a company with a bunch of employees and, and, you know, customer service and a big user base, you know, because for a vertical industry like that, you know, 800 customers, it was a pretty big user base. So that's when that's when my development career became really formalized.
Tim Bourguignon 17:17
And how did your past as a as a sales man or sales engineer helped you in this phase of your life?
David Hirschfeld 17:25
That's a good question.
It helped, because I could, even though I built the product with my partner, I could explain to somebody its value in business terms, instead of talking, getting lost in the technology itself, which is what happens with most people that don't know how to step back and connect with the person who needs the product that you have, because they don't need it. Because it's a cool technology, they need it because it satisfies a business issue, a business concern that they have, or a business problem. And they need somebody that can listen to them and understand their problems there, and what's unique about it to them, and then be able to reflect on, reflect back to them. What it is that we do that helps them solve that problem or makes their life easier, you know, managing inventory, managing route schedules, predicting, predicting service requirements based on sales, velocity, and vending machines, and all that kind of stuff. Otherwise, you get lost. If you just focus on what you build, then you start talking about how it you know, from a technology perspective, how it stores the information and does the predictions and nobody cares about that? If the because what they want is that it's going to make sure they have the right product at the right machine on the right day. Yeah, that's what they care about, without having to worry anymore about how they're going to manage that. So that's how sales being and sales helped me and still helps me
Tim Bourguignon 19:10
i would i would say with a photo that's, that's, that's what I thought as well. was the idea of creating your own company always in your mind.
David Hirschfeld 19:20
Yes, I didn't start out in this industry in the late 80s thinking I was going to start my own company. But it was after a few years, I started thinking that I should because I was watching other people create companies, some having quite a bit of success, some of them massive success and some smaller success, but it seemed like a very satisfying thing to be able to create. I liked the creation process, creating the product. It's what really got me into coding because the idea of creating an application that somebody was going to use is really satisfying. So taking that to the next level, creating the entire product, you know, innovating a product, that is as an A value in a market that somebody will buy it over other things that might have been out there is really, really satisfying. It's, of course, scary and risky. And it's all those things too. But but the, but it was satisfying. And I and I was doing contract development and doing development on my own software at night, when we started until it took off, and then we could form a, you know, a separate company and run it independently. We did that for a couple years, and then went full time, both of us with that company for the next seven years until we sold it. How was it to sell
Tim Bourguignon 20:45
your company after so long?
David Hirschfeld 20:49
Oh, that's a that's a great question. For reasons you wouldn't, you wouldn't expect it was, it was awesome for three months. Because we, because unfortunately, I made a critical mistake. And actually, I had people coaching me not to do it differently. But I was, you know, it was too smart for my own good back then. I should have been listening to people with more experience that had sold companies. I sold my company for 95% options in the company in this logistics for Canadian run logistics firm that was publicly traded and doing very well. And they were their stock was at two and a half billion in value at the time, which this is in the year 2000. During that right at the end of the stock. Right, exactly. I see what's coming. So we had a strike price. Yeah, exactly. So we had a strike price, and the stock was worth three times that strike price for three months. But we also a part of our agreement was we couldn't, you know, we had to keep this stock liquid in the company for three years. And before we could start to sell it, of course, the the market crashed, the stock went down from 92. Three, a strike price was around 25 or 26. It never recovered, lost all of last DePaul. So there was a short period of time where tall buildings had a kind of an interesting attraction. I got over that. But I got over that. Yeah, yeah, that was we had no, we had, it was worth over $10 million, my own personal stock was worth over $10 million for for three months, and became worth the stock itself was zero. And all the only thing I got to keep was the chipset, which was the cap value that we got to keep, which was, you know, a fraction, a very tiny fraction of what the stock was what we thought we had sold the company for anyway. So then you start over, right?
Tim Bourguignon 22:57
That's a pretty, pretty humbling story.
David Hirschfeld 22:59
Yeah, I was in good company back then. That's the only I just kept telling myself that I'm not an idiot. Look at all the other people that just went through the same thing. I went through it, you know, because, you know, half the tech world went through something similar. I mean, they didn't make a dumb decision about how they sold it, but their companies that were publicly traded, or were these darlings with all this VC money, all of a sudden disappeared, you know, went out of business overnight, like, you know, thousands of companies. So that's why I was in good company. And we did sell it, the company and that software company took our software, and I was employed with them for the next two years as VP of products before I left and you know, started looking for my next thing to do. But that was a very painful thing. So there you go. That's how it feels. It felt great for a little while, and then it felt horrible. For a lot longer. And then, you know, and now it now that's just a story.
Tim Bourguignon 24:00
But a great one.
David Hirschfeld 24:01
Yeah, well, it's a it's a significant one, a great one. I rather, I'd rather it be a little bit different story that I'm telling,
David Hirschfeld 24:11
I believe,
Tim Bourguignon 24:13
decided to move on after two years.
David Hirschfeld 24:16
What I could see that I was basically sort of stuck in a malaise. It was going if this was going to turn into something of any significant value was going to take a long, long time. I didn't really want to be working in that industry. I never thought when we started this company, that I was even going to be doing this for any I thought we would put out one or two releases. This is you know, out of ignorance. And then we would start to sell the product and get made and so we'd have an annuity, make a little bit of money and then we go off and build a real product. That's what I saw. But it ended up growing despite itself into a significant company and then but it wasn't And I didn't pick bending because I thought that was a great long term business that I just, I really wanted to be involved with, I wanted to be involved with something more technology interesting or oriented or, or vertically, something with a much larger opportunity. It just, it just ended up growing and kind of taking on a life of its own. And so you know, you follow those things when that happens. So then after I sold it, and then value of that sale turned out to be worthless for the most part, then I stayed on for a couple years and then decided to leave and start something and try to figure out what was the next thing I was going to start and then stumbled around a bit after that,
Tim Bourguignon 25:43
would you mind taking us through this process of finding out where your next move is going to be always going to be
David Hirschfeld 25:49
after that, I decided I wanted to build a new product. And so I learned dotnet.
And I wanted to build
I wanted to build the price pricing engines, if you remember, you may remember you may not meet a lot of your audience may never have experienced this. But there used to be these things called price engines. pricewatch. Next tag, these were sites where before Amazon and before Google had such great search, where you could go and and search for let's say you wanted to buy a new monitor. And any place that was selling a monitor, like Best Buy, or Walmart or whoever was selling a monitor would have you know, you put in the model and it would list every single place that's selling that same monitor and what their current sales price is for that monitor. And then you so you might see 15 different places selling the same exact item. And you could see where you could buy it for the least expensive and you click on the link and it would take you to that person site and that whoever that person site would would pay for that click. So that was the first real Pay Per Click model.
And so I
wanted to create a way of being able to manage those listings. So I wrote I spent about a year on my own learning dotnet. And then developing a price engine management system, which was actually quite cool, pretty sophisticated where it would go, let's say you have 50 products that you're selling, or that if you're a retailer, or a wholesaler even, and you have 50 products that you want to sell, and you have them listed on five price engines, that's 250 listings that you have to manage. And the and you don't want to be the fourth, third or fourth or fifth lowest price, because people will click on you, but they probably won't buy you. And so you'll rack up a lot of clicks, costs, but you won't get a lot of sales. And those prices are competitive, and they change almost daily. So so my app went out and crawled these sites back when you still could crawl sites to check the prices on all your products, it would then and then it would list in a in a kind of a smart, spreadsheet organiz organized view. It would list what the current price is, what the what my sales, current sales prices, what my margin is how much my margin would be if I dropped my price to be at the top and also what position I'm in for that for every product, and then it would automatically go and update them based on parameters I set might update that product, it might take it off, if I can't make enough margin on a particular site, it may lower the price to put me in the top one or two positions if my margins still good. And if I had slid to position three or four, then it would do this, I'd run it every day. And so in about 10 minutes, you could have 50 products for sale and in 10 minutes, every single product price could be refreshed so that your investment competitive position to sell them. So and I had that worked, it worked really well. So I had planned on licensing that. But then I thought well, why not just get into the product business and that was my second big mistake. And that's the end of that's the because I that product would have I could have licensed that it would have licensed to all the big retailers and they would there was nothing like even remotely like it on the market at the time. Anyway, so instead of doing that, I started basically buying a reselling components that through that, and that turned into a decent business but then it became very difficult, especially because I focused on network components. The the weirdest thing it was became very difficult to manage counterfeit, because this is when China started creating all this counterfeit product, Cisco routers and, and all these counterfeit product and flooding the market with it. And so I ended up I ended up having to get out of that business because I could not control that the only way you could control the counterfeit was to buy brand new directly from the manufacturer. And then there's no way you could compete in price, unless you were gigantic in size. So I ended up getting out of that business. And then of course, Amazon came along price engine started to drop. And then there was no point in trying to sell the note trying to license the software. But you know, about a year and a half later, it started to shift. And this is you know, when you're an entrepreneur, this is your journey. You don't know what you don't know until after you've done it. And you look back and go, Oh, now I know. That's what I should have done, or this is what I should have. Sometimes you make the right decision, the right decisions to write I mean, not all my decisions have been the wrong ones. You know, building Ben Master, we did a pretty good job of that. My current company, I've done a pretty good job with that. But it's there, you just have to be ready to know that no matter what you do, it's going to take many different failures before you hit a success. And you've got to be willing to pivot quickly, when you realize what you're going down the wrong
Tim Bourguignon 31:32
road take us to take is your current company, what's what's the story behind it.
David Hirschfeld 31:37
So after the price engine and a couple other ideas that I I went after I decided to do contract development for at the time it was web two, oh, which was really, really new. This is 13 years ago, when I started. And and then eventually, you know, not too long after that. And mobile apps became a big part of it. And now it's evolved way beyond all that. I mean, it's still mobile and web is the majority of startup businesses in terms of the products that they're developing. But there are lots of other requirements now, because technology has just moved along so fast. And at the time, we were using dotnet, and PHP. And when the MEAN stack came along, we started using node and angular and React Native and, and also native mobile. We initially were doing all native mobile, and then started to move into progressive mobile apps, as well, in that, but I've always kind of kept my eye on the whole model driven development process. And in the last few years, this concept of low code, no code development has started to really emerging in. And it's another word for Model Driven Development, which is what I did in 90. Problem with IMF is they were building a code generator for COBOL, it was this gigantic, monolithic thing, and then windows came along. And now they were more thing that's to be able to generate Windows applications. And, and they couldn't generate a Mac application. And there, but and they couldn't keep up with all of the cool user experiences that were coming out in Windows, there was just no way because it was this big monolithic thing. And so I mean, it was they had that product. Still, in fact, there's still big companies, some big companies and state government applications that are written with that system that are where you can go get contracts to do development on it. Because they invested, you know, 10s of millions of dollars in the platform. But and it and there was a lot of value in it, too. It just was it couldn't keep up with the shifts all the shifts and technology. Well, now the world is all microservices in IoT and machine learning and, and cloud, you know, cloud computing. And so the Model Driven platforms that have been coming along in the last couple of years, are more focused on my kind of a microservices approach. And now we're in the developing our first application. It's it's a, it's one that I won't share the name with you yet because we're working out a deal to bring it exclusively into the US. It's not in the US yet. But I've been watching this develop because I know the architect of it for the last seven years since he started putting this together. And it's a whole team of people and they do contract most of their contracts. Work is in Japan. But they've built some massive high volume systems. The thing that's so cool about it is you build something with this environment you end up with and you you don't have to decide how you're going to deploy it. Before you build it, you can decide that after you've built it, because it's more of an assembly process, you can decide that you want to deploy it as, as one big monolithic application up on a server, you can decide you want to deploy it as micro service have lots of micro services distributed throughout a cloud architecture, you could have it as a distributed system, that's part IoT part micro, because IoT is nothing more than just sort of a micro service. Right? There's micro services packaged together for IoT devices. And their platform started out as an IoT development framework. And then they realized, all they're doing is creating micro services that are targeting IoT devices. And so they expanded it a few years ago, so that it would really focus on the whole DevOps deployment model as well. But I can build it and then I can decide later how to how to distribute and partition and expose API's. so that it can act as a totally open or secured microservices framework for operations. So I can build something, and all of the scalability,
all of the scalability, all of the security, all of the structural components just get inherited along with it, I don't have to worry about any of it. And I can, as a result, I can use people, I still need developers, because we're because it's very extensible. And we can build an architect new extensions to it. So I need developers to do that, if I want. Now, I want really smart developers who are instead of just building something to deploy an application, they're building the components upon which will keep building bigger and more cool stuff. But now I can also use analysts for assembling my applications doesn't have to be a developer. And the analysts are naturally better at talking with clients about their business needs, so that I end up having a better match between what I'm building and what the client needs without having to put the layers in between to make sure that translation happens properly. So and So to me, this is great. It's, it's sort of a plus and a minus for developers on the one hand, does that mean there's going to be the need for fewer developers? I don't think so. Because, on the other hand, developers will be doing a lot more cool stuff, instead of just building more of the same thing bigger and faster. They're building, they'll be building all these architectural components and extensions, and focusing on the cooler part of what software developments all about, you know, for automating more of the DevOps cycle, machine, you know, implementing machine learning and more intelligent ways, things like that. So I, if I were, you still need as a developer, you've got to have all the basics in terms of understanding how to write code, you know, and do it smart. Like I say, lazy perfection, perfectionist, that's the perfect coder is the lazy perfectionist. They want it to work, they want it to be right, they want it to feel good and look good and act perfectly. And then they want to make sure that it, they thought through every possible way that you can make it, you know, fail. And they've thought through that and developed for it. But they want to do it in the laziest, most reusable way possible. So that they never have to rewrite that same thing twice. So that it's all abstracted. That's the that's the ideal developer.
Tim Bourguignon 39:10
In my mind, I'm really, really looking forward to towards developing in the space, having less of puzzle developers, and more of your real core developers building the the building blocks of what we do and not putting things together and building one more version of a logging framework for whichever framework we're using.
David Hirschfeld 39:34
Exactly. Is that mean? Cuz that's the fun work, right? It's building the componentry. Yeah, building. The same thing, again, is not so much fun.
Tim Bourguignon 39:43
It is once or twice, but that's it. Yeah,
David Hirschfeld 39:47
right. Right. Exactly. And then it's, then it's becoming, you know, like, I remember the cobalt developers of the 80s and 90s. They'd be working in and around. Big companies. And they would be doing the same thing day in day out. I mean, there, you have to think, you know, and you have to know how to architect and plan what you're developing. But it's the same thing day in and day out. And so the type of person who was really good at that was somebody who was steady. And who was smart and quick, but not somebody, not the lazy perfectionist, they hated it. That type of developer just could not survive in that world. And they still do. Oh, yeah, right. And they still don't, right. And but that's the kind of developer that I when I find that person, I will like, fall on a sword to protect them, and to make sure that they stay excited and interested in what they're doing. Because my whole future depends on them being, you know, wanting to continue to be perfect and lazy.
Tim Bourguignon 40:52
The Timex is unfortunately, pretty close when and I would like there's one one last question. If you could travel back to the 80s and meet your your younger self. Would you give yourself an advice? And if so, which one?
David Hirschfeld 41:09
Oh, yeah, I would say don't suffer.
That would be I would absolutely say don't sell for options. That, you know, I know, that's not the question. You're really asking. But it's very hard for me to go back to the 80s. Meet my younger self, and not make sure I had a very long conversation about that particular topic, then we'll
Tim Bourguignon 41:33
leave it to that. Sounds. It sounds good. Baby. Thank you very much. The listeners wanted to continue the discussion with you. Where would the appropriate place be?
David Hirschfeld 41:48
Okay, so my website is techies calm and techies is spelled t isn't Tom isn't Edward Kazan kite. y as in yellow, z as in zebra.com. Just a play on words and, and you can reach me at David at techies calm or feel free to call my cell phone. I love it when somebody who's listened to an interview of mine gives me a call that my cell phone is 480-570-8557. And I really do hope to hear from some of your listeners because it's really kind of a joy when people call
Tim Bourguignon 42:34
and listeners you heard it. Please do. Do you have something coming up in the next month? Something you will have to to plug in on the show?
David Hirschfeld 42:41
Not in the next month? I I did a keynote speech for a bunch of for, for healthcare, because remember, you asked me the question about my other company that I that was a client then became a company with that I'm the CTO and founder up for them. I ended up doing a keynote speech to a couple months ago to 150 directors of public health from around the country. Which was way fun. And you can go to my if you want to see that speech, you can go to my YouTube page to see that as well. It talks about the unintended consequences of disruptive technology. And it there was some there's some really cool stuff. Yeah, because usually the big disruptions that happen when something goes viral or something becomes super successful. They're never intended the consequences are unintended. They're never something that the the developers of the the founders of the product actually planned it just happened by accident. So that's what the presentation was about. Anyway, but no, I don't have anything coming up in the next couple months other than traveling on vacation to Europe to Budapest actually at the end of the year.
Tim Bourguignon 43:57
So um, thank you very much for sharing your story. That was a blast and very interesting in in Indiana and I hope the listeners do take it up on your call and and call yourself and, and tell you all the great things to learn to ask Lisa, this interview. Thank you very much.
David Hirschfeld 44:14
Yeah, thank you, Tim. It was fun.
Tim Bourguignon 44:16
And this has been another episode of developer's journey. We'll see each other next week. Bye.
Dear listener, if you haven't subscribed yet, you can find this podcast in iTunes, Google music, Stitcher, Spotify, and much more. Head over to WWE WWF journey dot info. To read the show notes. find all the links mentioned during the episode. And of course links to the podcast on all these platforms. Don't miss the next developer's journey story by subscribing to the podcast with the app of your choice right now. And if you like what we do, please rate the podcast, write a comment on those platforms, and promote the podcast and social media. This really helps fellow developers discover the podcast and do fantastic journeys. Thank you.