DIM-EPISODE: BRAD WILKENING (FOUNDER DEVMYND SOFTWARE)
DevMynd Software - A Modern Custom Software Agency co-created by Brad Wilkening is a technology shop that steps outside the box, employing new concepts and an approach that works.
Realizing that you don’t have to be a perfect programmer lead Brad to where he is today. Knowing that and how to deal with it helps to manage a successful team. The principal engineer is the unicorn, the magical piece to the puzzle who is the project manager of development solutions. The high quality craftsmanship of his team's work is incredibly important for their software solutions to succeed.
While software development has been heavily weighted towards the developer, Brad discusses the importance of looking at the user of the software and working towards their needs. Looking at the end user, their needs, and developing a relationship with the client are paramount for creating a lasting impression and increasing the clientele base.
Jim Jacoby and Jim Cohen are regularly sought after for keynotes, lectures, and for custom consulting. If either of those are of interest choose a next step below.
Brad Wilkening is a career software engineer who has been writing code, managing teams, and working with clients for two decades. Three years ago he chose to start DevMynd Software - A Modern Custom Software Agency. In that time he has grown it from 2 to 17 people and had over 50 clients.
Debs Cane: We have Brad Wilkening today on the podcast. Brad Wilkening is a career software engineer who has been writing code, managing teams and working with clients for 2 decades. 3 years ago he chose to start Dev Mine software a modern custom software agency. In that time he has grown it from 2 to 17 people and had over 50 clients. Brad thank you so much for joining us on the podcast today.
Brad: Thank you for having me.
Debs: So usually we start out by just asking you how you got to where you are now.
Brad: Sure so when I was growing up it always seemed like we had technology nearby and I was always playing with it. My family had a strict discipline of using our tax refund to buy fun stuff which basically funded computers and instruments for my entire childhood but it was only once a year and it was in a weird season right. After Christmas, it wasn’t for Christmas. It was after Christmas.
As a result of that I started getting into programming when I started out it was typing in a couple thousand lines of code and then trying to figure out whether or not the game where you throw a banana at a gorilla was going to behave and then I basically take the output of it and fix it because when you type in 1,000 words you are probably going to get one wrong.
Jim J: I think I coded that game too. That was a good game.
Brad: It is amazing when you can get software in a magazine except for it gives you the task of typing in 1,000 lines in order to achieve it as well.
Debs: This was in the days before cut and paste.
Brad: Yes it was. Email was not a term that was commonly used. After that I basically went through the high school and at the end of high school I realized that I didn’t have any money to go to college and that I knew how to write software and people kind of wanted that. So I just started coding.
Probably half of my career I was a terrible programmer. Probably more than half actually but I had a good 8 years of incredible growth when I decided that it was time for me to actually pay attention to myself and that kind of ran me into starting to understand custom software development and how to deliver, how to have consistency through projects and so now I am basically at a point where I am building the best dev. team in the world and figuring out how to find new clients and basically I have broken that mold, I have taken that mold of just go write software Brad and shattered it and now I have to put my head on for marketing and sales and all these other crazy kinds of things that I never had a consideration before starting Dev Shop.
Cash flow, what is that? All these things are kind of shocking once you are so heavily indebted to just building software that these things are pretty shocking but it has been a fun ride and I am looking forward to the next 2 or 3 years where we are probably going to double in size and we are always working on great stuff. So it is always a fun time.
Jim: At what moment did you decide to cross over and stop being the one man show of Brad and having more people involved? Did you just sort of oversell work or how did you make that decision?
Brad: There is a little bit of serendipity there. So Dev Mind was actually started on paternity leave for my first daughter’s birth. I took 2 weeks of actual paternity and then I started working on a client that a friend of mine referred over to me. So I kind of just fell into having this client during a time where I didn’t have to go to my 9-5 and then as I realized that there is a lot of people out there that could use my help I started of course I called my former employer and said I don’t need free health insurance anymore I am not sure if you are familiar with the FMLA but it means I get free health insurance on paternity leave. So basically I called them and said I am done. I think they kind of guessed to be honest.
Jim: They could see it in your eyes.
Brad: Well you know every day that I was there I was always being an idealistic guy in his 30s which was odd. I was always trying to suggest things like a better way to do this, a better way to do that and they never really listened to me and I think that they knew that I was I had a bit of an itch to start my own shop.
Jim: So then you do it and it’s a Dev shop you are pretty specific about that. It is a Dev shop. How would you define that?
Brad: So software development agency I guess is the proper term but basically you throw ideas in you get software out. It is a Dev shop if there were giant machines associated with building software it would feel that way. When you go to a machine shop and everything is really loud because of all the things that are being manufactured it kind of feels that way to me too. It is a shop where we are building things and there are loud noises and there aren’t actually loud noises. It is more metaphorical.
Debs: Clicking of the keyboard is just maddening clicking sounds.
Brad: Yeah we do have a no click keyboard rule. Those are infuriating.
Debs: Probably keeps people from going insane. It is interesting that you kind of compared it to a machine shop because one of the things that as I was doing a little research on you and DevMynd that when I came across your apprenticeship program and thinking about apprentices and machine shops or apprentices for coding and also what you said in your own personal story about you are a mediocre coder and then you sat down and kind of got into the flow of it. Think about 10,000 hours of mastery and what it takes to actually write elegant code. But I am really fascinated by this apprentice program. Is that something that you came up with because of your own experience or because of a dearth of coders or do you really see it kind of as craftsmanship?
Brad: Yeah and to answer that last bit it is absolutely craftsmanship. It is incredibly important for software to be of high quality. I am always, so I am a sales person but I am also a software engineer so I am basically internally conflicted. You basically can’t sell to a technical person because they don’t want to be sold to. So instead I am a technical person that is selling which is an odd kind of scenario. I have kind of confronted it with the fact that sometimes it is really hard to communicate certain things. So for instance what does quality software mean? Well it means that you are going to have a lower cost of ownership over time and when it gets bigger than a breadbox it is not going to fall over and we get a lot of recovery projects. So we kind of push that very strongly and follow it as a discipline.
As far as the apprenticeship goes. Apprenticeship is not an emerging concept. It sounds like it and everybody talks about it like it is an emerging concept but in reality the best way to do something is to do it for a while and constantly get better. There are a lot of components to this. You have to have an individual, like a good apprenticeship candidate is humble, reasonable, communicates incredibly well. We found that people that can read really fast can also read code really fast which is a pretty good ramp for getting their skills in line and all these things mushed together into a person that then joins our team paracodes with our folks and then can basically become a very competent idiomatically test driven ruby on rails developer in 6-8 months this doesn’t mean that they can do everything soup to nuts. It means that they can provide leadership even on teams that have more experience because it is a very rigorous 6-8 months. So that is kind of how we do the apprenticeship.
There is a very important personality component. There is of course aptitude is an important component and all those things coming together ends up being very beneficial for a number of reasons. Apprentices tend to actually educate the senior developers that they work with because they are a new set of eyes. So whenever you get a new set of eyes on a piece of code and they ask a very reasonable question although it at least naïve in the concept that they haven’t been programming for that long and the actual senior programmer will go wow I haven’t thought of that because I have been doing this for too long. So it is very beneficial in that the senior engineers get to kind of get a new perspective on things.
Another fun part of apprenticeship is that because you are the people that brought them up they have a very sticky nature. So they tend to not quit for quite a while. The average lifespan, lifespan is the wrong term. The average duration that someone software engineer would work for a company is typically in Chicago it is 3-5 years. In the Bay it is 14-18 months. So for apprentices they are going to end up being longer than that 5 year stretch. I mean don’t get me wrong here we still have to pay them obviously they would bail if they could get a way higher number but they grew up in our culture they were raised by our folks and it creates and great kinship comradery I guess is a good term for it for sure. So that is kind of the outline of apprenticeship.
Jim: It seems reassuringly structured in many ways. I am guessing that some people kind of get frustrated with a structure but it seems you know again it just sort of feels reassuring like I know where I am going I know how I am accountable to I know that if I have been there for an extended period of time that I will receive or inherit responsibility of bringing other people up. I mean it all seems like a good healthy ecosystem but very well structured.
Brad: Yeah so let’s talk about structured. So I can name 50 companies in Chicago that do apprenticeship and I can name 3 that do it well. So a lot of people aren’t taking the apprenticeship as seriously as we do. We have 17 folks and at any given time we have 1 apprentice. We are going to grow to 20 and we think we will be able to take on 2 apprentices at the same time but it is kind of a very important thing to be very personal and for it be very deliberate. So these people are blogging for us. They are putting together proof of concept for different ideas that they have on their own, they have their own breakable toys basically a piece of software that they can write and then break when they need to which is a great learning tool for them and all of those things kind of play into their course of education self-education over the 6-8 months of the apprenticeship. That part of the process being self-directed but still receiving mentorship from others is incredibly important in software because you have to relearn your entire job every 3 years anyway. Ruby is going to change dramatically or rails more specially. Rails is going to change dramatically in the next 5 years and we are going to have to kind of change the way we do things. It is a living thing, software is a living thing. You have to treat it like that and pay attention to it like that.
Debs: So in some ways you are also just really cultivating a lifetime of learning as well that you are looking for lifelong learners both in the apprenticeship program and for your hires that you are curious enough about what you do you love what you do enough to stay up to date and not get frustrated when everything you know is now over and you have to start again.
Brad: I had lunch with a friend of mine. He is a Google software engineer and I am like you are not still doing .net and he is like oh of course not. I am like ok well this is google are you doing python. He is like oh no no java. I was like what. How long did it take you to get used to java, he said it took me 5 times longer to get use to google and the tools associated with google then it did to get adapted to java and java and .net as programming languages have a lot of similarity. So I was asking kind of humorously to myself because I wanted to hear what his response was. It wasn’t exactly what I was expecting. It is one of those things where there are so many different components to programming as a concept that it is transferable but it also is just game changing. Another friend of mine that I also talked to yesterday she said that if she doesn’t program if she does training for 6 months she has to have a recovery period. That is she has to relearn all the different tools that we use and so then I told her that her new job doing training for 6 months might not be a great choice.
Jim: Brad since you are talking about technologies in general can we talk about the technology stack so to speak which we started to explore this concept of the full stack craftsman for instance. Like is it possible that somebody can understand each layer of the stack to such a level of detail that you could be a full stack craftsman or is there an entirely new concept where an organization could work to be full stack craftsmanship organization if that even makes sense? Do you have any opinions on that?
Brad: So let’s talk about the full stack software engineer. First off I typically refer to them as the unicorn. I would also like to note that we have 3 of them.
Debs: Nice you have a unicorn stable over there.
Brad: Yes. I am not going to follow that up. So basically the desperate programmers. The programmers with different consolidated skill sets. So let’s say a java script developer and a back end developer when they work together they complement each other and they learn from each other and over time you end up with 2 developers that know how to do both. Which is incredibly powerful for our clients because that is just an ass kicking team to have a great front end engineer as well as a great back end engineer on the same team. It is a great blend but it also means that they learn from each other which is an additional benefit.
Now here is one of the problems with the idea that everyone is a full stacker. So I am not an incredibly patient person. Whenever I go to do any HTML or CSS I want to just slam my face against a brick wall intentionally because the different browsers do different things. It is a weird mentality to have building HTML and CSS be calming but great front end devs people that can sling markup and do design and you know organize great CSS those folks have that patience to deal with all the different browsers and stuff like that. That is a different patience then you would take when looking at let’s say a performance problem. Let’s say your website isn’t fast enough and you need to figure out the thing that makes it that one page load in 20 seconds. That is a different skill set a different mindset and you are not going to get that capability is not going to be easy to get out of the same individual necessarily although I don’t think that they shouldn’t try for it. I think they should. It is important to kind of know that sometimes that back end guy just isn’t going to want to go into trying to figure out why IE 6 why the text field is way over to the right. Nobody is going to want to do that as a mentality if they also happen to be a back end engineer.
So it can be super beneficial and we lead towards it. We make everyone paracode because that transfers skill and decreases distraction and that ends up making it so that we do transfer a lot of those skills but some of them just don’t make their way over.
Jim: But for people who are less familiar with it can you just kind of talk about the paracoding concept and how you implement it? I am sorry it is just fascinating to me because I can’t find a way to apply that process to other fields for instance. So I am fascinated by it.
Brad: Absolutely. So I am doing this thing I am not sure if you guys noticed. I am writing a book. So I am doing book research and the tittle of the book is CTO DNA I basically want to explain to want to be CTOs or to CEOs how to manage a technology team and what their expectations should be for someone who happens to be managing their technology team. I have interviewed I think to date like 33 people somewhere around there and early on I started asking the question what are the benefits to paracoding and it is always fun to hear because the people that do paracode are incredibly passionate about it. Because they have seen the benefits.
Jim: It is like a religion. There are some people who are just nutty about it.
Brad: It is and polarly people that really don’t want to paracode really don’t want to paracode. Typically I would raise the red flag and say they are trying to hide something. Yeah I wasn’t kidding either. It is literally if they are trying to over project what their skill level is.
Debs: Right they don’t want anybody looking over their shoulder.
Brad: And once you end up finally seeing their code it might not be fantastic but yeah that is one of the things I got in my growing up about 8 years ago is the fact that I am not the best programmer and I don’t have to be and it shouldn’t be a goal of mine to appear as the greatest programmer. That being said all the people that I asked about paracoding they all had kind of great things to say. So there is something called bus rate and that is how many members of your team would have to get hit by a bus before you were incapable of delivering anymore software.
Jim: That is awesome.
Brad: Here is an example. Group on has 1100 software engineers in like 8 countries 11 locations like just crazy sauce. So they paracode because it means that there is always going to be at least 2 people that know a particular part of the code and then when one of the other people decide to work on that piece of code they can say hey I want to pair with you I know you wrote that with that other guy there lets pair on that and then you have a third person that knows that piece code as you expand that out that means that basically the bus rate for them is probably 50 because they are constantly transferring that knowledge. Here is another benefit of paracoding. When 2 people work on the same problem together it forms a bond. So what are the 3 legs of the table of employment? The 3 legs of the table are how much money you make, how many friends you have at work and I forget what the third one is.
Debs: Satisfaction in your job?
Brad: That sounds good let’s go with it.
Jim: We are writing a book. All of us together now.
Debs: Well it really is interesting how much of what you said that seems to be specifically technical and code related are actually these great lessons about management on a much larger scale the idea of how much your senior developers learn from apprentices, how important it is to have that kind of humility to open yourself up on the transparency of being able to make mistakes and have somebody else catch them and not have that kind of tied to your ego and then who are the folks managing those people and how do they not only manage all of that but also kind of represent that transparency and that eagerness to continue to learn and that kind of thing it seems like it it applies way beyond software development as well.
Brad: So the people that manage the people. So that is actually something that I have put my brain into a lot lately as I am doing research for the book and the way that you manage a development team is acutally kind of uniform that is the scary part. I had a static set of questions that I started to ask with my interviewees and interviewee number 5 it got boring.
Debs: Well you saw a pattern right?
Brad: Yep and by the way that is the ultimate skill of a software engineer is pattern matching. Understanding patterns very quickly. So basically every time that a software engineering team doubles in size the game changes 100%. Some of the people won’t fit anymore they will go from 25 to 50 people and they won’t feel like they belong anymore because the size of the team changed and the way management has to be distributed changes. So to this you know kind of sophomoric theory it means that 2, 4, 8, 16, 32, 64 and 128 are the numbers where the game changes. I have had this I keep collaborating it. It keeps going back to basically every time they double in size although it is usually closer to 100 not 128 but you know some people might get to that point.
So the interesting part about it is that the way that you manage the team changes as the size of the team changes, the way you manage the team changes based on the size of the team and it changes because the people that are all the way at the top need to know what is happening. You need to create visibility for people at the top so that they know what is going on. They know why and so that they feel comfortable in that you have a competently run technology organization. So that is kind of a little uniformity as far as the book goes.
Now for us we are a little bit different. We have so our org structure if there was such a thing for a team of 17 we have a practice lead and the practice lead basically keeps an eye on all the projects understands where they are, all of them are at all times make sure that the code is of good quality, make sure that nobody is getting stuck and they are the person that keeps the train on the rails.
Now below that we have the principle engineer. Now the principle engineer is the unicorn. That is the person that does project management when they have a team where that is appropriate they look at the set of folks that they have and they figure out how to distribute the work, they figure out how to break down the work, they gather requirements, they do all of those different things. Now we put a principle engineer on all of our projects that are more than 2 people. So you get a principle engineer and some consultants. Keep in mind that our consultants are just as good of programmers it is just that they might not have the breadth and patience to manage the tasks at hand and manage the client or perhaps they don’t want to. So basically that is how we manage out projects is by putting just someone that is so awesome that they know how to subjectively manage their projects on projects and of course they can turn to the practice lead when they have questions or need more insights.
Jim: So when you have practice leads and you are purely rail shop right.
Brad: I would say that more than half of the work we do is java script. We even have clients that don’t have a Ruby back end you know PHP or whatever. More than half of what we do is java script but then we do rails and we do some java sometimes and some closure which is a functional programming language that is only appropriate in certain cases.
Jim: So I guess where I was going is how do you decide when a new language or a new branch of the language or a new layer is going to get introduced into the shop because that all would affect I would assume the culture and the way you do the work just in the way a volume of people would affect the culture and the way you do the work?
Brad: At the core of the question you are asking is how does technology selection work. That is actually a really complicated question because you have, let’s say that you have a team of 64 folks they are not all going to agree on what database you should be using so there is actually a number of different kind of things that you can do to manage that. One process is what I am currently referring to as "guiding" - basically you have all the people that are super passionate about java script when somebody has a technology selection challenge associated with java script then you spike out a period of time where the java script guild can build out a proof of concept and basically take in to consideration 30 odd details as to which one will be the most appropriate and that guild does a couple of things. One is it makes it so that not all the developers can pick that thing they want to use but it also makes it so that they communicate between each other and they become kind of a co-foundry of making that decision and that tends to be a great way to lead the team that implements it as well as justify it to them.
Now on a team of 4 people basically they will say, "hey what database should we use?" and one guy will say, "postgresql." Everybody else will look at each other and go, "Yeah, that is good." Typically the principle engineers are the folks that are making the technology selections on our smaller teams. Technology selection is definitely something that has to be incredibly deliberate and you have to have the discipline to make sure that it is because otherwise you might have a software engineer that is chasing a shiny object that is to say they want to use this new technology because it is cool which is not rational that is not a good decision making process.
Debs: So we have kind of I think we have really spent a lot of time in the wheelhouse that you are the most comfortable in but you have really at the beginning you were talking about taking on the roles of marketing and sales and cash flow and all that kind of stuff as you start your own place and I was actually wondering if you would feel comfortable kind of talking about what makes you uncomfortable and what you are learning on the other side of the business?
Brad: Yeah so everything makes me uncomfortable. Which there is nothing wrong with that. It is a driver. A little bit. So the things that make me uncomfortable in business oh that is a broad topic. So I have a set of mentors and a shrink I have 21 triggers. Basically there are 21 situations that can cause me to just fall off the rails and I am trying to get to the point where I don’t respond to them as much where every time it happens I go, "Oh there is my trigger let me go ahead and breathe for a moment." You know, take it to a Buddhist level. So that being said some of the things that kind of knock me off the rails includes trying to understand money on a large scale because we are managing 17 people it means that our salaries alone are in the millions and it makes sense to understand it but that is one of those things that I always fear having that transparency is incredibly uncomfortable because you know how fucked you are. Rather than the alternative which is everything is going fine. You know it is the big boy pants situation you have to do it. It is completely necessary at this stage.
Debs: So it is like every day you don’t want to look at that bottom line but every day you must look at that bottom line.
Brad: Exactly. Professional services is not as profitable as the world thinks it is you know it is always like oh my gosh that consultant is so expensive. Yeah they are still at least 4 times faster than your people though lets be fair and then they nickel and dime you it is they nickel and dime you more in Chicago then they do in the Bay. It is actually a culture in the Bay to use consultants as a thing like you use them intentionally so that you can get new blood on your team for a period of time so that you can have better insights into your own team. Whereas here it is more of a religion where people are like we can’t use consultants and despite the amount of value that they can bring even over a short term. So that is one of the things that makes me uncomfortable. You know there is personalities like no matter what happens right when you get around 4 or 5 people personalities can start taking a little bit of control even team members they are the coolest people I could ever thing to employ but they still have personalities they still have strong opinions some of them even love arguing. One of my guys does something I refer to as hate driven development.
Jim: We can do a whole podcast on that.
Brad: That is true. But basically he just says I hate that library, that library sucks. Why did they implement it this way and then 20 minutes later you will walk over by him again and say is everything ok and he is like oh yeah I get it now it is fine. You know those personalities can be a hard thing to manage but they are also the kind of the core of the culture of the organization. So those folks are the core of the organization. We have personalities it is a good thing but it does make me uncomfortable from time to time. Let’s see what else makes me uncomfortable?
Debs: I might have asked too broad a question here but I was just thinking about the transferring of going from coding to going to selling, waking up in the morning and realizing that it is kind of a different goal at the end of every day then building in code.
Brad: So let’s pop a level. I am going to talk about sales as a concept. So there are two kinds of sales people there are sales people that have a list or an appointment set and they go through the list and then there are relationship driven sales folks. So software development or selling an agency is all personality it is entirely working with people building comradery between folks you know lead sharing if that is necessary because other dev. shops use us and vice versa from time to time for larger projects. So I have to not sell. There is no selling component of what I do other than occasionally saying hey you want to have lunch maybe perhaps you might need some consultant help or what not and that is about as salesy as I get. That is kind of complimented by the fact that almost all of our clients are referrals or previous customers coming back. So there is at least that part of the machine is very well oiled and works pretty well.
Now to another point certain clients you just can’t get unless you are kind of following a sales pattern. So for instance we are building Chicago.com for the SunTimes rapports and that project I wouldn’t have gotten unless I played monkey bars and said, "hey how are you doing" to basically every member of their technology leadership. It is a great bit of work and it took a long time to sell like the sales cycle on that stuff is like 8 months for those larger projects. That being said the transition that I made personally is kind of I started out by just hating the fact that I was doing sales because it felt wrong to me because I am a software engineer being sold to feels inappropriate and then I just quit trying to sell and instead I just have deep conversations in kind of root out what people are working on whether or not they might be able to use our help and that feels a lot better. It feels a lot better to antisell.
Debs: Yeah and how did you kind of get there, how did you realize that that was where you had to go?
Brad: So it was a combination of my mentors telling me that wasn’t the right way to approach things in combination with the fact that it didn’t work. Trying to actually sell does not work for heavy relationship based sale stuff and I can appreciate all those really hardcore sales people out there but it is still hard a little bit even though there is a lot reoccurring themes right like I reached back out every month or so so I ask permission hey is it ok if I reach out to you again in a month or so and they always say yes but I am always on the edge of going they are totally going to say no.
Jim: Well Brad maybe as we kind of come in for a landing I am curios when you mix company leadership and team growth and things like that with this conversation of sales and so forth I am just kind of curious is there a target or an ideal or a goal or do you just keep going, do you just kind of keep following what the market does? Do you have a sense that 17 is good but 28 is the ideal or you want to get to that 128 or you know what is there kind of a plateau or does it just keep going?
Brad: There is a plateau. The plateau is 32. So basically my theory is that every time you add one person more than 32 to your team you reduce your capability to deliver value by 1%.
Jim: That is really specific. How do you land at that?
Brad: Because I am silly. So I landed at that because whenever a team kind of gets to especially a custom software agency team gets to a certain size it just becomes a lot more difficult to deliver value and deliver a lot of value. That is one of the things that I think that we should all just and by we I mean all custom software agencies we should just all admit to ourselves that we should just stop growing at 32 and we should all just be friends.
Jim: That is really interesting and I would imagine that has a huge impact on culture and so forth as well right because I mean do you know you would be I think by this theory you would be 100% different company at 32 then you are at 17.
Brad: Yep and that is absolutely true. There are processes that will have to go in place in between now and then you know and the way we manage teams is going to be a little bit different. Our practice lead which I was describing a little bit ago that actually transferred from cofounder JC to one of our internal guys and that is one of the changes that we saw at 16 is that JC can’t be the practice lead because he is the octopus that is being pulled from 8 different directions and is a little bit spread too thin scenario. So now Joe is managing that role and we feel that that is the growth that had to happen at 16 as we grow to 32 there are going to be other things that come in that I can’t even predict yet even regardless of my book research there is just things that I haven’t seen yet that I am going to. Then I will call them out and make good fun of it as well as provide the constructs to repair.
Jim: I have to say this is oddly reassuring. The kind of confidence of change and just kind of the predictability of the pattern. It is really really interesting.
Brad: Yeah and I mean have you guys ever been part of a giant team and the problem with the team was not the people but the fact that it was giant?
Jim: Yeah definitely.
Brad: That is devastating. Everybody answers yes to that question.
Jim: So where do we go to find you? Let’s get some websites and twitter handles and stuff out there.
Brad: So the book that I am writing is called CTO DNA and I bought ctodna.com if you look at the testimonials on the page you might notice that I only have one quote from one of my interviewees so if anybody would like to be an interviewee and give me a quote that would be fabulous. During these interviews I share my knowledge of the 33 people that I have interviewed as well as try to gain insights from the folks that I am interviewing. So it is kind of a two way street. All the people I talk to say let’s do it again in 6 months I want to hear what else you have gathered at that point. So I am looking for more interviewees for that. Also if you sign up for the newsletter you will get 3 chapters for free which is going to include software developer archetypes. Basically there are certain personality traits if you will that exist within software engineers that are antipatterns and we need to kind of call ourselves out on those antipatterns. I would like to note that I have been all of them during my career at some point.
Jim: Sybil of coding of sorts.
Brad: Yeah exactly. If you wanted to follow me on twitter it is @BWilken you can find out by Dev Mynd by going to devmynd.com and I think that is all I got.
Jim: That is awesome. This has been a fantastic conversation I can’t thank you enough.
Brad: Absolutely thanks for having me.