All right. Well, we are kicking off the second live stream. I'm very, very excited about
today's guest. Neil Toveson, welcome to the live stream. How are you this fine morning?
Fantastic. Fantastic. It's a beautiful sunny warm day in Minneapolis.
I'm going to laugh about that a little bit. And for anyone who is listening, we are chuckling
a little because I used to live in Minnesota and he said it's a beautiful warm 28 degrees
Fahrenheit there. Meanwhile, I'm over here in Texas like it's going to be 78 today.
I'm going to work outside this afternoon. Oh, how the weather is different.
Yep. Yeah. A little bit different perspective on that one.
Yeah. Absolutely. Well, I am so excited to have you today. Why don't you tell us a little
bit about yourself? Obviously from Minnesota, we'll get into kind of like what you do and
how you build, but you know, just generally sort of like what you've been up to and who
are you? Sure. Sure. So I started my career years ago in large enterprise, you know, companies
like GE and Siemens and Pricewaterhouse Cooper and stuff like that. And I kind of got this
sort of itch to do my own thing. And so I've founded two startups and then got to a point
where I couldn't really sustain that after six years and wanted to start a family. So
I kind of like out of necessity and before the word fractional, like it was hard to explain
what I did, but I kind of stumbled into this sort of fractional CTO sort of thing. And
I've been doing that. I did that full time for about five years and getting back into
it now after a little sabbatical. And yeah, so I love working with startups. I love working
with non-technical founders. I love coaching technical founders that maybe are new to the
startup world or maybe you're a, you know, my first client was actually a technical co-founder,
but they were fresh out of school. And so they had a brilliant idea. They managed to
raise money very quickly, had a big first customer right away and said, oh gosh, now
what do we do? You know, and so, you know, it was kind of more of a coaching player coach
sort of scenario there. But yeah, generally speaking, people who can't find can't afford
or don't need a full time technical co-founder. Oh my gosh, I love that so much. We nerded
out on this a little bit before we actually started the live stream. But you know, I
think that's something that's really needed right now. And honestly, there's a lot of
fractional types of roles and not to go out and tangent too much, but I started doing
fractional DevRel earlier in the year as I was starting to build my business. I thought
maybe that was the thing I wanted to chase down. Turns out I don't by any means, but
I had to explain what fractional meant. And I thought that was kind of interesting. So
I do agree that there's it's not as known. Do you want to maybe give folks a good idea?
I think you sort of did in your description, but maybe just let them know what what fractional
means to you.
I think the hardest thing for me, you know, 10 years ago when I started doing this kind
of work was trying to explain to people the difference between like a consultant and a
fractional, right? A fractional is just simply not full time. That's all it means really.
Yeah, that's true. Yeah. So if if if I'm the CTO, I'm the CTO, it just might be working
for multiple companies because they're part time. Right. And I think that's the difference
is that I'm part of your team. I'm there with you in the trenches. I'm not a consultant.
I'm not, you know, whatever. I do do coaching engagements, which is more consulting sort
of stuff too. For you know, high performing software engineering and product development,
you know, what do we build? How do we build it? How do we operate it? Sort of stuff.
But the fractional side of things, if it's a fractional gig, like I'm part of the team
until such time as either I hire my full time replacement or or you don't need me anymore.
But it's it's basically an employee sort of arrangement. Yeah. Not not just some sort
of arms length consulting sort of thing. Right. Yep. I agree, which is why I don't want to
do it. Like, it's for, you know, there's everything, you know, everyone has their different roles.
I think in a CTO space, I could say it would be really, really great opportunity in a DevRel
space, which already has a lot of sort of who's talking to who is product talking to
marketing is marketing topic talking to sales, do they know what's happening with DevRel
and developer relations? And that's already sort of a political nightmare and to come
in part time and try to chase down that nightmare is not not as fun. But I think, you know,
in a CTO realm, I can see that be a really beautiful, rewarding role.
Yeah. Yeah. Like I said, it's really just about I love rolling up my sleeves and being
part of the team. And and I love earlier stage companies because you get to play so many
hats. You get to to get involved in the business, which, you know, I kind of believe that, you
know, every software engineer, you're with every line of code you write, you're placing
bets on behalf of the business. And if you aren't like fully in tune with what the business
is doing, even as a junior debt, like as much as you can learn about what the business
is doing. And when I'm working with CEOs and senior leaders, like my advice to them is
just spew your thoughts like help the team understand how you think, help the team understand
what do you want to be when you grow up? What is this company going to do? How do we approach
all this stuff? Because the way that you're thinking about it influences the code people
right, you know? And so if if if you're working, you know, like I said, even even as a junior
debt, the more you can understand about where we're going and why, the better code you're
going to write, you're going to make better decisions, you know?
Yep. And you're going to be more invested, right? I don't know about you, but for me,
like when I hear some vision and it's like, okay, I'm thinking about this today, but here's
where I'm going in five years or two years or whatever it looks like, I get excited.
Like if I'm invested and I care about it, I get excited and I'm like, okay, you tell
me how to get you there, right? Like how do we do this together? So I fully agree. And
I think I was just at a conference last week, which we were talking about how you had watched
yesterday's live stream. So you heard about this of actually a dev who was really like,
I really think we're making bad decisions. And it was one of those scenarios. It's like,
I don't think that enough developers find their way into those business conversations
or are exposed to those business conversations to really start to understand that and apply
that and bring that into their day to day, which I think is a missed opportunity.
Yeah, absolutely. So like my favorite scenario, which is exactly kind of what you're talking
about is like, you've got the typical situation, right? Where, you know, you've got a CEO or
a product leader or something like that who's like, oh, we got to go faster again. And the
software engineers are like, oh, but I have to make it perfect. I have to make it really
good. I have to spend extra time. And it's like the answer is probably somewhere in between.
Yep. But if everybody's invested in where we're going and why, then those conversations
get a lot easier because the conversation becomes not about making this perfect software
that's beautiful and that we like to look at six months from now, which almost never
happens no matter how hard you try really, right? Yeah, but it becomes where are we going
and why and what's the best way to approach that. And so, you know, one of the things
that I don't think I've ever figured out until I started my own business and start like,
oh, that's why this matters, right? Is like, when do you take shortcuts? Yes, yes, I couldn't
let myself take shortcuts. And I think early in my career, my managers got really frustrated
at me for that, right? Because I wanted to make it perfect. And they're like, no, just
get it done. And I never understood, because I didn't want to deal with that two years from
now or whatever. And the reality is, if the company doesn't survive for two years, it does
not matter what you have to deal with in two years, right? Yes. That was like, that was
something one of those like, I wish somebody had taught me as a junior dev or figured out
how to get through my thick skull. Yes. Junior dev of like, why sometimes it's okay. And
even like if you come into a scenario, you know, nerds, our favorite thing is to walk
into the room and look at the code and be like, well, I didn't write it. So that's crap,
right? And it's like, the reality is that code, that code got us where we are. And if
you know, so many businesses just don't survive, you know, my first startup total, total failure,
I went three years, I learned a ton, but that code's gone, right? Nobody's going to see
that code again ever. And it doesn't matter how perfect it was, the business didn't survive.
So if you're not making choices based on what the business needs right now, even if that
means taking ugly, packy shortcuts sometimes, intentionally understanding the impact, right,
placing the bet, then it doesn't matter. Yep. Oh my gosh, what you said, I was just
over here like, yes, yes, which you can obviously tell, but I started my business back in April.
So it's been, you know, I don't know, however long that's been, it's been a hot minute.
I have that problem. I have the, I need to reach perfection problem. And I couldn't figure
out and I've struggled with it my entire life as a dev also. I just, I couldn't figure out
I'm like, oh, I just feel like I'm delivering such greatness. And my coach was like, Hey,
I get it. But you know, you're probably delivering too much, right? Like they're looking for,
Hey, I need insights on this, this event that's coming up. And they maybe want something
that's a quick turnaround, right? Here's how you approach it. Here's you go talk to you.
Here's your, you know, your whole focus. Here's the goal, right? Here's what you're going
after. And instead I'm like, here's a 10 page strategy doc on how you're going to go to
this event and how you're going to show up and who you should talk to and why. And it's
like, they don't need all that, right? And I think as a dev, I constantly did the same
thing. I was like, everything had to be perfect. It had to be pixel perfect, like literally
pixel perfect, because I was more on the front end side. And it took longer. It took more
time, but I felt better about that. And I think that that's great and all. But like
you said, sometimes businesses don't survive. And sometimes you need all those strategic
insights to be able to say, Hey, I have this ticket. I know that this is something that's
sort of small. This isn't necessarily a priority for us in the future. This is sort of a, maybe
it's a patch, right? Whatever the situation is, to be able to say, Hey, you know what,
I can put my 75% in my 80% in, right? It doesn't have to be at 100.
I would almost re characterize that it's not as though you're not putting 100%. It's what
you're optimizing for, right? I'm always super passionate about what we're doing, right?
But what am I optimizing for? Am I optimizing for speed? Am I optimizing for quality? Am
I optimizing for UX? Am I optimizing for, you know, what is that? Right? And that's the
conversation. And so it's not about phoning it in. It's not about being, you can still
be a perfectionist. This is kind of how I solve the puzzle in my brain, right? I'm a
perfectionist. Change the definition of perfection to match the need at the time. That's what
it is, right? Yes. So, you know, and I still have trouble with it. I still like, I just
can't let it go. And every now and then somebody will be like, dude, just commit. Okay, that
happened yesterday, actually. But like, you know, that's still a thing. But, but yeah,
you just have to, you have to change the definition of the objective. And again, that's why the
business context matters. Because that helps you as your, you know, super anal perfectionist
engineer mind square away the fact that I'm going to hack this and shit that, right? Yep.
Because I'm shooting for perfection of a business. I want to get that extra funding. I need
to get to that release. I need to, because I understand why that's important, right?
I love that angle even more. You're still, you're still contributing your 100%. You're
still feeling like you're reaching that perfectionist level that you want to be at. But you're
focusing that energy in the right direction. Exactly. And like I said, it didn't get through
my skull until I actually own my own business. But if there's like a way for other people
to like, somehow, you know, grok that in a, in a way that doesn't require you to, you
know, take all your life savings and put it in a trash can and light it on fire, then,
then, then you'll be ahead of me.
We are so relatable right now. All right. Digressing from our dumpster fires, which
are all great lessons for everyone to learn, right? We talked about, you know, what you
do, do you have an official title or company? Do you work for yourself?
Yeah, independent and yeah, just, you know, fractional CTO and product development coach.
Love it. Well, we talked about earlier before we got in the live stream that you got to
spend the last six months remodeling your house, which is a nice little break. So with
that, what are you diving into these days?
Yeah, so I'm actually back working in a Ruby on Rails project with a client that I've worked
with off and on for 10 years. And it's really awesome. You know, I love, I've worked in
a lot of different languages and a lot of different frameworks. And they all, you know,
they're all tools. They were all built by somebody to solve a problem. And so they all
have utility and it's all different ways. But I got to say, you know, Ruby as a language
is so elegant. Rails is so, you know, I love the idea of opinionated software. And I think
Rails has done that as well or better than anybody else. And so is it the right tool
for every job? Absolutely not. But I love it when I get to play with it.
Yeah. What do you feel like is that so I don't have as much exposure to, you know, Ruby and
Ruby on Rails generally. I know many devs who build with it and the ones that do just
love it. And they are like, they swear by it. And so I haven't had the chance to actually
sit down and be like, why, why do you spare by it? So tell me like, what, I mean, what,
what is it about sort of that stack that really just you feel like is so powerful, but more
so, where do you feel like it plays the best role in what you're building? Because like
you would said, it's not the job that the tool is not the tool for everything.
Honestly, the way that I think about it in my mind is that there's a dichotomy between
Ruby the language and Rails the framework. So Ruby itself is like, it's, you know, people
compared to Lisp, things like that. It's like this crazy, crazy expressive language, right?
I feel like, and that's that's a double-edged sword a little bit. On one hand, I could probably
take an RB file, I could hand it to my grandmother and she could probably read it and have a
clue about what it does because a good Ruby developer, it almost looks like natural language
like Ruby itself, that you don't need any, you know, people talk about creating DSLs
for certain domain specific languages, things like that. Ruby just is that, right? You don't
need that because the language itself is so expressive. On the flip side, when you first
starting out, I remember when I first started it, I found it was very hard to write because
it's literally a blank page, like it is so expressive that it's hard to understand. So
Ruby itself has this crazy capability that's a little bit hard to wrap your brain around
and then you throw Rails on top of it, which is your, you know, your web framework for,
you know, APIs and web pages and database access and all this other stuff. And that's
all crazy opinionated about how you do things, which is what saves your butt from Ruby's
like, like it's so hard to figure out what to do with Ruby sometimes because it's so
expressive. Rails says, do it this way. And that tension is amazing. And then the other
piece about Ruby that's really interesting is that Ruby being interpreted language has
the ability to do things with like a lot of the best libraries and stuff, active record
is there, ORM, for example, like you can have a class that is just class user and that's
the entire class. And if you go define the rows in the, or the columns in the database
table at runtime, it has all the getters and setters for all those attributes automatically
as well as all the persistence methods and all that other stuff. So Ruby has this ability
to actually take a class and modify it at runtime. And that's a lot of how Rails works,
which gives Rails a whole bunch of crazy capabilities that when I first started doing it, coming
from languages like Java and dot net, things like that, I thought was insane and dangerous.
And but, but again, the Rails community is so opinionated on exactly how you use that
power that that's how it works. So it doesn't have a lot of safety nets in the language,
but the community has built these crazy strong conventions that are really powerful. And
it's, it's a very different way of approaching problems from Java, right?
And, and it has pros and cons. But when it works, it's beautiful. Like, like it's, it's,
it's generally easier to, to if you have a experienced Ruby Dev to show up on a new project
and be productive the first day. I've personally done that. I've seen it. I've hired people
who've done that. It's there. The conventions are so strong in that community that you can
be productive almost immediately, like walking into a Rails app is walking into any Rails
app by and large, right? And then kind of get into my, my next favorite catch phrase,
which is I love tools that make easy things easy and make hard things. And I think Rails
fits that well. Easy things are easy. Hard things are possible.
Right? Oh, that's great. Okay. So follow up to that.
I'm so excited. I'm so excited about Ruby, honestly. I'm like, hmm, so I have a future
guest in a couple of weeks coming on. His name is Brian Castle and he does. He just launched
this. Do you know who that is? I know the name. Yeah.
Okay. So he, he, I don't know when he launched it by Metamint events many years ago. And
I've known him for a number of years, but he has like an app in a month kind of a vibe
service where he's offering. And it's like, he'll come in and it's like on a weekly basis,
he's contributing to the SaaS product that you want to try to build out, right? Can you,
can you get to where you want your app to be? And then I just thought it was so interesting.
And now that you told me about Ruby and, and like Rails and how they come together and,
and the power there makes tons of sense because that's what he's using. And that's what he
like, he just thinks that it is awesome. And he's not a dev by trade. He actually came
in from sort of a different industry, but has been in SaaS and building these different
things. And so now I'm like, Oh, I can't wait to talk to Brian because I think he'll have
very similar sentiment, but also have sort of thoughts on what he's building and how
that's coming into play. So follow up on the, that, where do you think that that stack is
the most lucrative for building, right? Like when would you choose to use that versus maybe
something else?
That's such a hard question. I think, well, so, so I mean, here's the thing, like as much
as I love it, the reality is, is that, you know, practitioners of Ruby and Rails have
been generally, I think in the decline. And so, you know, I think a lot of that has to
do with talking with the founder about what they want to be when they grow up, what is
the company going to be and the culture that they want, right? So, you know, all of the
different languages and frameworks each kind of carry their own culture, which on, you
know, which, which, which on the good side is they bring their own superpowers and they
vary by language. On the flip side, they bring their own baggage, right? And so the baggage
in the Rails community is that the language is does not seem to be growing, which is a
bummer. And the practitioners, the, I would, I would probably say the average Rails practitioner
tends to be very, very highly skilled, very passionate about software engineering and
very, they tend to be, they tend to value productivity. Those are all great things.
They also tend to be expensive. They tend to be hard to find, you know, things like
that. And so it's, it's all kind of a question of what's the right tool for what do you want
to be? You're placing a bet again. Where do you want to be? You know, JavaScript developers,
JavaScript developers are everywhere. And a lot of them are fantastic. And the tools
are so ubiquitous that it's really hard to argue against picking something that has that
kind of inertia and momentum, right? So, you know, you're making those kinds of conversations.
But if you've got a case where, you know, you don't mind trying to find those rare,
very highly sought after engineers, and you've got a business case that is compelling and
interesting to that kind of culture, right? Then, you know, maybe that's the right choice
for you because you can build a culture that can innovate quickly and can do a lot of interesting
things that, that maybe are harder to do, not impossible, but harder to do in other languages.
See, now I'm really turned down by it because that would definitely be what, you know, I'm,
I'm, as I'm sure you can relate to, right, the perfectionist vibe productivity. I'm
trying to be efficient and maximize every day all day. And so to me, that's, that sounds
really, really beautiful. So we actually talked about this topic a little bit before we went
live. And we're kind of derailed from the questions that I really asked. But honestly,
that's okay, because this is such a great conversation. We talked about how all these
different language and different technical stack communities vary in so many ways. And
I fully agree. But I'd love to like kind of dive into that a bit, right? You just sort
of shared with us what Ruby, the vibes you get from Ruby, which I'm going to go hang
out with some Ruby devs, they sound like my people. But you know, a lot of what we get
in sort of the JavaScript ecosystem is going to be more of, you know, it's just like younger,
it's Hipper, it's, I don't know, they're just doing, they're doing sort of different things.
And I'd love to sort of talk through what you think you see, and kind of cross that
with maybe some of the things that I see, as we talk about different languages. So you
would mention some of the other communities you're a part of, do you want to start maybe
sharing some of those and things you've witnessed?
Yeah, I mean, you know, I've done, I spent a huge chunk of my career in Java, I've spent
a good chunk in that net, I've done a lot of JavaScript, I mean, that's kind of almost
in some ways the OG, right? I mean, that language goes back to the 90s. And, you know, and I
worked at a Golang shop, you know, Python. So, you know, I've kind of covered a lot of
the usual suspects. JavaScript and TypeScript are both, you know, I think they're on such
a tear in terms of popularity, in terms of usefulness, in terms of maturity. One of the
things that I think is really, really cool over the last few years is JavaScript as a
general purpose, especially back end, but even on the front end, language has really
started maturing. I think the interesting thing is that JavaScript is still carrying
and seems to be still struggling to figure out how to jettison the baggage of being a
scripting language from the 90s. Yeah.
And there's so much baggage that comes with this, all the transpiling, all of the, you
know, memory issues, the way the event loop works is much, much better than it used to
be. But, you know, async await and promises and things like that, that are, you know,
concepts that, you know, I wasn't part of the working groups that developed those, but
they feel to me very much like they were trying to, you know, I don't want to say polish a
turd, but in the sense like they were trying to take this language that was never designed
to do what they wanted to do with it. But because of backward compatibility, because
the runtimes are in every browser out there on every computer on the internet, and you
can't just go magically snap your fingers and change all that, they had to have all of these
backward compatibility features in the language. And so they've tried so hard to grow and develop
and mature this language while doing, you know, have their cake and eat it too. And it's
really created a lot of complexity in that space. And then the other pieces, the JavaScript
as a community seems very, you know, a little bit, what's the word I'm looking for? I don't
know.
I was trying to find the word too.
Is fad driven fashionable the right term? I'm not sure.
Trendy.
But front end frameworks, I'm so happy that React is finally kind of becoming almost a
de facto standard because for so long there, the front end frameworks didn't last a handful
of years. Every code base, every, if you're thinking about from a business perspective,
I mean, technical debt is something every company has to deal with. But can you imagine
building a product where in two years, you're almost guaranteed that all your front end code
is obsolete just because JavaScripters decided that Mu wasn't cool anymore. Right. You know,
it's really frustrating from a business perspective. So I'm really happy to see the typescript
and JavaScript community, you know, finally getting to some level of maturity. There's
still, I think, a ways to go to make it truly productive as it could be and as robust as
it could be. But it's making a lot of really good strides. I've done a few JavaScript and
typescript projects over the last five years that started feeling a lot better as an engineer,
you know, sort of thing.
That's awesome. That's good to hear. How does that compare, obviously, to like.NET and
Java, right? And then also, as you compare Java and.NET individually in themselves,
like what differences do you see?
So Java, I think, my experience there, because it's not used by a lot of startups, but I
have worked with some larger companies over the last few years and gotten a little experience.
I love what Java, Java has been trying to fold in more like historically, it was there
was so much boilerplate. It was so, you know, highly structured. It was so, you know, earlier
in the Java days, it was all about we need to build the most capable mousetrap possible.
And so everything was possible, which meant that you needed to know, you know, every possible,
you know, configuration option in that, you know, JEE server configuration file and all
of that. You had to lead through and create, you know, hundreds of lines of XML in order
to get things to run it all. And, you know, so much boilerplate, it was so painful. And
I think over the years, they finally kind of started doing it. You get things like
spring boots and things like that that are, I think, pulling a lot of great ideas from
languages like JavaScript and Ruby and stuff like that. And.NET is very similar as well.
What I love about what.NET's been doing lately is we're finally getting out of the world.
Microsoft, I think, really suffered from coming up in a world where commercial software was
all there was. Yeah.
And so for so long, the Microsoft community, the.NET community, like if it didn't come
from Microsoft, or if you weren't paying tens of thousands of dollars a year for a license,
then it was crap. Yep.
And, you know, that has taken literally like a decade plus to evolve. But, you know, the
current CEO of Microsoft is much more into the open source game. You got things like
VS Code, which are pretty amazing. So I think that's all been shifting. You're starting
to see more acknowledgement and widespread adoption of true open source projects in the
.NET world. I've been talking with a company the past couple of weeks here that is a.NET
startup. And so I'm kind of excited about getting my feet wet again in that world because
I'm a little bit rustic. But it's pretty, I think that's shifting quite a bit. It's
really interesting. I've always loved Microsoft's developer tools. Their IDEs were fantastic.
I started my career in Visual Basic and I remember going to some of the earlier Java
things like that. And I'd be like, well, where's the step through debugger? And everybody
looked at me like I had three heads. I mean, that's how far back this stuff goes, right?
And now it's like one of those things that nobody lives without. But Microsoft was doing
that in C++ and VB way back.
Yeah. It's really interesting. So when I first started getting into coding, it was like back
in like, I want to say like 2007, at least professionally, right? I did it as a high
schooler. I was building random stuff, trying to figure out how I can learn. I feel like
a lot of us, right? And as nerds, we are always sort of diving into those types of things.
But it's interesting when I first came into the ecosystem and have been working and like
understanding and I had a great conversation about this is like understanding the system
at which you're building with. And I think a long time ago, like earlier, like what you're
referring to, right? I didn't quite hit it. But it's like in that sort of vein of earlier
days of software development, it was just easier. It was easier, but it was harder, right? It
was harder because you were building more. It was more complex. There was more things
to manage, more things to think about. But at the same time, like I was, so this is going
to like air my, my dev chops. The other day, I was like, okay, I'm going to make an XJS
site. And I was like pulling stuff together. And I've been a leader for like five years
and it hasn't been on a CTO level. So I haven't been necessarily in a whole lot of code of
this one more in technique, technological conversations. And I just like couldn't even
troubleshoot stuff. And I'm like, just bring me back to my PHP stack where I'm like, I
understand how SQL works. I understand how everything works. And like, I know my system
where in these, these newer technologies, they're beautiful. It saves me so much time.
I had a website up in hours, right? But then I also feel like I'm, I feel more imposter
syndrome that I don't understand everything that's going on. And I think for me, it was
just a great conversation. And you talking about all this really sheds light on that
too of looking at sort of JavaScript compared to some of these other languages and, and
how, you know, that just this lack of system understanding, I think is something that's
a pain when you're looking in sort of the JavaScript ecosystems in comparison to others.
I don't know if you feel or resonate with that, but yeah, I have a lot of thoughts, right?
But it's, there's so many pros and cons to the whole thing. So like, so my degree is,
is I called it technology and communication. As in, I actually invented that title. I actually
mashed up a computer science minor and a communications minor. And because I was really interested.
So, you know, we're in the wayback machine now, like, Netscape was brand new, right?
You know, the World Wide Web was something most people hadn't used yet, right? I'm old.
And, and, but, but like, I love the idea that technology serves a purpose to humanity.
Like, like this is something that changes the way we live.
Yep. Right. And like, one of my absolute best friends in the entire world is the kind of
guy who you can, you know, he likes, he likes, you know, shove him in a closet, give him
a hard project. And once a month, you open the door, rainbows and unicorns come out,
you shove in pizza and Mountain Dew and you shut the door as quick as you can, because,
you know, he melts in sunlight, right? Like he loves the tech for the tech. And that is
so cool, right? But that's not me. I'm more interested in like, what did you do for people?
Out here? Yes. You need both of those. But like, that's where I come from is this sort
of, and that's part of why I gravitate a lot to the business problem is like, what are
we trying to accomplish here? What are we really trying to do for people? And so to me, that's
such a big piece of the whole puzzle that that it kind of influences a lot of what I
do with that. And so when you start talking about kind of getting back to the question
you really asked, like, like, I don't technically I technically have a computer science related
degree. And that's useful. I use bits of that to frame, like what's really going on under
the covers. And I think that's helpful. And I think that the more that people learn about
that stuff, the more it will help their career, it will help them with problem solving, it
will help them think about problems in different ways that can be very useful. But on the flip
side, like, I am so excited about the idea that software engineering has really, at least
as far as the stuff that I do, B2B SAS, you know, stuff like that, it's much more like
a trade than what I would call pure computer science, which is somebody working in algorithms,
like, like not just creating an LLM, but actually like doing the deep, you know, working for
open AI or Google or something like that, right? That's computer science, right, or designing
processes or whatever, right? What I do is really, to a trade. And so I love the idea
that that's becoming more accessible. I love the idea that I can go hire a boot camp grad,
not because they're cheaper, but because they bring life experience from some place that
isn't software, they've actually lived in the real world. And when you give them software
chops, they are able to sort of synthesize those things. They're able to bring in, you
know, information about a problem domain, whether that's finance or customer, you know,
dealing with customers or they were users of the software or whatever. They're not just
somebody who's been writing code since they were five years old. And that's all they do
is they know the code. And I think that you need both. But, you know, they're valuable.
It's really interesting for a lot of business problems. Yeah, I fully agree. Well, that's
actually really, there's a lot of little nuggets you just dropped in there, like a lot. That
was really good. Okay, so before we get too far, the other
thing I love about making it accessible is that it's bringing in not just a diversity
of thought, but experience and, you know, across all the vectors, right? People can
get into this industry. I think, you know, obviously, we're in an industry that is not
particularly diverse, and it's moving in the right direction. But I think making the languages,
the frameworks, concepts like boot camps more accessible is a wonderful sort of shortcut
or hack to adding diversity into the industry so that you don't have to, I mean, my, you
know, six year old girl is, I'm hoping going to be a tech nerd when she grows up. But that's
15 years from now, right? Yeah, like that's a generational shift that takes a long time.
But if we make the technology more accessible, then we can get there sooner. Yep, I fully
agree. I also fully agree with the ability of taking, you know, bringing someone in who's
had a previous career. I came from hospitality and business management and then that that
side of things, right? So customer service was something I focused on heavily, right?
So shifting into tech, I did it because I started having kids and I was like, okay,
I need to learn to code and I didn't want to be, you know, I started having kids very
young. I was only 20, 21, 22. Anyways, and so I just, I didn't want to be out late,
right? And so I'm like, how do I learn a different career? I loved to code, loved to
dive into things. And I really, truly am very thankful for the path that I took, even though
I'm like, oh, I could have been a developer sooner, I could have gone to school for it,
I could have gotten a comp side degree. And I'm like, no, because I wouldn't understand
it. I wouldn't be as capable as I am now because I was the dev that was like, come into the
client meetings, come talk to the client, they want this crazy technical thing. Can
you talk them down, right? Talk to them about what they really need so we can actually come
down to like, what are the features that truly need? And I think that's like, that's a magical
skill that I didn't realize was magical. And I think that I encourage a lot of others
to really try to expand on that on the communications on the ability to talk through those types
of problems with non nerds, even though we love talking to our nerds.
And it's impossible to be good at all the things, right? But that's why I love diverse
teams too, is you've got the person who likes to be shut up in the closet, solve our problem,
right? And then you've got the person you can put in front of a customer and talk them
off a ledge or put in front of the product owner and be like, you know, say in the nicest
way possible that they're crazy, you know, that sort of thing. And I would love that
job.
And they all skills and but they all sort of revolve around this idea of code and building
up building some software that's useful to somebody, but you need all of those things
to have a truly successful team.
Yes, I agree. Okay, so we derailed from all of my questions, which is okay, I think I
may be asked you like, you know, the what's your job title that one. One thing I am really
curious because you are a fractional CTO working in startups. And so if anyone is looking,
I'm a great person to reach out to you, but I'm curious because two of the questions I
ask and they're more towards the end. And it's just to help devs understand where they
should start going to find people like you or to find resources and learn what you've
learned. So two questions. First one, who are I should say, where do you go when you're
stuck, when you're personally stuck in something you can't solve technically or whatever it
might be?
Yeah, so ultimately, I think you need an array of different options, right? Because a lot
of times nothing, you know, one place doesn't work. And that's shifting obviously with AIA
and stuff like that. And so I usually try, I try to get good at solving my own problems
before I consume somebody else's time. So of course, you know, you're Googling your stack
overflow, your GitHub, you know, issues, you're looking for those sorts of things. Now you
can throw co-pilot other AI things like that into I'm starting to use those more. And I
think they're becoming useful. I don't think we're at the, you know, the holy grail yet.
I don't think our jobs are quite in danger yet. But that might happen. But honestly,
you've got to build networks too. You know, if you've got colleagues you're working with,
obviously that's your first stop. That's the best place. You know, I've been doing this
for 25 years and yesterday I had to, you know, ask my fellow coder like, help me, I am so
stuck, you know, and, you know, pairing up when you need to is just a magical thing.
And, you know, and you have to sort of get over your own ego, right? When it comes to
code reviews, when it comes to pairing up, you have to be able to say, I don't know,
I'm stuck. And, you know, can I learn something from somebody else? And then obviously, if
you're in a super hyper small company where you don't have like a panorama of people that
you can, you can talk to, then you got to find another community, right? And so there's
some great Slack communities out there. I imagine I'm not on any of them, but I imagine
there's some great discords and things like that out there for people in whatever stack
that you're playing with. That sort of stuff. But, you know, I think that that's, you got
to find ways to solve your problems, right? And that's what this is all about. And, you
know, figuring out how to connect with people that have similar problems is just the way
that we support each other.
I agree. Build your nerd herd around you, right? Who are you going to go to? Okay, so
very similar question. Somewhat different, though. So if you are looking for, let's say
you need a new tool or a new solution or you're building something and you're just like, Hey,
I know that, you know, maybe you're going to integrate something or you're going to
bring something else in. How do you start to search for those things? Like, you know,
maybe you're, I'm going to leave it at that. Where would you go to go look for something
like that?
Similar question.
That's a tough one for me personally, because I've, I'm usually the, the, the one who's,
you know, especially in a fractional CTO role, I'm usually not absolutely the most technical
person in the room, right? There's almost always somebody else in the room who has ideas
for how to solve it, right? And so whether that's a particular, you know, SAS tool or
a Dev tool or, or something like that, it's usually not me. And, and, and I'm totally
cool with that. And I tend to jump around frameworks and languages and stuff enough that
I'm not deep enough in any one of them at any given time to, to, to be the one with
those answers. And so again, I'm using that same community. I'm still, you know, either,
either talking with the people on my team or I'm talking with, you know, I'm looking
around at, at, I've got some Slack channels that I'm part of and things like that where
I'm always, you know, hearing about new things. And I try and, try and pay attention, but
there's so much going on out there right now.
It's pretty cool.
Tell me about it.
It's really cool.
I've been trying to stay up to date and like at least, you know, with it being like my
role, right, is like, I do competitive analysis and market insights and, you know, developer
experience audits of my clients, but then I also compare and contrast them to their
competitors. Where do you, where do you have that edge? Where do they not? And so I've
just been trying to be like, okay, let me just do market research, like just chip away
at it every day. And I'm like, Oh my gosh, the number of tools that are coming out. I'm
like, I'm just going to have to stay with like knowing the hip ones and hope that the
new ones just come in as clients so I can learn them that way.
Good follow up question to what you shared. And I think would be very insightful for our
users and anyone listening, you being in the CTO role, I didn't, I expected that kind of
an answer, right? Because oftentimes it's the users, the developers, the ones who are
going to be in that tool that want to advocate that up to their leadership and say, Hey,
we need this.
So what are some of the things that, you know, if a developer on your team really wants to
use a tool, like how can they come at you in the strong with the strongest argument
or sort of representation for you to be like, Okay, let's try it.
Bring data, bring a story, right?
You know, and data isn't always possible. But can you tell a compelling story about it?
About how this is going to make our life better? What problem is it solving? My favorite sort
of environment in terms of the question you're asking was a company where they had a really,
really amazing, it was a little bit larger company, they had a really, really amazing
infrastructure engineering and SRE team. And it was as a leader there, it made it super
easy for me because we could literally have a policy that said any team, I think we had,
I don't know, eight or 10 teams, it was a little bit larger company. Anybody can do
anything they want. If your team, you know, wants to go do X stack or language or whatever,
you're empowered to do that. However, we have kind of our official, you know, stack. And
if you use that stack, it comes with the observability, the alerting, the monitor, the canary deploys,
the, you know, all of the different things, the backups, the disaster recovery, the auditing,
all of those things, right? So if you want to diverge from our core stack, you go, go
for it. But you need to solve for all of those requirements. There were cases where people
did and it was good because they had a strong need for because of this other problem, this
stack was not a great fit. And so they solved for that. And that became another stack that
we could support. But it's sort of weeded out that because I think it's cool sort of
thing and brought it, yeah, business perspective of, okay, what's the problem I'm trying to
solve? And is this the right solution? And this is a case where it's a little bit more
of a mature company. Okay, so not always applicable to startups. But, but I think it provides
one healthy way to approach that problem, right? Where we could literally say, if you've got
a good idea, let's talk about it, right? Maybe it does solve a great problem. And we're empowered
to go do that. You don't even have to have permission, right? But you have to solve for
these requirements for the business and sustainability, right? And, and, and a lot of times that,
you know, if it was sort of a casual, I think rust is a really cool language, you know,
okay, fine. But, you know, if you don't solve for all these other things, it'd be like,
yeah, I think I'm just going to stick with what I got, you know, and, and, and I don't
like, you know, having people sort of resign to that, like, oh, I guess it's not worth
it, whatever. That's not what I'm going for. But what I'm saying is, is it opened the possibility
to make a business case that we would, that we would go forward with, right? And it's
okay. Yeah, and it's okay if they decide not to, because they've, they've gone through
that checklist and they're like, I don't need it this bad, or I don't want it this bad,
or it isn't, I don't need to chase down all these other things, right? It isn't necessarily
that you're saying, oh, good, you gave up, right? It's more of like, no, you did what
you needed to do. Is the problem worth solving and solving all of these different areas?
Or can you solve it in a different way?
Put a more objective lens on it, right? And it allowed you to really evaluate the, you
know, whatever ROI or whatever you whatever, whatever terms you want to use there, right?
But, but, you know, it, you can get to a point where you're really talking about, is it worth
it? Is it valuable? Is it something we need? And there were cases where it was, right? You
know, the, the, the analytics team, you know, wanted to use Python. And that wasn't part
of our core stack. And, but that's a crazy, crazy powerful language and stack for analytics,
right? Absolutely.
So it made sense. And they did the work. And it was great, right?
Yep. I love that. I think that's, that's a beautiful, a beautiful blend of like sort
of both ends of the, of the spectrum, right? I'm just saying yes to all the things and
ending up with technology, you're trying to update like we talked about, right? JavaScript
frameworks changing every few years, not too long ago.
Right.
I think it's a beautiful answer to that versus like, go do what you want, right? It's not
the wild wild west. We've got some, some, some, what's the things in bowling, the gutters?
Are they, they, what are the things they put? Is that what they call them? Yeah, like those
little bouncy things. Any of that. I was trying to say that smoothly.
Yeah, yeah, yeah. That's when the kids use, right?
The, yes, yes. I can't think of them either way. We know we're envisioning it. You're
stuck in a lane. You can do what you want in your lane, but you can't leave that lane,
which I think is a really safe lane.
If you can do it in a way that's, you know, that, that meets the objectives that meets
the requirements, right?
Yes. Yes. Exactly. Okay. I could honestly talk to you for like hours. You are so interesting
to talk to you. Maybe cause you're a fellow Minnesotan, you know, so we've got that Minnesota
vibe going on.
Got that connection.
Yeah. Where can people find you? Cause I think they're going to be intrigued by a lot of
what you're sharing. And I think obviously you have this beautiful opportunity where
you do fractional CTO and there might be folks looking for your services. So where can, where
can folks find you?
Yeah. I need to do some work on my, on my marketing materials.
I can help you.
The best place to go.
Yeah.
So Neil Topsen was it slash in slash Neil Topsen. And, but yeah, that's, that's, that's
probably the best place for now. And I'm working on, working on getting better at the marketing
stuff.
I literally do marketing for my dev tool clients and my own marketing is complete trash. So
I don't know your website.
It's a work in progress.
All right. Well, this has been absolutely lovely. So great hearing from you and so awesome
to hear about your journey and everything that you've shared. And I hope that you have
a fabulous rest of your day. Give Minnesota a big hug for me.
We'll do, we'll do big cold hug.
Yeah. Cold hug. We need those hugs there, right? It's chilly.
Awesome. Thank you.
All right. Yes. Thank you.