Kevin Montalbo

Welcome to another round of Coding Over Cocktails. I'm your host, Kevin Montalbo. 

In this episode, David and I talked to Eric Dietrich, founder of DaedTech LLC, and Hit Subscribe. We tackle how modern enterprises are taking on various approaches to software development and digital transformation, the problems they're encountering and how the future of labor for developers looks like.

Of course, joining us today is my co-host, CEO, and founder from TORO Cloud David Brown recording all the way from Australia. Hi, David. Good to have you as always. And of course today's guest is the founder of DaedTech LLC, a programmer, a software architect, an IT management consultant and a technologist. He's also the co-founder and CEO of Hit Subscribe, a company specializing in tech content marketing. Over the years, he's authored several books, his most recent being “Developer Hegemony: The Future of Labor,” which explores the past, present, and future of the corporation and what it means for developers. 

Joining us to share his knowledge and expertise is Eric Dietrich all the way from Michigan. Hi, Eric. Good to have you on

Erik Dietrich

Hi, Kevin. It is good to be here.

Kevin Montalbo

Great to have you. All right. So, let's begin with our questions with Eric. But before that, tell us more about what you do at Hit Subscribe. How do you see your platform change the way businesses should look at the IT side of things?

Erik Dietrich

Hit Subscribe is - my role there is I'm the CEO. It was a business that my wife and I actually founded sort of opportunistically. I spent a lot of years doing IT management and strategy consulting, but I was also a pretty active blogger and writer. And during the course of that, companies would reach out to me, usually in the developer tool space, specifically static code analysis because that was my specialty. And I would do this blogging for them in my travels, like in hotel rooms at night, I was doing a hundred percent travel. It was fun, but as enough companies reached out and asked about this, it kind of hit me in the head like, “Hey, there's a business opportunity here.” So my wife and I - she being an editor by trade - decided to found it like soup to nuts content business.

And the original plan was for it to almost be a side hustle. Like it was just a way to kind of even out the revenue, that's, you know, with consulting. There's a lot of feast-or-famine type revenue but it just took off. And so, um, what I do there these days is it's grown. I have moved into the CEO role of that business and we brought on staff and everything else. And so we are helping specifically companies that market to software engineers with their content marketing. So, my role is kind of overseeing all that, doing sales and having relationships with clients. And I guess the way I would see Hit Subscribe impacting businesses is the content marketing that we're doing is kind of bridging the gap between traditional marketing and the way you would market to the engineering org.

The gap that we perceive there was basically that companies would hire somebody that was say a marketer and the marketer would go out and produce content that was aimed at software engineers and attended a land flatly just because there wasn't that knowledge, a lot of engineers are consuming tutorial, style of content, so on and so forth. And there was a real gap. So by bringing a software engineering background and building a company where we're bringing in software engineers as the authors and marrying that with marketing I think that the way we're changing things kind of in the community is infusing engineering into the idea of marketing. And I'm a believer in infusing engineering into the idea of kind of disciplines across the business. And when you have businesses that are kind of by engineers for engineers, I'm a firm believer in engineers being participants in all phases of the business. If that makes sense.

Kevin Montalbo

Yeah, absolutely. I personally can relate because I work in the marketing field and so it's true. It's very, it's quite difficult to try and approach software engineers, software developers with a very broad marketing kind of approach. They need to have their own like, approach to them.

David Brown

Eric, do you find it difficult? Because we find that an engineering mind and I guess there's a left brain-right brain kind of scenario where engineering tends to be more of a technical, analytical type mindset, whereas, copywriting tends to be more of a creative type process. And so do you find it difficult getting engineers, which can cross that bridge? 

Erik Dietrich

Yes and no. I'd say that if you, there are, you might think of them as unicorns. There are a number of engineers that we get into the fold that are very good technically, and they're also good storytellers, good writers. So that does occur. It's more common that you know, pros isn't their primary – it's not their superpower, if you will. And so what we've done is we have a staff of editors that are kind of functioning often as writing coaches.

So in some cases we get these unicorn authors that just kind of do it all. And then in cases where they really do prefer to stick to kind of like, tutorial style things, or they're not really as comfortable with the pros, we have staff that are working with them to kind of smooth things out or bring out that side of them to the best of their ability. So, there is definitely a gap that exists a lot there, but we feel like kind of, we've all evolved over the years to be good at bridging it for all the folks that we're having right for us.

David Brown

I understand.

Kevin Montalbo: All right. So, moving on in your article in DZone “Characteristics of good APIs,” you mentioned that good APIs offer simplicity and it takes a good bit of effort to preserve that simplicity. Can you elaborate on that?

Erik Dietrich

Sure. So, I went back and I wrote that article a few years ago and I was kind of taking a look at it. And, when I was looking at it, I was reminded kind of randomly of, I don't know, it was maybe 10 years ago now I was working at a company that manufactured hearing aids. And my group was responsible for the fitting software it was called. So this is basically what the audiologists would use to interact with from a GUI perspective. And then they would plug a hearing aid into the USB port. So this piece of software, this gooey piece of software added kind of a backend component to it that was talking to device drivers. And my background in the years before that had been a lot of embedded stuff, Linux, Kernel programming, et cetera. So I fell into the group of us that was kind of more on the backend of that.

And I remember one device in particular had this really old kind of like windows CE in her face. And I don't remember the API exactly that they were exposing that they had to consume, but it was the kind of thing where they were passing a lot of variables in by reference like creating these data structures. It was a very awkward complex API that made you think of like C programming from the eighties. And the reason I'm citing this example is because if I think back to that, I was kind of faced with two choices. I was writing this code in C sharp, and it was going to be consumed by people that were more comfortable in the gooey. And what I could have done is just kind of passed through that API that I was dealing with and said, “Okay, I'm going to make some simple calls here.” And I'm just going to let this, the authors of this API determine what I expose to the consumers of my API, or I can go the extra mile to expose a pretty simple API and cover up the complexity. 

So, I think that complexity kind of begets complexity if you're dealing with something that is optimized, I guess, to work rather than to present a nice interface. And this is true, whether it's a graphical interface or an API, you know, an interface that you're exposing to consumers of your code, that it takes a lot of work and diligence to encapsulate the complexity and expose simplicity. So that's what I was getting at with that statement.

Kevin Montalbo

Yeah. I like how you included the Principle of Least Astonishment in one of your points. So it's true that you want an API to be as user-friendly as possible, especially in a complex and technical space, such as where we are right now in software development. So, what I got from this is that developers need to take a more developers of the API. I need to take a more considerate approach with a, like do what I mean mentality, if that makes sense. So when they're trying to develop API and probably software in general, is this what you advise their clients when you are doing code base assessment?

Erik Dietrich

In as much as that would have come up, I would have to say, I like the way that you're describing this as being considerate. So, if I found myself in a position where there were engineers within the team producing an API or some kind of piece of code and others consuming it, I would have given advice like that. It would have been fairly tactical, like, so most of what I was doing with my code base assessment practices is I got pretty good with static analysis tools of kind of turning code bases into data. And I would come in typically with organizational leadership. I'd be working with C-suite or maybe a board of directors, and they would be wanting to make critical decisions about their application portfolio. So a particular code base, do we retire this thing and sunset it? Do we try to evolve it? Do we scrap it and build something from scratch? Usually I was helping with decisions like that. Sometimes it was, do we have the right folks? Are we trying to build with the right tech stack, given our staff? So answering questions like that.

If I were doing an assessment of, is the staff kind of approaching things the right way, is this a code base that we can evolve? I could have seen giving specific advice about producing and consuming APIs that probably came up from time to time, but that was for my clients, like the people that were bringing me in that would have been pretty granular. They would've been looking for understanding of their code bases and broader strokes. If that makes sense 

David Brown

At TORO, we often get asked about migrating legacy systems. So, large monolithic code bases and our legacy system, which typically underwrites a core function of the business. In your consulting days when you're doing these assessments, did you come across these legacy migrations and the challenges associated with migrating those? 

Erik Dietrich

Yeah, definitely. That was often central. I'm trying to think of the different situations quite often. I don't want to say always, but quite often when I was brought in, there was legacy code involved because in the practice that I had where people were making tough decisions, like people were calling me in to tell me how great everything was going and that, you know, their whole department love the Greenfield development they were doing. So it was usually, you know, we're on this old mainframe system and this ecosystem of cobalt that grew up around it, and we're building these Java apps on top of it. And what do we do? So a pretty common situation was we've got this legacy app.

How do we phase it out? Another kind of common situation is we started this forklift upgrade to try to, you know, wholesale replace the legacy system and it's not going well. So that's where, you know, we'd be getting into the migration conversation is like, well, how can we maybe slice what we're doing in such a way that we're not building a replacement for this thing for five years, and then trying to cut over, you know, with a flip of the switch, which I think everybody knows isn't going to go very well. So, um, to answer the question, there was often a legacy migration at play, or there was often a legacy system that would be a growing organizational risk at play. Like literally we can't find people who know how to maintain this code base. So there's, you know, a real kind of drop dead data on this coming in five or 10 years. It was usually things around that. So, like the legacy system would typically be the elephant in the room. And a lot of the discussion is what are we going to do about this?

David Brown

How do you see APIs and microservices facilitating legacy system migration?

Erik Dietrich

Generally speaking with the enterprise clients? I would view an approach using microservices or using the term I would use a lot was like thin slicing anything that we'd do. And I would see those as like a fundamental piece of enablement to get away from a legacy system, because the failure pattern was always you know, the first thing that these enterprises would do is they'd bring in, you know, some huge app dev body shop or something to build an enormous piece of software. And then inevitably that attempted to wholesale switch away from the legacy system just wouldn't go well. So then the conversation is, okay, we have this race, you know, we're still kind of maintaining the legacy system and doing stuff to it while we're in parallel trying to perfect the new system. And they come to realize that there isn't going to be this magic switch-over moment.

So what do we do? And usually then the conversation is like, well, all right, what can we do? That's, you know, slicing things thinly where we can get some kind of win, like how do we get one little piece of this legacy system routed over to the new system? And inevitably the answer there is, um, some kind of like, adapter or proxy type concept. So you put something in front of the legacy system, say in the form of a microservice, you have a just call through, into the legacy system. And then once that's all structured well and going well, you put in some kind of feature flag where you can flip it over to start being serviced by the new system. And then if that goes poorly, you know, you just flip it off and go back to where you started and if it goes well, then, “Hey, you've migrated a little tiny slice away from the legacy system.” And so based on that pattern, usually I'm advising clients to build on that series of wins by, you know, deconstructing and winning on small bets.

David Brown

That's interesting. We've talked a lot about that concept and we take them to that approach with a lot of our customers to our cloud, because the proxy you're talking about is of course our product Martini  that we proxy solutions through and expose those, that legacy system being that bridge, that connector through our integration platform. And then build those microservices piece by piece, it seems to be that sort of incremental approach seems to introduce a lot less risk and makes having bite-sized chunks seem to make what's the end and otherwise daunting project more approachable. And is that your findings as well?

Erik Dietrich

One hundred percent. If I think about the management consulting I did in the IT space, so many problems, I think were attributable to trying to do things in way too monolithic fashion. I mean, you could apply like the term model to an architecture, but also to like old software development methodologies. So like usually when I was consulting in the enterprise at Fortune 500, all of them were always going through some flavor of agile transformation or dev ops transformation. And if you really boiled that all down to kind of its core it's that they were all trying to figure out a way to get away from, you know, creating these four year long programs that would get funding and kind of go off. And the idea was, meet back here in four years when everything's great. And so just across the board, it was always chunking and batching too many things together and trying to win them all at once, rather than, you know, trying to peel off something and build on those wins.

David Brown

In that respect, how are you finding enterprise a success in that regard? So, they're moving away from those four year projects trying to become a more agile and responsive organization to the demands of the market and that requires a mindset as well as technology change and a DevOps process. How successful are you finding enterprises in that transition?

Erik Dietrich

So I say this from the perspective of having really moved away from that management consulting practice over the last two years to just running it subscribed these days. So, honestly now mostly I hear about what's going on either through old contacts, just purely anecdotally, or honestly, through a company's doing case studies with like enterprise clients. And so if they're doing case studies, usually just hearing the good stuff, but what I would often see with enterprises is they would be making a good faith effort and they'd be making genuine progress towards better things, but it seemed that they were in a lot of, they would have the deck stacked against them. So I remember, you know, talking shop with people at the hotel, other consultants that had seemed like we were taking enterprises from crawling to walking, but then compared to startups, the startups are running.

So even with these good faith efforts, it's tough for the enterprises. And it seems like they're often doing a lot of innovation through acquisition or kind of wholesale plays like that rather than  doing a migration where they start out in, you know, sort of this old school waterfall world. And then they just magically become, you know, over the course of four years of effort, some kind of startup like company.  You just didn't see a lot of that. If you saw transformational success in the huge enterprises, in my experience, it was usually what they had done is created a pocket of innovation within the enterprise where they removed a lot of the restrictions, you know, brought about by having a lot of risk mitigation strategies, like compliance departments and legal and all of the things that would kind of tie these groups hands. They would create this little pocket that was sort of insulated from that stuff. And then they would have success in that pocket, but it was a lot tougher for them to kind of top to bottom across, you know, 200,000 people or however many enterprises kind of full on and brace that type of transformation.

David Brown

Where do you see the biggest challenges faced by these enterprises? Is it a management level problem? Is it a technology problem? Is it a cultural problem? What's the biggest challenge becoming as you say, from taking that waterfall approach to an agile approach?

Erik Dietrich

I would say philosophically, the biggest challenge is almost that they're victims of their own success and size. So as an organization goes from startup to kind of mid-market and then eventually to enterprise, they become a bigger target, whether it's for, you know, fast follower types or whether it's for lawsuits and litigation or any other number of things they wind up dealing with a lot more regulatory concerns. And what starts to happen is because their risk surface area grows so much. They have all of these risk mitigation strategies in a vacuum. That makes sense. So if you look at an enterprise and they have policies against just ad hoc adoption of open source technologies, that's probably come from some battle scar they've gotten sued or something's happened. So they've, you know, developed antibodies against that within the organization. And as they grow, they keep building that up.

And what I remember going from, you know, whether it's banks or manufacturing companies, et cetera, uh, when I'd be sizing up individual groups, there was nothing in particular that the developers there were subject to that was overly onerous, but I would always think of it as death by a thousand cuts. So, you know, they'd get to their desk and they'd have some problem when they would log in. And then it would take, you know, the it group awhile, cause they weren't empowered to deal with that themselves trouble logging into the computer. So somebody from it has to wander over and get them into their own laptop. So they've wasted a morning there. They have, you know, maybe all of these emails to catch up with that are coming from these cross-cutting corporate concerns. So they waste some time there. They finally get into their code base but it's really taking a long time to compile because they're using some ancient version of customized net beans or whatever that they didn't pick. That's forced on them by the company. 

And then when they're trying to debug, maybe they would go to stack overflow, but the net nanny stops that. And so it's just on and on and on. And no one of those things is unreasonable in and of itself and they all from the organization's perspective makes sense, but they all accumulate on top of those engineers to make it a real challenge to develop an innovative culture. 

David Brown

I was going to say it's all too easy sometimes to say, yeah, the top three challenges associated with legacy system migration of becoming an agile organization is cultural change technology, DevOps process and whatever, but in reality, it's actually a whole bunch of things, isn't it? And it's all those little things you compile on top of each other. And, it's a difficult process. It's you know, really, there's no way around it. You have to do the hard yards. You have to, you're going to experience some pain points. And so, you know, I think it brings us back to our original point of breaking it down into bite size chance is more, perhaps more approachable and learning. You make some mistakes, learn from those mistakes and that you haven't spent four years building that stake. You'll know that all this technology spending those four year projects, a lot of it gets wasted, never used in the end as well. I'm sure you've seen your fair share of that.

Erik Dietrich

Yup.

David Brown

We also wanted to ask you about your book Developer Hegemony. Kevin?

Kevin Montalbo

So he was talking about doing some consultancy for firms. So, I think this transitions perfectly into your book Developer Hegemony. You said it's a nod to the idea that organizations, especially enterprises and corporations tend to hit three to seven years of management above software developers. Can you explain to us what this means?

Erik Dietrich

Sure. So, the book that I wrote when I was writing, that it was during the thick of these travels and I had come from a software engineering background. I spent a lot of years as a software engineer, and then I kinda moved up the org chart, dev manager, CIO, and then consultant. And as I was doing these travels, I was immersing myself in code bases, interviewing, engineering managers, engineers, and looking at the way that this worked within and there was a lot of frustration, you know, that I felt on behalf of these folks, the individual contributors, the engineers, and kind of putting myself back in that same role. And so it was, I think of it as this like developer populous book, um, that expressed a lot of my frustrations and sort of, there's a lot of cynicism in it, but also in the end, I think a lot of, um, you know, what I hope for in terms of the future of the organization.

The idea of all these layers of management on top of the software engineers was kind of a look at is this the best situation for innovation? So, without mentioning any particular straw man of a company, but let's take a non-fan kind of Fortune 500 companies. So, a traditional brick and mortar institution that's been around for a long time and over the years, I think the conventional wisdom that I certainly wouldn't disagree with is that all companies are kind of becoming software companies with a lot of these traditional organizations. You had them become software companies in kind of a reactive way. So it's coming from a world where it has almost always been a cost center and they've developed reactively these software engineering organizations. And what I would go in and look at is that they're doing these agile transformations and software craftsmanship or dev ops transformations.

And they're struggling with this fundamental idea of why is it no matter what we seem to do and seem to try, we can't have the kind of culture and the kind of innovation that startups do. And I started to unpack a lot of those ideas in the book. And one of the things I asked, especially given that I would see the best way to have success in the enterprise was to create this isolated pocket that was sort of sheltered from the organization and let it run like a startup. So I started to say maybe the best situation for innovation with engineers isn't large organizations with this huge risk surface area. What if hypothetically speaking, instead of these companies, having staff software engineers, if they were just contracting with kind of small app dev firms to do the organization, then you're sort of pulling the risk out of these enterprises directly, and creating kind of a barrier and insulation against it.

And so what I said in the book about all this management that's heaped on top of the engineers, is that it creates a lot of things that make it hard to have good morale and hard to do hiring in the enterprise. So just, you know, strictly speaking, if you have, seven layers between the CEO and the individual contributors, that's a lot of inertia in the pain matrix alone. So if you say, “Hey, we're not competitive in the market with paying our software engineers,” it's not just a question of bumping their salaries 10%. 

You have to evaluate the whole structure and kind of, and on from there. So in the book, I was taking a look at this and saying like, what if instead of all of this management being applied to software engineers, you pulled them out of the enterprise, let them form these firms and give them a lot more decision-making responsibilities in terms of the innovation and how they interacted with the organizations. And that kind of coalesced as well with the agile idea of I forget how it's phrased in agile circles, but the idea is to create management structures that let the people closest to the metal make the decisions. So if you have an engineer that's looking at, you know, what, what should the architecture of this be that shouldn't be a decision that's routed up to some director, you know, like let that expert make the decision. So it's kind of an extension of that philosophy. 

David Brown

It seems like it's entirely, although you said you wrote it a number of years ago and you were cynical at the time and almost apologetically, it still seems like there's still a lot of relevant points like you said. And when you're talking about creating these autonomous groups and you're talking about making it outside the organization, in terms of like almost a consultancy, we've seen organizations perform exactly the same function whilst it's not a separate entity in terms of a separate company, they are treated as independent entities. So they give these developers their own workspace outside of the traditional corporate office. They make them autonomous, they give them a goal and success, I go and achieve it. We're not really sure how you're going to, to achieve it. And sometimes it would be a goal which would otherwise seem unobtainable within the bureaucracy of the corporate head office. So whether it's a completely independent entity in terms of a third party consultancy, or just treated, treat your own organizational structure as a sort of separate smaller agile entities. I think that the moral of the story I think is still the same.

Erik Dietrich

Absolutely. I love that idea. And  it's great to hear that that's occurring because that decoupling is exactly the kind of thing that I was clamoring for as I was writing the book is, you know, give those intelligent folks more autonomy and let them make more decisions. 

Kevin Montalbo

So, what do you think does the future hold for software developers? 

Erik Dietrich

The thing that I predicted in the book, and then you know, still see every reason to believe will happen is I feel like there's going to be kind of a flow out of larger organizations. And, you know, maybe it does if larger organizations, if enterprises are coming around to the idea of creating these pockets, maybe that's the shape the flow will take. But in general, what I predicted just based on looking at what was going on in the enterprise and how much trouble they were having with retention, I was seeing a future where software developers leave and they form their own small firms.

And in the book I was kind of talking, I gave them this term called efficiency, which is my way of saying, you know, I created a neologism for this to say, it's like an automation professional. So instead of a situation where you have an engineer who maybe starts a firm with a handful of people, and then it goes out and gets a project manager involved, and that project manager tells them what to do. It's almost like the engineers run the business as if it were kind of a law firm. And then they're delegating aspects of project management to people that they're hiring. And I don't know if that exact structure like saw software engineers, making firms that looked like law firms is what's going to happen. But I do see a more autonomous future for those folks. I see more independent entrepreneurial software engineers.

Some of that might just be that I travel in circles with a lot of software engineers turned entrepreneurs. So it might be, you know, recency or exposure bias, but I feel like that's happening. And I also feel like software developers are going to involve themselves in more business functions than they maybe have historically. And, I think of my business Hit Subscribe as kind of proof of that. We're involving software engineers in writing blog content in looking at SEO and doing marketing planning. So I think those are the two main things kind of more autonomy, more independence while I use three main things, more autonomy, more independence, and more integration with other business disciplines.

Kevin Montalbo

All right. So, how about for new developers coming into the industry? What's your advice to them?

Erik Dietrich

So, if I think of it, it's always struck me that entry-level developers. It, you know, and I could be wrong about this, but entry level developers like to struggle to get that first job. Whereas once you've kind of been gainfully employed as a software engineer for a bit, it seems like most people really don't struggle with that anymore. So if I'm thinking about new engineers coming into the industry, I guess the first advice I would offer is like, please don't get discouraged. It'll only get easier to find work. What I would also suggest kind of in a nod to the increasing autonomy and, and multi-discipline status of the software engineer is think about creating a presence for yourself. So yeah, absolutely apply to all the jobs, you know, try to get work that's priority number one, but think about starting a website or a blog you think about, contributing to open source through, GitHub and think in general about what can you do to sort of differentiate yourself in a meaningful way and to create some social proof around you in what you're doing, and maybe even think about developing kind of a specialty or you know, I don't want to call it a hobby, but like an area of interest.

So, I'm not just a front end developer, but maybe you're a front end developer that's interested in chat applications or something like that. So, give some thought, I say to your career arc and specifically how potential employers, or maybe clients are going to view you as an individual and rather than just a collection of, you know, experience tubals on your resume that are, you know, this many years of this thing in this stack.

Kevin Montalbo

Yeah. All right. So, I guess that's it for the end of our podcast, unfortunately. I've enjoyed it a lot, Eric. Where can they go to find you or where can they go to read your book?

Erik Dietrich

So, if you go to my website, daedtech.com, which is D-A-E-D-T-E-C-H.com, that's a great starting point to kind of find me in all the places. I do things. I have a YouTube channel, some social media with varying levels of activity there. But that blog, I write it, I have a link to the book, other books I've written and that's kind of the nexus of all of my contents. So if you're interested in what I'm doing, it kind of all starts there.

Kevin Montalbo

DaedTech is that Daedalus?

Erik Dietrich

Yeah. It's sort of originally modeled 10 years ago when I created it after the Greek character Daedalus.

Kevin Montalbo

Oh, okay. All right. Thank you very much. Thank you for that, Eric. 

Erik Dietrich

Thank you for having me. 

Kevin Montalbo

That was TORO Cloud CEO and founder David Brown, as well as Eric Dietrich for Coding Over Cocktails. Make sure to check out Eric's book and his work at daedtech.com. That's D-A-E-D-T-E-C-H.com to learn more about him and all the other stuff that he talked about in the show. 

You can also listen to our previous conversations which are available for streaming or download on your favorite podcast platforms. Also visit our website, of course, at torocloud.com. We're also on Facebook, LinkedIn, YouTube, Twitter, and Instagram. Just look for TORO Cloud. Thank you very much for listening to us today. This has been Kevin Montalbo for Coding Over Cocktails.